Why mongo db was created - Dwight Merriman - MongoSF 2011
description
Transcript of Why mongo db was created - Dwight Merriman - MongoSF 2011
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