The document discusses the rise of NoSQL databases as an alternative to traditional relational databases. NoSQL databases are non-relational and are designed for massive scale and flexibility. They achieve horizontal scalability through lack of joins and lightweight transactions. Key features that vary across NoSQL products include data model (key-value, column-oriented, document-oriented), consistency model, and distribution/query methods. NoSQL is influenced by concepts like CAP theorem and eventual consistency.

1. NoSQL : Channeling the Data ExplosionDwight MerrimanCEO, 10gen@dmerr dmerr.tumblr.comGlueCon 2010

2. The database world is changingNo longer one-size-fits-all

3. NoSQL = Non-relational next generation operation data stores and databases

4. Scaling Outno joins +light transactional semantics = horizontally scalable architectures

5. Why?cloudcommodityhttp://www.globalnerdy.com/2007/09/07/multicore-musings/

6. How the NoSQL Products VaryWhat’s the sameNo joinsNo complex transactionsWhat variesScale-out modelConsistency modelData model

7. Scaling Outdistribution & query modelsConsistent hashingOrder preserving range chunkingScatter gather

8. Data modelsno joins +light transactional semantics = horizontally scalable architecturesImportant side effect : new data models = improved ways to develop apps

9. Data ModelsKey/valueColumn-oriented “bigtable-style”Document-oriented (JSON)

10. Data Models{ title: ‘Too Big to Fail’, author: ‘John S’,ts: Date(“05-Nov-09 10:33”), comments: [ { author: 'Ian White', comment: 'Great article!' }, { author: 'Joe Smith', comment: 'But how fast is it?', replies: [ {author: 'Jane Smith', comment: 'scalable?'} ] } ] ], tags: [‘finance’, ‘economy’]}

11. { title: ‘Too Big to Fail’, author: ‘John S’,ts: Date(“05-Nov-09 10:33”), comments: [ { author: 'Ian White', comment: 'Great article!' }, { author: 'Joe Smith', comment: 'But how fast is it?', replies: [ {author: 'Jane Smith', comment: 'scalable?'} ] } ] ], tags: [‘finance’, ‘economy’]}db.posts.find( { tags : ‘economy’ } ) .sort({ts:-1}).limit(10).skip(10)db.posts.find( { “comments.author” : “Ian White” } )

12. Influences

13. CAP It is impossible in the asynchronous network model to implement a read/write data object that guarantees the following properties:• Availability• Atomic consistency in all fair executions (including those in which messages are lost).

14. Consistency Models - CAPChoices are AP or CPWrite Availability, not Read Availability, is the Main QuestionIt’s not all about CAPEventual consistency makes these non-availability aspects better:Multi data centerSpeedEven load distribution

15. Eventual Consistency

16. Eventual ConsistencyRead(x) : 1, 2, 2, 4, 4, 4, 4 …

17. Could we get this?Read(x) : 1, 2, 1, 4, 2, 4, 4, 4 …

18. TermsRWNR+W>N has nice propertiesSloppy quorum

19. R+W>NIf R+W > N, we can’t have both fast local reads and writes at the same time if all the data centers are equal peers?

20. Network Partitions

21. Trivial Network Partitions

23. Sometimes we need global state / more consistencyUnique key constraintsUser registrationACL changesAre we surprising the user?read-your-own-writes

24. Could it be the case that…uptime( CP + average developer ) >= uptime( AP + average developer )where uptime:= system is up and non-buggy?

25. PredictionsJSON will be the most popular building block for non-relational data modelsTunable consistency in all the productsSome SQL in these products!

26. Questions?Thank youdwight@10gen.com@dmerrdmerr.tumblr.com@mongodbDownload : www.mongodb.org10gen is hiring in SF and NYC – info@10gen.com