NoSQL
Now we know what it’s not... what is it?
What are we running
from?
• Relational databases are the defacto
standard for storing data in a web
application.
• A lot o...
Rules? What Rules?
• Classic relational databases follow the
ACID rules:
• Atomicity
• Consistency
• Isolation
• Durability
Atomicity
• If any part of the update fails, it all fails.
• Databases have to be able to lock tables
and rows for operati...
Consistency
• After a transaction, all copies of the data
must be consistent with each other (my
interpretation).
• Replic...
Isolation
• Data involved in a transaction must be
inaccessible to other operations.
• Remember the thing about locked row...
Durability
• Once a user is notified that a transaction
has completed, the data must be accessible
and all integrity constr...
I come not to bury
MySQL...
• Relational databases are great for a lot of
uses.
• If you have data that’s actually relatio...
But...
• RDBMS’s have been
treated like hammers
and used for things
they’re not good at and
weren’t designed for.
• Like t...
Thus were born...
• Key-Value Stores
• Wide-Column Stores
• Document Stores/Databases
• Graph Databases
All thrown together &
clumsily dubbed...
NoSQL
Which, despite it’s
negative sound,
supposedly means:
“Not Only SQL”
Yeah, I don’t believe it
either...
Key-Value
Just what it sounds like. You set a Key to aValue and
can then retrieve it.
Key-Value Benefits
• Simple
• High performance (usually) because there
are no transactions or relations so it’s a
simple bu...
Popular Players
• memcached - in memory only, extremely
efficient hashing algorithm allows you to
scale easily to hundreds ...
My Uses
• memcached: Read-through cache for
Rails with cache-money.
• redis: persistent cache for results from
our algorit...
Wide Column
• Family of databases modeled on either
Google’s BigTable or Amazon’s Dynamo.
• Pick two out of three from the...
CAP?
• Consistency:All clients always have the
same view of the data.
• Availability: Each client can always read
and writ...
Use cases
• Making sense out of large amounts of data
where you know your query scenario
ahead of time.
• Large = 100s of ...
Big Players
• HBase
• Cassandra
• Hypertable
• Amazon’s SimpleDB
• Google’s BigTable (the granddaddy of all of
them)
Graph Databases
• Store nodes, edges and properties
• Think of them as Things, Connections and
Properties
• Good for stori...
The Players
• Neo4j
• FlockDB
• HyperGraphDB
Document Stores
• Short on relationships, tall on rich data
types.
• Big on eventual consistency and flexible
schemas.
• Hy...
Use Cases
• Content Management Systems
• Applications with rapid partial updates
• Anything you don’t need joins or
transa...
The Players
• CouchDB
• MongoDB
• Terrastore
MongoDB
• Support for rich data types: arrays, hashes,
embedded documents, etc
• Support for adding and removing things
fr...
Design Considerations
• Embedded Documents - Use only if it
the embedded document will always be
selected with the parent....
Real-World MongoDB
• We use MongoDB heavily at MIS.
• Statistics application and reporting
• Top-secret new application
• ...
Real-World Example
Let’s do tags. Everything is taggable now, right?
The MySQL Way
Schema
And to get a “thing’s”
tags?
SELECT `tags`.* FROM `tags`
INNER JOIN `taggings` ON `tags`.id = `taggings`.tag_id
WHERE ((`t...
Yuck!
That’s a lot of pain for something so simple.
And I didn’t even show you finding things with tag “x”.
Or how to set a...
The MongoDB Way
Using MongoMapper and Rails 3
class Post
include MongoMapper::Document
key :title, String
key :body, String
key :tags, Array
ensure_index :tags
end
Let’s Make This Easy...
def add_tag(tag)
tag = Post.clean_tag(tag)
self.tags << tag
self.add_to_set(:tags => tag) unless s...
Demo Time
Sorry if you’re looking at this later, but it’s console time!
Why I Love MongoDB
• Document model fits how I build web apps.
• For most apps, I don’t need transactions.
• Eventual consi...
What’s NoSQL, really?
• The right tool for the job.
• We’ve got lots of options for storing
application data.
• The key is...
Questions?
Further Reading
• Visual NoSQL: http://blog.nahurst.com/
visual-guide-to-nosql-systems
• MongoDB: http://mongodb.org
• Mon...
Thanks!
• Kevin Lawver
• @kplawver
• kevin@lawver.net
• http://kevinlawver.com
Upcoming SlideShare
Loading in …5
×

NoSQL - We know what it isn't, but what is it?

1,066 views

Published on

A presentation given at Refresh Savannah on the wonderful world of NoSQL, what it includes, what it means and where using new-style databases makes sense. There's also a demo that contrasts doing tags with MongoDB vs. doing it with a traditional RDBMS.

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

  • Be the first to like this

No Downloads
Views
Total views
1,066
On SlideShare
0
From Embeds
0
Number of Embeds
77
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

NoSQL - We know what it isn't, but what is it?

  1. 1. NoSQL Now we know what it’s not... what is it?
  2. 2. What are we running from? • Relational databases are the defacto standard for storing data in a web application. • A lot of times, that data isn’t really relational at all. • RDBMS’s have lots of rules that can impact performance.
  3. 3. Rules? What Rules? • Classic relational databases follow the ACID rules: • Atomicity • Consistency • Isolation • Durability
  4. 4. Atomicity • If any part of the update fails, it all fails. • Databases have to be able to lock tables and rows for operations, which can block or delay other incoming requests.
  5. 5. Consistency • After a transaction, all copies of the data must be consistent with each other (my interpretation). • Replication across lots of shards is expensive especially if there’s locking involved.
  6. 6. Isolation • Data involved in a transaction must be inaccessible to other operations. • Remember the thing about locked rows and tables? • It’s a bummer.
  7. 7. Durability • Once a user is notified that a transaction has completed, the data must be accessible and all integrity constraints have been met.
  8. 8. I come not to bury MySQL... • Relational databases are great for a lot of uses. • If you have data that’s actually relational and you need transactions, joins and have a limited number of data types, then an RDBMS will work for you.
  9. 9. But... • RDBMS’s have been treated like hammers and used for things they’re not good at and weren’t designed for. • Like the web...
  10. 10. Thus were born... • Key-Value Stores • Wide-Column Stores • Document Stores/Databases • Graph Databases
  11. 11. All thrown together & clumsily dubbed...
  12. 12. NoSQL
  13. 13. Which, despite it’s negative sound, supposedly means: “Not Only SQL”
  14. 14. Yeah, I don’t believe it either...
  15. 15. Key-Value Just what it sounds like. You set a Key to aValue and can then retrieve it.
  16. 16. Key-Value Benefits • Simple • High performance (usually) because there are no transactions or relations so it’s a simple bucket and lookup. • Extremely flexible • Commonly used as caches in front of slower resources (like MySQL - bazinga!)
  17. 17. Popular Players • memcached - in memory only, extremely efficient hashing algorithm allows you to scale easily to hundreds of nodes. • Redis - persistent, slightly more complex than memcached (has support for arrays) but still highly performant. • Riak - The Rails Machine guys love it. Jesse?
  18. 18. My Uses • memcached: Read-through cache for Rails with cache-money. • redis: persistent cache for results from our algorithm, partitioned by version and instance.
  19. 19. Wide Column • Family of databases modeled on either Google’s BigTable or Amazon’s Dynamo. • Pick two out of three from the CAP theorem in order to get horizontal scalability. • Data stored by column instead of by row.
  20. 20. CAP? • Consistency:All clients always have the same view of the data. • Availability: Each client can always read and write. • Partition Tolerance:The system works well despite physical network partitions
  21. 21. Use cases • Making sense out of large amounts of data where you know your query scenario ahead of time. • Large = 100s of millions of records. • Data-mining log files and other sources of similar data.
  22. 22. Big Players • HBase • Cassandra • Hypertable • Amazon’s SimpleDB • Google’s BigTable (the granddaddy of all of them)
  23. 23. Graph Databases • Store nodes, edges and properties • Think of them as Things, Connections and Properties • Good for storing properties and relationships. • Honestly, I don’t fully understand them... anyone?
  24. 24. The Players • Neo4j • FlockDB • HyperGraphDB
  25. 25. Document Stores • Short on relationships, tall on rich data types. • Big on eventual consistency and flexible schemas. • Hybrid of traditional RDBMS and Key-Value stores.
  26. 26. Use Cases • Content Management Systems • Applications with rapid partial updates • Anything you don’t need joins or transactions for that you would normally use a RDBMS for.
  27. 27. The Players • CouchDB • MongoDB • Terrastore
  28. 28. MongoDB • Support for rich data types: arrays, hashes, embedded documents, etc • Support for adding and removing things from arrays and embedded documents (addToSet, for example). • Map/Reduce support and strong indexes • Regular expression support in queries
  29. 29. Design Considerations • Embedded Documents - Use only if it the embedded document will always be selected with the parent. • Indexes - MongoDB punishes you much earlier for missing indexes than MySQL. • Document size - Currently, documents are limited to 4MB, which should be large enough, but if it’s not...
  30. 30. Real-World MongoDB • We use MongoDB heavily at MIS. • Statistics application and reporting • Top-secret new application • Web crawler and indexer • CMS
  31. 31. Real-World Example Let’s do tags. Everything is taggable now, right?
  32. 32. The MySQL Way
  33. 33. Schema
  34. 34. And to get a “thing’s” tags? SELECT `tags`.* FROM `tags` INNER JOIN `taggings` ON `tags`.id = `taggings`.tag_id WHERE ((`taggings`.taggable_id = 237) AND (`taggings`.taggable_type = 'Song'))
  35. 35. Yuck! That’s a lot of pain for something so simple. And I didn’t even show you finding things with tag “x”. Or how to set and unset tags on a “thing”. Ouch.
  36. 36. The MongoDB Way Using MongoMapper and Rails 3
  37. 37. class Post include MongoMapper::Document key :title, String key :body, String key :tags, Array ensure_index :tags end
  38. 38. Let’s Make This Easy... def add_tag(tag) tag = Post.clean_tag(tag) self.tags << tag self.add_to_set(:tags => tag) unless self.new_record? end def remove_tag(tag) tag = Post.clean_tag(tag) self.tags.delete(tag) self.pull(:tags => tag) unless self.new_record? end def self.clean_tag(str) str.strip.downcase.gsub(" ","-").gsub(/[^a-z0-9-]/,"") end def self.clean_tags(str) out = [] arr = str.split(",") arr.each do |t| out << self.clean_tag(t) end out end
  39. 39. Demo Time Sorry if you’re looking at this later, but it’s console time!
  40. 40. Why I Love MongoDB • Document model fits how I build web apps. • For most apps, I don’t need transactions. • Eventual consistency is actually OK. • Partial updates and arrays make things that are a pain in SQL-land absolutely painless. • It’s just smart enough without getting in the way.
  41. 41. What’s NoSQL, really? • The right tool for the job. • We’ve got lots of options for storing application data. • The key is picking the one that solves our real problem. • And if an RDBMS is the right tool, that’s OK too.
  42. 42. Questions?
  43. 43. Further Reading • Visual NoSQL: http://blog.nahurst.com/ visual-guide-to-nosql-systems • MongoDB: http://mongodb.org • MongoMapper: http://mongomapper.com/
  44. 44. Thanks! • Kevin Lawver • @kplawver • kevin@lawver.net • http://kevinlawver.com

×