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

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

2011 05-12 nosql-progressive.net

965
views

Published on

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

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
965
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
11
Comments
0
Likes
1
Embeds 0
No embeds

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