The Many Flavors of NoSQL at That Conference

The relational database has been the dominant model for persisting data for the last 40 years. While SQL databases aren’t going away anytime soon, the NoSQL ("not only SQL") movement has challenged the relational database's place as the default persistence layer for modern applications. Learn about horizontal scaling and eventual consistency as well as key-value stores, document databases, graph databases, and more.

Transcript

1. @BradleyHolt! The Many Flavors of NoSQL That Conference Monday, August 10, 2015 Bradley Holt, Developer Advocate
2. @BradleyHolt!
3. @BradleyHolt! The Relational Database •  Originated from within IBM in 1970 •  Data is stored in tables, rows, and columns •  Each table has a column designated as the primary key •  Foreign keys can reference primary keys, allowing for joins Image Credit: database 2 by Tim Morgan, on Flickr
4. @BradleyHolt! ACID Guarantees •  Atomicity: Each transaction must be "all or nothing" •  Consistency: Constraints (e.g. foreign key constraints) are always applied before data is written •  Isolation: Sequencing of transactions is ensured •  Durability: Committed transactions will survive errors such as power loss or database crashes Image Credit: Hard Drive by walknboston, on Flickr
5. @BradleyHolt! Image Credit: IBM 360 Announcement center by Robert Nix, on Flickr
6. @BradleyHolt! …then the web happened •  Horizontal scaling became more important than vertical scaling •  Eventual consistency became an acceptable alternative to immediate consistency •  New models for storing and retrieving data were explored Image Credit: Dialing Up Web History by Mike Licht, on Flickr
7. @BradleyHolt! Horizontal Scaling •  Scaling through the addition of commodity hardware •  Vertical scaling is limited by the maximum server size available •  Goal of horizontal scaling is linear scalability, where each additional resource adds the same capacity as the previously added resource Image Credit: truck day 2012 june 19 (11) by Laurence Simon (Crap Mariner), on Flickr
8. @BradleyHolt! Eventual Consistency •  Each node in a distributed system will eventually contain a consistent view of the data (given no new updates) •  A property of the web in general •  Data conflicts can arise which need to be resolved Image Credit: organic growth by Steve Jurvetson, on Flickr
9. @BradleyHolt! Enter "Not only SQL" (NoSQL) Databases key-value graph document …more Image Credit: database by Tim Morgan, on Flickr
10. @BradleyHolt!
11. @BradleyHolt!
12. @BradleyHolt! Key-Value Stores •  Opaque data accessed through unique keys •  Typically offer very fast read/write data access •  Good for caching, highly-variable data values, and/or high performance •  Typically can't query against values, only keys Image Credit: Keys by Taki Steve, on Flickr
13. @BradleyHolt! Document Databases •  A type of key-value store where the value is more clearly defined •  Often include both a primary index and secondary indexes •  Document model is often a great fit for modern web and mobile apps Image Credit: paper by Tim Morgan, on Flickr
14. @BradleyHolt! Graph Databases •  Based on graph theory •  Entities are represented by nodes •  Nodes contain properties •  Nodes/properties are connected to other nodes/properties via edges •  Uses include social networks (e.g. "friend of a friend"), driving directions, shopping recommendations, etc. Image Credit: Die Homepage by Jörg Kanngießer, on Flickr
15. @BradleyHolt! The CAP Theorem Partition Tolerance Availability Consistency Consistency Availability Partition Tolerance
16. @BradleyHolt! IBM Cloudant •  Globally distributed data layer for web and mobile applications •  MongoDB-style queries •  Advanced geospatial capabilities •  Full text search indexing •  Based on Apache CouchDB
17. @BradleyHolt! Apache CouchDB •  Prioritizes Availability and Partition Tolerance over Consistency •  Features Atomic, Consistent, Isolated, and Durable (ACID) properties
18. @BradleyHolt! Common Relational Database Problems •  Object-relational impedance mismatch •  use the repository pattern (domain and data mapping layers) •  object-relational mapping (ORM) •  Semi-structured data •  leave non-applicable column values null •  use the entity-attribute-value (EAV) anti-pattern (never do this) •  High concurrency •  reduce transaction scope •  denormalize
19. @BradleyHolt!
20. @BradleyHolt! Further Reading
21. @BradleyHolt! Image Credits •  database 2 by Tim Morgan, on Flickr <https://www.flickr.com/photos/timothymorgan/75593157> •  Hard Drive by walknboston, on Flickr <https://www.flickr.com/photos/walkn/5472536812> •  IBM 360 Announcement center by Robert Nix, on Flickr <https://www.flickr.com/photos/simplyphotography/6880675992> •  Dialing Up Web History by Mike Licht, on Flickr <https://www.flickr.com/photos/notionscapital/7324074422> •  truck day 2012 june 19 (11) by Laurence Simon (Crap Mariner), on Flickr <https://www.flickr.com/photos/isfullofcrap/7402854788> •  organic growth by Steve Jurvetson, on Flickr <https://www.flickr.com/photos/jurvetson/63009926> •  database by Tim Morgan, on Flickr <https://www.flickr.com/photos/timothymorgan/75294154> •  Keys by Taki Steve, on Flickr <https://www.flickr.com/photos/13519089@N03/1380483002> •  paper by Tim Morgan, on Flickr <https://www.flickr.com/photos/timothymorgan/75288583> •  Die Homepage by Jörg Kanngießer, on Flickr <https://www.flickr.com/photos/derletzteschrei/193506552>
22. @BradleyHolt! Bradley Holt Developer Advocate bradley.holt@us.ibm.com @BradleyHolt github.com/bradley-holt