Why mongo db was created - Dwight Merriman - MongoSF 2011
Download as PPTX, PDF3 likes1,134 views
- MongoDB was created because existing databases had limitations in terms of speed, scalability, flexibility and agility for modern applications. - Relational databases were good for complex transactions and tabular data but had challenges with object-relational mapping, speed and scaling. NoSQL databases were more flexible but lacked querying and transactions. - MongoDB uses a document data model and is non-relational to allow horizontal scaling while still providing functionality like indexing and queries. The goal was to balance simplicity, functionality and scalability.
Why mongo db was created - Dwight Merriman - MongoSF 2011
- 1. Why MongoDB was Createdwe start at 9:30MongoSF 2011Dwight Merriman / 10gen
- 2. signs we needed something differentdoubleclick - 400,000 ads/secondpeople writing their own storescaching is de rigueurcomplex ORM frameworkscomputer architecture trendscloud 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 simplerneed a good degree of functionality to handle a large set of use casessometimes need strong consistency / atomicitysecondary indexesad hoc queries
- 10. as simple as possible but no simplerbut, leave out a few things so we can scaleno choice but to leave out relationaldistributed transactions are hard to scale
- 11. as simple as possible but no simplerto scale, need a new data model. some options:key/valuecolumnar / tabulardocument oriented (JSON inspired)opportunity to innovate -> agility
- 12. mongodb philosphyNo 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 practicalDocument data models are goodKeep 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/@mongodbme - @dmerrwww.mongodb.orghttp://groups.google.com/group/mongodb-userirc://irc.freenode.net/#mongodbMongoNYC - June 7Mongo Hamburg - June 27MongoDC - June 2710AM - in this room: Schema Design10:45AM - breakthanks