Why NoSQL Makes SenseWhy NoSQL Makes Sense

NoSQL NowDwight Merriman / 10genDwight Merriman / 10gen

signs we needed something differentsigns we needed something different

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

the db space 2000 ‐ 2010the db space 2000  2010

+ great for complex d h i transactions

+ great for tabular data+ ad hoc queries easy‐ O<‐>R mapping hard

+ ad hoc queries easy+ SQL gives us a standard protocol for the interface between clients and 

OLTP / i l

BI / i

‐ speed/scale challenges‐ not super agile

servers+ scales horizontally better than operational dbs. some scale limits at 

i l operationalreportingmassive scale‐ schemas are rigid‐ real time is hard; very good at bulk nightly data loadsloads

the db space 2000 ‐ 2010the db space 2000  2010

+ great for complex d h i transactions

+ great for tabular data+ ad hoc queries easy‐ O<‐>R mapping hard

+ ad hoc queries easy+ SQL gives us a standard protocol for the interface between clients and 

OLTP / i l

BI / i

‐ speed/scale challenges‐ not super agile

servers+ scales horizontally better than operational dbs. some scale limits at 

i l operationalreportingmassive scale‐ schemas are rigid‐ real time is hard; very good at bulk nightly data loadsloads

less issues here

the db space 2000 ‐ 2010the db space 2000  2010

+ great for complex d h i transactions

+ great for tabular data+ ad hoc queries easy‐ O<‐>R mapping hard

+ ad hoc queries easy+ SQL gives us a standard protocol for the interface between clients and 

OLTP / i l

BI / i

‐ speed/scale challenges‐ not super agile

servers+ scales horizontally better than operational dbs. some scale limits at 

i l operationalreportingmassive scale‐ schemas are rigid‐ real time is hard; very good at bulk nightly data loads

caching

loads

flat filesmap/reduce

app layer partitioning

the db spacethe db space+ fits OO programming 

ll

l bl

well+ agile+ speed/scale‐ querying a little less dd hscalable 

nonrelational(“nosql”)BI / reporting

add hoc‐ not super transactional‐ not sql

OLTP /OLTP / operational

data models

as simple as possible b lbut no simpler

as simple as possible b lbut 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 b lbut 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 b lbut no simpler

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

• opportunity to innovate ‐> agilitypp y g y

mongodb philosphymongodb philosphy

N l i fit ll b t t 12 t l ith• 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 hori ontal scaling then becomes easierhorizontal 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/@mongodbme ‐@dmerrme  @dmerr

www.mongodb.orghtt // l / / dbhttp://groups.google.com/group/mongodb‐user

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

thanks