Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Approaching and evaluating NoSQL

Approaching and evaluating NoSQL

Brown bag lunch presentation at TUI / Fritidsresor about approaching and evaluating the NoSQL area.

Approx 60 minutes.

Mårten Gustafson

August 31, 2011
Tweet

More Decks by Mårten Gustafson

Other Decks in Technology

Transcript

  1. NoSQL Mårten Gustafson Brown bag lunch @ TUI / Fritidsresor

    Stockholm 2011-08-31 Wednesday, August 31, 2011
  2. Disclaimer I don’t know any and all products by heart

    I’m trying to illustrate my broad reasoning Wednesday, August 31, 2011 NoSQL tends crammed with religious zealots
  3. “NoSQL is a movement promoting a loosely defined class of

    non-relational data stores that break with a long history of relational databases” - Wikipedia Wednesday, August 31, 2011
  4. “NoSQL is a movement promoting a loosely defined class of

    non-relational data stores that break with a long history of relational databases” - Wikipedia • Not one single technique Wednesday, August 31, 2011
  5. “NoSQL is a movement promoting a loosely defined class of

    non-relational data stores that break with a long history of relational databases” - Wikipedia • Not one single technique • Not one type of data Wednesday, August 31, 2011
  6. “NoSQL is a movement promoting a loosely defined class of

    non-relational data stores that break with a long history of relational databases” - Wikipedia • Not one single technique • Not one type of data • Not one type of use case Wednesday, August 31, 2011
  7. “NoSQL is a movement promoting a loosely defined class of

    non-relational data stores that break with a long history of relational databases” - Wikipedia • Not one single technique • Not one type of data • Not one type of use case Wednesday, August 31, 2011
  8. Example reasoning “...so our RDBMS is a SPoF that won’t

    scale” Multi-master move to? Wednesday, August 31, 2011
  9. Example reasoning “...so our RDBMS is a SPoF that won’t

    scale” Atomicity Multi-master sacrifices? move to? Wednesday, August 31, 2011
  10. Example reasoning “...so our RDBMS is a SPoF that won’t

    scale” Distribution / replication Atomicity Multi-master sacrifices? gives? move to? Wednesday, August 31, 2011
  11. Example reasoning “...so our RDBMS is a SPoF that won’t

    scale” Distribution / replication De-normalization Atomicity Multi-master sacrifices? gives? move to? requires? Wednesday, August 31, 2011
  12. Example reasoning “...so our RDBMS is a SPoF that won’t

    scale” Distribution / replication De-normalization Atomicity Multi-master sacrifices? gives? move to? requires? Integrity dissolves? Wednesday, August 31, 2011
  13. Example reasoning “...so our RDBMS is a SPoF that won’t

    scale” Distribution / replication De-normalization Querying Atomicity Multi-master sacrifices? gives? move to? toughens? requires? Integrity dissolves? Wednesday, August 31, 2011
  14. Key aspects • Type of data • Graph • Documents

    & key/value-pairs Wednesday, August 31, 2011
  15. Key aspects • Type of data • Graph • Documents

    & key/value-pairs • Operational aspect Wednesday, August 31, 2011
  16. Key aspects • Type of data • Graph • Documents

    & key/value-pairs • Operational aspect • Resilient Wednesday, August 31, 2011
  17. Key aspects • Type of data • Graph • Documents

    & key/value-pairs • Operational aspect • Resilient • Atomic Wednesday, August 31, 2011
  18. Example Atomic Resilient Graph Neo4J InfiniteGraph ? Document & key/value-paris

    CouchDB RavenDB Redis Riak Voldemort Cassandra Wednesday, August 31, 2011
  19. Case A: Data from user • Data set... • ...mix

    of binary & JSON (access by known key) • ...replicated to all nodes on best effort • ...allows read & write on any node • individual nodes may be unavailable Wednesday, August 31, 2011
  20. Case A: Data from user Atomic Resilient Graph Neo4J InfiniteGraph

    ? Document & key/value-pairs CouchDB RavenDB Redis Riak Voldemort Cassandra Wednesday, August 31, 2011
  21. Case A: Data from user • Riak due to... •

    outstanding packaging & community • simple on both server and workstations • serious and dedicated engineering team • Lots of statistics • HTTP API • Everything’s tunable (much per request) Wednesday, August 31, 2011
  22. Case B: configuration • Data set... • ...is JSON (access

    by alternating keys) • ...on all nodes • ...seldom updated (read only) • ...consistent and replicated on demand Wednesday, August 31, 2011
  23. Case B: configuration Atomic Resilient Graph Neo4J InfiniteGraph ? Document

    & key/value-pairs CouchDB RavenDB Redis Riak Voldemort Cassandra Wednesday, August 31, 2011
  24. Case B: configuration • CouchDB due to... • simple on

    both server and workstations • HTTP API • Views for alternating keys • Lots of statistics • Dead simple “one-click” push replication Wednesday, August 31, 2011
  25. does it fit with current data structures? Wednesday, August 31,

    2011 Don’t underestimate the exercise of making your data “fit” a certain nosql product
  26. search and reporting? Wednesday, August 31, 2011 What access patterns

    do you have today? Tomorrow? What kind of reports will customers or management require?
  27. does it speak HTTP? Wednesday, August 31, 2011 For us

    at Hitta.se this is important since almost everything we do is HTTP based
  28. availability and redundancy? Wednesday, August 31, 2011 What kinds of

    availability? How does it handle node failures? Network partitions?
  29. ease of scaling in and out? Wednesday, August 31, 2011

    What’s required to add additional nodes? How do you remove a node temporarily or permanently?
  30. is it properly packaged? Wednesday, August 31, 2011 Proper install

    packages? Sane defaults in terms of service accounts and privileges?
  31. is your data safe? Wednesday, August 31, 2011 Is your

    data really durable on disk -- assuming that’s what you need