2011 05-12 nosql-progressive.net

1,188 views
1,096 views

Published on

A high level overview of my views of the NoSQL space.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,188
On SlideShare
0
From Embeds
0
Number of Embeds
356
Actions
Shares
0
Downloads
13
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • NoSQL tends crammed with religious zealots\n
  • \n
  • \n
  • \n
  • (No)SQL for me is very much about trade offs\n
  • Don’t underestimate the exercise of making your data “fit” a certain nosql product\n
  • Client libraries?\nDoes it require driver libraries?\n
  • What access patterns do you have today? Tomorrow?\nWhat kind of reports will customers or management require?\n
  • For us at Hitta.se this is important since almost everything we do is HTTP based\n
  • What kinds of availability?\nHow does it handle node failures? Network partitions?\n
  • How and with what?\n
  • Does performance scale with additional nodes?\n
  • What’s required to add additional nodes?\nHow do you remove a node temporarily or permanently?\n
  • \n
  • \n
  • Proper install packages?\nSane defaults in terms of service accounts and privileges?\n
  • Don’t underestimate this\n
  • Is your data really durable on disk -- assuming that’s what you need\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • For us, so far, the answer has been Riak & CouchDB\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Append only disk structures\n
  • \n
  • \n
  • Important for us as it requires no “drivers” and allows us to serve binary+mime\nNo, I don’t like WS-*\n
  • Important for us as it requires no “drivers” and allows us to serve binary+mime\nNo, I don’t like WS-*\n
  • Important for us as it requires no “drivers” and allows us to serve binary+mime\nNo, I don’t like WS-*\n
  • Important for us as it requires no “drivers” and allows us to serve binary+mime\nNo, I don’t like WS-*\n
  • Important for us as it requires no “drivers” and allows us to serve binary+mime\nNo, I don’t like WS-*\n
  • Important for us as it requires no “drivers” and allows us to serve binary+mime\nNo, I don’t like WS-*\n
  • \n
  • \n
  • \n
  • 2011 05-12 nosql-progressive.net

    1. 1. NoSQLMårten GustafsonProgressive.Net @ Valtech Stockholm 2011-05-12
    2. 2. Not Only SQL
    3. 3. “NoSQL is a movement promoting a looselydefined class of non-relational data storesthat break with a long history of relationaldatabases” - Wikipedia
    4. 4. “NoSQL is a movement promoting a looselydefined class of non-relational data storesthat break with a long history of relationaldatabases” - Wikipedia• Not one single technique
    5. 5. “NoSQL is a movement promoting a looselydefined class of non-relational data storesthat break with a long history of relationaldatabases” - Wikipedia• Not one single technique• Not one type of data
    6. 6. “NoSQL is a movement promoting a looselydefined class of non-relational data storesthat break with a long history of relationaldatabases” - Wikipedia• Not one single technique• Not one type of data• Not one type of use case
    7. 7. The way I see it
    8. 8. Families• Graph• Key/Value• Document
    9. 9. Flavors• Stand-alone• Distributed• Embedded
    10. 10. Flavors • Isolated instances are common • Might have slave replication• Stand-alone• Distributed• Embedded
    11. 11. Flavors • Isolated instances are common • Might have slave replication• Stand-alone• Distributed • “Cluster” is default mode of operation • No master node • Multiple nodes may fail without interrupting• Embedded service (implies storage distribution)
    12. 12. Disclaimer I don’t know any and all products by heart I’m trying to illustrate my broad reasoning
    13. 13. Example of my reasoningFlavor / Family Graph Key/Value Document CouchDB Stand alone Neo4J Redis MongoDB Riak Distributed Voldemort Cassandra Tokyo Cabinet Embedded Neo4J LevelDB
    14. 14. Example of my reasoningFlavor / Family Graph Key/Value Document CouchDB Stand alone Neo4J Redis MongoDB Riak Distributed Voldemort Cassandra Tokyo Cabinet Embedded Neo4J LevelDB
    15. 15. Example of my reasoningFlavor / Family Graph Key/Value Document CouchDB Stand alone Neo4J Redis MongoDB Riak Distributed Voldemort Cassandra Tokyo Cabinet Embedded Neo4J LevelDB
    16. 16. Example of my reasoningFlavor / Family Graph Key/Value Document CouchDB Stand alone Neo4J Redis MongoDB Riak Distributed Voldemort Cassandra Tokyo Cabinet Embedded Neo4J LevelDB
    17. 17. priorities & trade-offs
    18. 18. Does it fit with current data structures?
    19. 19. Ease of adoption?
    20. 20. Indices or some sort of search?
    21. 21. Does it speak HTTP?
    22. 22. Availability and redundancy?
    23. 23. Can you monitor it?
    24. 24. Performance?
    25. 25. Ease of scaling in and out?
    26. 26. Commercial support available?
    27. 27. Does it run on your preferred OS?
    28. 28. Is it properly packaged?
    29. 29. Do you understand it?
    30. 30. Can you kill it without loosing data?
    31. 31. For example...• I work at Hitta.se• We love availability• We like “easy” scalability
    32. 32. For example...• I work at Hitta.se• We love availability• We like “easy” scalability
    33. 33. availability +scalability
    34. 34. availability + scalability =multi-master
    35. 35. availability + scalability =storage distribution
    36. 36. availability +scalability =replication
    37. 37. availability + scalability =add & remove nodes
    38. 38. availability + scalability =tune behavior per use case
    39. 39. availability +scalability = ?
    40. 40. availability + scalability =Riak & CouchDB
    41. 41. RiakCouchDB
    42. 42. Dynamo inspiredkey / value store Riak CouchDB
    43. 43. Dynamo inspiredkey / value store Riak Document database CouchDB
    44. 44. Dynamo inspiredkey / value store Data that must be available as soon as possible on all nodes Riak Document database CouchDB
    45. 45. Dynamo inspired key / value store Data that must be available as soon as possible on all nodes Riak DocumentData that changes less databasefrequently and is ok to replicate “manually” CouchDB
    46. 46. Dynamo inspired key / value store Data that must be available as soon as Data that possible on all nodes require storage distribution Riak DocumentData that changes less databasefrequently and is ok to replicate “manually” CouchDB
    47. 47. Dynamo inspired key / value store Data that must be available as soon as Data that possible on all nodes require storage distribution Riak DocumentData that changes less databasefrequently and is ok to replicate “manually” CouchDB Data that might be local to a single node
    48. 48. Common factors Riak & CouchDB Good packaging
    49. 49. Common factors Riak & CouchDB Monitorable (lots of stats)
    50. 50. Common factors Riak & CouchDB Easy configuration
    51. 51. Common factors Riak & CouchDB Reliable
    52. 52. Common factors Riak & CouchDB HTTP API
    53. 53. Common factors Riak & CouchDB They embrace HTTP
    54. 54. All your webish skillz and tools apply...
    55. 55. language-, platform- and OS-neutralload balancers proxies MIME / Content-Type All your webish skillz and tools apply... HTTP client libs (etag, if-modified-since, etc) caches
    56. 56. Common factors Riak & CouchDBAble to store and serve complete web apps
    57. 57. Go do!• Test one or more NoSQL thingys• Get familiar with Brewers CAP theorem• Get familiar with the Dynamo paper
    58. 58. Thx.Mårten Gustafson@martengustafsonhttp://marten.gustafson.pp.se/marten.gustafson@gmail.com

    ×