1. Why MongoDB was Createdwe start at 9:30 MongoSF 2011 Dwight Merriman / 10gen

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

3. the db space 2000 - 2010 + 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

4. the db space 2000 - 2010 + 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

5. the db space 2000 - 2010 + 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

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

7. data models

8. as simple as possible but no simpler

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

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

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

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

13. Questions? http://blog.mongodb.org/ @mongodb me - @dmerr www.mongodb.org http://groups.google.com/group/mongodb-user irc://irc.freenode.net/#mongodb MongoNYC - June 7Mongo Hamburg - June 27MongoDC - June 27 10AM - in this room: Schema Design 10:45AM - break thanks