Download - Some NoSQL
So to scale you have to drop consistency
which means some stale data is ok. that is a compromise. A risk to be taken and considered.
Basic Availability Soft-state Eventual consistency
details here : http://www.cs.berkeley.edu/~brewer/cs262b-2004/PODC-keynote.pdf
You drop Consistency for Eventual Consistency
That is the most important change for scaling purposes
So if Relational implies ACID and ACID does not
scale?then: relational databases do not scale, right?
"If all you have is a hammer, everything looks
like a nail"Abraham Maslow, The Psychology of Science, 1966, p.
15
Database (Complex Algorithms)
SQL Interpreter
SQL Generation (souped up concatenation)
Database Abstraction Layer (avoid lock in)
Model Translator (ORM usually)
Model Logic (the M in MVC)
Your App
Several data representations!
● Key-Value● Document● Column-Family● Graph● XML-bases● Object● Grid● mixed (using several types)● etc.
Key-Value Datastore: What is it?
You store keys (identifiers) and values (pretty much anything, serialized)
Just a quick way to store things under a name and recover them using that name.
Key-Value Datastore: When to use?
● Dictionaries● Session data● User preferences● Shopping cart● Anything whose content you do not want to
scry or query.
Key-Value Datastore: When to avoid?
● You have relations● You have multi-operational transactions● You want to query the values● You want to operate on sets of entries
Document Datastore: What is it?
As with the key-value, but your data is not amorph is a document!
Each document behaves like an Hash-table, it has entries of a given kind that may themselves have entries (like a xml or json file).
documents are schemaless, you have complete liberty of what goes inside them.
Document Datastore: When to use?
● When you have documents!○ Blogs○ CMS
● When freedom of schema is required○ Analytics○ E-commerce products
● When you wanted a key-value but wanted to query the values.
Document Datastore: When to avoid?
● You need complex/atomic transactions over different documents○ in that case you may have a relation, you may need
sql after all!● The schema-free usage render your queries
impossible.● You want to force a schema.
Column-Family Datastore:What is it?
Data in tables of rows and columns like the relational model but:● Each row has a varying number of columns
(hence the name)● Each row is timestamped for comparison,
expiring and conflict resolution.● There is no master node; writing can be
scaled by adding nodes.● A column may contain another row.
Column-Family Datastore:When to use it?
● Logging● Registering events● Counters● when you have massive concurrent writes
with small chances of collisions (facebook uses for their internal messaging system)
● when your information has a due date
Column-Family Datastore:When to avoid it?
● You need ACID● You need aggregate results (sums,
averages, etc)● Your data is not tabular
Graph Datastore: What is it?
Data is represented by nodes (objects) connected by vertices (relations).
The very school definition of a graph.
The same data can represent several graphs.
Graph traversal may be persisted as a relation.
Graph Datastore: When to use it?
Anywhere you should already be using Graphs on your application:● Any relations (in the relational model
sense) that have no data.● Social relations (friend of, employee, chief
of, etc)● Dependency● Geographical data● Routing, dispatching etc.
Graph Datastore: When to avoid it?
Your application writes over large sets of nodes commonly (writing to many nodes at once is expensive)
Your relations carry payloads (in that case you need sql)