Your SlideShare is downloading. ×
0
Why MongoDB was Createdwe start at 9:30<br />MongoSF 2011<br />Dwight Merriman / 10gen<br />
signs we needed something different<br />doubleclick - 400,000 ads/second<br />people writing their own stores<br />cachin...
the db space 2000 - 2010<br />+ great for complex transactions<br />+ great for tabular data<br />+ ad hoc queries easy<br...
the db space 2000 - 2010<br />+ great for complex transactions<br />+ great for tabular data<br />+ ad hoc queries easy<br...
the db space 2000 - 2010<br />+ great for complex transactions<br />+ great for tabular data<br />+ ad hoc queries easy<br...
the db space<br />+ fits OO programming well<br />+ agile<br />+ speed/scale<br />- querying a little less add hoc<br />- ...
data models<br />
as simple as possible but no simpler<br />
as simple as possible but no simpler<br />need a good degree of functionality to handle a large set of use cases<br />some...
as simple as possible but no simpler<br />but, leave out a few things so we can scale<br />no choice but to leave out rela...
as simple as possible but no simpler<br />to scale, need a new data model.  some options:<br />key/value<br />columnar / t...
mongodb philosphy<br />No longer one-size-fits all.  but not 12 tools either.<br />By reducing transactional semantics the...
Questions?<br />http://blog.mongodb.org/<br />@mongodb<br />me - @dmerr<br />www.mongodb.org<br />http://groups.google.com...
Upcoming SlideShare
Loading in...5
×

Why mongo db was created - Dwight Merriman - MongoSF 2011

1,960

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,960
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
28
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Transcript of "Why mongo db was created - Dwight Merriman - MongoSF 2011"

  1. 1. Why MongoDB was Createdwe start at 9:30<br />MongoSF 2011<br />Dwight Merriman / 10gen<br />
  2. 2. signs we needed something different<br />doubleclick - 400,000 ads/second<br />people writing their own stores<br />caching is de rigueur<br />complex ORM frameworks<br />computer architecture trends<br />cloud computing<br />
  3. 3. the db space 2000 - 2010<br />+ great for complex transactions<br />+ great for tabular data<br />+ ad hoc queries easy<br />- O<->R mapping hard<br />- speed/scale challenges<br />- not super agile<br />+ ad hoc queries easy<br />+ SQL gives us a standard protocol for the interface between clients and servers<br />+ scales horizontally better than operational dbs. some scale limits at massive scale<br />- schemas are rigid<br />- real time is hard; very good at bulk nightly data loads<br />
  4. 4. the db space 2000 - 2010<br />+ great for complex transactions<br />+ great for tabular data<br />+ ad hoc queries easy<br />- O<->R mapping hard<br />- speed/scale challenges<br />- not super agile<br />+ ad hoc queries easy<br />+ SQL gives us a standard protocol for the interface between clients and servers<br />+ scales horizontally better than operational dbs. some scale limits at massive scale<br />- schemas are rigid<br />- real time is hard; very good at bulk nightly data loads<br />
  5. 5. the db space 2000 - 2010<br />+ great for complex transactions<br />+ great for tabular data<br />+ ad hoc queries easy<br />- O<->R mapping hard<br />- speed/scale challenges<br />- not super agile<br />+ ad hoc queries easy<br />+ SQL gives us a standard protocol for the interface between clients and servers<br />+ scales horizontally better than operational dbs. some scale limits at massive scale<br />- schemas are rigid<br />- real time is hard; very good at bulk nightly data loads<br />
  6. 6. the db space<br />+ fits OO programming well<br />+ agile<br />+ speed/scale<br />- querying a little less add hoc<br />- not super transactional<br />- not sql<br />
  7. 7. data models<br />
  8. 8. as simple as possible but no simpler<br />
  9. 9. as simple as possible but no simpler<br />need a good degree of functionality to handle a large set of use cases<br />sometimes need strong consistency / atomicity<br />secondary indexes<br />ad hoc queries<br />
  10. 10. as simple as possible but no simpler<br />but, leave out a few things so we can scale<br />no choice but to leave out relational<br />distributed transactions are hard to scale<br />
  11. 11. as simple as possible but no simpler<br />to scale, need a new data model. some options:<br />key/value<br />columnar / tabular<br />document oriented (JSON inspired)<br />opportunity to innovate -> agility<br />
  12. 12. mongodb philosphy<br />No longer one-size-fits all. but not 12 tools either.<br />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.<br />Non-relational (no joins) makes scaling horizontally practical<br />Document data models are good<br />Keep functionality when we can (key/value stores are great, but we nee more)<br />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...<br />
  13. 13. Questions?<br />http://blog.mongodb.org/<br />@mongodb<br />me - @dmerr<br />www.mongodb.org<br />http://groups.google.com/group/mongodb-user<br />irc://irc.freenode.net/#mongodb<br />MongoNYC - June 7Mongo Hamburg - June 27MongoDC - June 27<br />10AM - in this room: Schema Design<br />10:45AM - break<br />thanks<br />
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×