Why MongoDB was Createdwe start at 9:30

MongoSF 2011Dwight Merriman / 10gen

signs we needed something different

• doubleclick - 400,000 ads/second• people writing their own stores• caching is de rigueur• complex ORM frameworks• computer architecture trends• cloud computing

the db space 2000 - 2010

OLTP / operational

BI / reporting

+ great for complex transactions+ great for tabular data+ ad hoc queries easy- O<->R mapping hard- speed/scale challenges- not super agile

+ ad hoc queries easy+ SQL gives us a standard protocol for the interface between clients and servers+ scales horizontally better than operational dbs. some scale limits at massive scale- schemas are rigid- real time is hard; very good at bulk nightly data loads

the db space 2000 - 2010

OLTP / operational

BI / reporting

+ great for complex transactions+ great for tabular data+ ad hoc queries easy- O<->R mapping hard- speed/scale challenges- not super agile

+ ad hoc queries easy+ SQL gives us a standard protocol for the interface between clients and servers+ scales horizontally better than operational dbs. some scale limits at massive scale- schemas are rigid- real time is hard; very good at bulk nightly data loads

less issues here

the db space 2000 - 2010

OLTP / operational

BI / reporting

+ great for complex transactions+ great for tabular data+ ad hoc queries easy- O<->R mapping hard- speed/scale challenges- not super agile

+ ad hoc queries easy+ SQL gives us a standard protocol for the interface between clients and servers+ scales horizontally better than operational dbs. some scale limits at massive scale- schemas are rigid- real time is hard; very good at bulk nightly data loads

caching

flat filesmap/reduce

app layer partitioning

the db space

scalable nonrelational

(“nosql”)

OLTP / operational

BI / reporting

+ fits OO programming well+ agile+ speed/scale- querying a little less add hoc- not super transactional- not sql

data models

as simple as possible but no simpler

as simple as possible but no simpler

• need a good degree of functionality to handle a large set of use cases– sometimes need strong consistency / atomicity– secondary indexes– ad hoc queries

as simple as possible but no simpler

• but, leave out a few things so we can scale– no choice but to leave out relational– distributed transactions are hard to scale

as simple as possible but no simpler

• to scale, need a new data model. some options:– key/value– columnar / tabular– document oriented (JSON inspired)

• opportunity to innovate -> agility

mongodb philosphy

• No longer one-size-fits all. but not 12 tools either.• 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.

• 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...

Questions?

http://blog.mongodb.org/@mongodb

me - @dmerr

www.mongodb.orghttp://groups.google.com/group/mongodb-user

irc://irc.freenode.net/#mongodb

MongoNYC - June 7Mongo Hamburg - June 27

MongoDC - June 27

10AM - in this room: Schema Design10:45AM - break

thanks