Former DoubleClick Founder and CTO Dwight Merriman wrote the first lines of MongoDB code in 2007. He drew upon his experiences building large scale, high availability, robust systems to create a new kind of database. This session will introduce some of the background to how and why MongoDB came about to address the need for a more scalable database, and provide some key use cases and rationale for a new product category in the database marketplace.
2. signs we needed something different
signs we needed something different
• doubleclick ‐ 400,000 ads/second
• people writing their own stores
people writing their own stores
• caching is de rigueur
• complex ORM frameworks
• computer architecture trends
p
• cloud computing
3. the db space 2000
the db space 2000 ‐ 2010
+ great for complex
dh i
+ ad hoc queries easy transactions
+ SQL gives us a standard + great for tabular data
protocol for the interface + ad hoc queries easy
between clients and ‐ O<‐>R mapping hard
servers ‐ speed/scale challenges
+ scales horizontally ‐ not super agile
better than operational
dbs. some scale limits at BI / OLTP /
massive scale
i l reporting
i operational
i l
‐ schemas are rigid
‐ real time is hard; very
good at bulk nightly data
loads
4. the db space 2000
the db space 2000 ‐ 2010
+ great for complex
dh i
+ ad hoc queries easy transactions
+ SQL gives us a standard + great for tabular data
protocol for the interface + ad hoc queries easy
between clients and ‐ O<‐>R mapping hard
servers ‐ speed/scale challenges
+ scales horizontally ‐ not super agile
better than operational
dbs. some scale limits at BI / OLTP /
massive scale
i l reporting
i operational
i l
‐ schemas are rigid
‐ real time is hard; very
good at bulk nightly data
loads
less issues
here
5. the db space 2000
the db space 2000 ‐ 2010
+ great for complex
dh i
+ ad hoc queries easy transactions
+ SQL gives us a standard + great for tabular data
protocol for the interface + ad hoc queries easy
between clients and ‐ O<‐>R mapping hard
servers ‐ speed/scale challenges
+ scales horizontally ‐ not super agile
better than operational
dbs. some scale limits at BI / OLTP /
massive scale
i l reporting
i operational
i l
‐ schemas are rigid caching
‐ real time is hard; very
good at bulk nightly data
loads
app layer
flat files partitioning
map/reduce
6. the db space
the db space
+ fits OO programming
wellll
+ agile
+ speed/scale
‐ querying a little less
scalable
l bl add hoc
dd h
nonrelational ‐ not super transactional
BI / reporting (“nosql”) ‐ not sql
OLTP /
OLTP /
operational
9. as simple as possible
but no simpler
b l
• need a good degree of functionality to handle
a large set of use cases
– sometimes need strong consistency / atomicity
– secondary indexes
– ad hoc queries
10. as simple as possible
but no simpler
b l
• but, leave out a few things so we can scale
– no choice but to leave out relational
– distributed transactions are hard to scale
11. as simple as possible
but no simpler
b l
• to scale, need a new data model. some
options:
– key/value
– columnar / tabular
– document oriented (JSON inspired)
• opportunity to innovate ‐> agility
pp y g y
12. mongodb philosphy
mongodb philosphy
• No longer one‐size‐fits all. but not 12 tools either.
N l i fit ll b t t 12 t l ith
• By reducing transactional semantics the db provides, one can still solve an
interesting set of problems where performance is very important, and
horizontal scaling then becomes easier.
hori ontal scaling then becomes easier
• Non‐relational (no joins) makes scaling horizontally practical
• Document data models are good
• Keep functionality when we can (key/value stores are great, but we nee
more)
• Database technology should run anywhere, being available both for
running on your own servers or VMs, and also as a cloud pay‐for‐what‐
you‐use service. And ideally open source...
13. Questions?
http://blog.mongodb.org/
@mongodb
me
me ‐ @dmerr
www.mongodb.org
http://groups.google.com/group/mongodb‐user
htt // l / / db
irc://irc.freenode.net/#mongodb
thanks