why nosql makes sense
Post on 27-May-2015
1.290 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
top related