Why NoSQL
   isn’t NO SQL
by Tim Berglund and Matthew McCullough
Data Scale
Gigabyte
Terabyte
Petabyte
10s of Petabytes
Transaction Volume
Pedestrian data
   volumes
Just be lazy
Wait for a faster CPU!
Wait for a faster hard
        drive!
Wait for faster RAM!
Can’t be lazy anymore
More reads, less writes
More writes, less reads
Eventually consistent
ACID
The lies SQL tells you...
Memory is good
Precomputation is good
Normalization is good
Duplicating data is bad
CAP Theorem
2000, Eric Brewer
MIT CS
Want three...
Consistency
Availability
Partition tolerance
Can have two...
Proven to be the case
NoSQL Personalities
Structured
Semi-structure
Unstructured
The Players
Column Oriented
     Store
Key Value Store
Document Database
Not Only SQL
Re-examine
requirements
Which piece needs to
      be fast?
What part needs to be
  highly available?
Which part needs
extreme scalability?
Life as an architect is
    getting harder
Now you’re responsible
for knowing about and
    making tradeoffs
Lets you say Petabyte
And that makes you
       cool
Thanks for listening
http://delicious.com/matthew.mccullough/nosql
• http://blog.nahurst.com/visual-guide-to-
  nosql-systems

• http://nosql.mypopescu.com/
• http://delicious.com/matthew.m...
NoSQL isn't NO SQL
NoSQL isn't NO SQL
NoSQL isn't NO SQL
NoSQL isn't NO SQL
NoSQL isn't NO SQL
NoSQL isn't NO SQL
NoSQL isn't NO SQL
NoSQL isn't NO SQL
NoSQL isn't NO SQL
NoSQL isn't NO SQL
NoSQL isn't NO SQL
Upcoming SlideShare
Loading in...5
×

NoSQL isn't NO SQL

2,227

Published on

Matthew McCullough's and Tim Berglund's presentation on a survey of NoSQL tools to the Denver Open Source Users Group

Published in: Education
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,227
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

NoSQL isn't NO SQL

  1. 1. Why NoSQL isn’t NO SQL by Tim Berglund and Matthew McCullough
  2. 2. Data Scale
  3. 3. Gigabyte
  4. 4. Terabyte
  5. 5. Petabyte
  6. 6. 10s of Petabytes
  7. 7. Transaction Volume
  8. 8. Pedestrian data volumes
  9. 9. Just be lazy
  10. 10. Wait for a faster CPU!
  11. 11. Wait for a faster hard drive!
  12. 12. Wait for faster RAM!
  13. 13. Can’t be lazy anymore
  14. 14. More reads, less writes
  15. 15. More writes, less reads
  16. 16. Eventually consistent
  17. 17. ACID
  18. 18. The lies SQL tells you...
  19. 19. Memory is good
  20. 20. Precomputation is good
  21. 21. Normalization is good
  22. 22. Duplicating data is bad
  23. 23. CAP Theorem
  24. 24. 2000, Eric Brewer
  25. 25. MIT CS
  26. 26. Want three...
  27. 27. Consistency Availability Partition tolerance
  28. 28. Can have two...
  29. 29. Proven to be the case
  30. 30. NoSQL Personalities
  31. 31. Structured
  32. 32. Semi-structure
  33. 33. Unstructured
  34. 34. The Players
  35. 35. Column Oriented Store
  36. 36. Key Value Store
  37. 37. Document Database
  38. 38. Not Only SQL
  39. 39. Re-examine requirements
  40. 40. Which piece needs to be fast?
  41. 41. What part needs to be highly available?
  42. 42. Which part needs extreme scalability?
  43. 43. Life as an architect is getting harder
  44. 44. Now you’re responsible for knowing about and making tradeoffs
  45. 45. Lets you say Petabyte
  46. 46. And that makes you cool
  47. 47. Thanks for listening
  48. 48. http://delicious.com/matthew.mccullough/nosql
  49. 49. • http://blog.nahurst.com/visual-guide-to- nosql-systems • http://nosql.mypopescu.com/ • http://delicious.com/matthew.mccullough/ nosql • http://refcardz.dzone.com/refcardz/getting- started-nosql-and-data

×