2011 05-12 nosql-progressive.net
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

2011 05-12 nosql-progressive.net

  • 1,138 views
Uploaded on

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

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,138
On Slideshare
783
From Embeds
355
Number of Embeds
4

Actions

Shares
Downloads
11
Comments
0
Likes
1

Embeds 355

http://mj89sp3sau2k7lj1eg3k40hkeppguj6j-a-sites-opensocial.googleusercontent.com 352
http://www.slideshare.net 1
url_unknown 1
http://www.techgig.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    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

Transcript

  • 1. NoSQLMårten GustafsonProgressive.Net @ Valtech Stockholm 2011-05-12
  • 2. Not Only SQL
  • 3. “NoSQL is a movement promoting a looselydefined class of non-relational data storesthat break with a long history of relationaldatabases” - Wikipedia
  • 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. “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. “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. The way I see it
  • 8. Families• Graph• Key/Value• Document
  • 9. Flavors• Stand-alone• Distributed• Embedded
  • 10. Flavors • Isolated instances are common • Might have slave replication• Stand-alone• Distributed• Embedded
  • 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. Disclaimer I don’t know any and all products by heart I’m trying to illustrate my broad reasoning
  • 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. 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. 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. 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. priorities & trade-offs
  • 18. Does it fit with current data structures?
  • 19. Ease of adoption?
  • 20. Indices or some sort of search?
  • 21. Does it speak HTTP?
  • 22. Availability and redundancy?
  • 23. Can you monitor it?
  • 24. Performance?
  • 25. Ease of scaling in and out?
  • 26. Commercial support available?
  • 27. Does it run on your preferred OS?
  • 28. Is it properly packaged?
  • 29. Do you understand it?
  • 30. Can you kill it without loosing data?
  • 31. For example...• I work at Hitta.se• We love availability• We like “easy” scalability
  • 32. For example...• I work at Hitta.se• We love availability• We like “easy” scalability
  • 33. availability +scalability
  • 34. availability + scalability =multi-master
  • 35. availability + scalability =storage distribution
  • 36. availability +scalability =replication
  • 37. availability + scalability =add & remove nodes
  • 38. availability + scalability =tune behavior per use case
  • 39. availability +scalability = ?
  • 40. availability + scalability =Riak & CouchDB
  • 41. RiakCouchDB
  • 42. Dynamo inspiredkey / value store Riak CouchDB
  • 43. Dynamo inspiredkey / value store Riak Document database CouchDB
  • 44. Dynamo inspiredkey / value store Data that must be available as soon as possible on all nodes Riak Document database CouchDB
  • 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. 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. 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. Common factors Riak & CouchDB Good packaging
  • 49. Common factors Riak & CouchDB Monitorable (lots of stats)
  • 50. Common factors Riak & CouchDB Easy configuration
  • 51. Common factors Riak & CouchDB Reliable
  • 52. Common factors Riak & CouchDB HTTP API
  • 53. Common factors Riak & CouchDB They embrace HTTP
  • 54. All your webish skillz and tools apply...
  • 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. Common factors Riak & CouchDBAble to store and serve complete web apps
  • 57. Go do!• Test one or more NoSQL thingys• Get familiar with Brewers CAP theorem• Get familiar with the Dynamo paper
  • 58. Thx.Mårten Gustafson@martengustafsonhttp://marten.gustafson.pp.se/marten.gustafson@gmail.com