NoSQL - Channeling the Data Explosion

In this presentation Dwight Merriman, of 10Gen, explains NoSQL's role in dealing with the explosion of data.

So why NoSQL?

• One size no longer fits all
• Computing power is now considered a commodity
• Horizontal scaling

An interesting point that Merriman makes is the comparisons of the various NoSQL data stores in how they are alike and different. Outside of the type of data store i.e. Key/Value, Column, Graph, etc. I haven't put a lot of thought into this point. Well what does Merriman have to say?

• What's the same between NoSQL products?
  • No joins
  • No complex transactions
• What's different?
  • Scale out model
  • Consistency model
  • Data model

Merriman continues his discussion by talking about data models, influences, CAP and consistency. Finally, he provides some predictions about NoSQL.

• JSON will be the most popular building block for non-relational data models
• Tunable consistency
• Some SQL in NoSQL data stores.

Cassandra: Replication and Consistency

In this presentation, by Benjamin Black, we get an introduction to Cassandra's replication and consistency model. Black provides us with a very concise and easily understood definition of both replication and consistency.

Replication. How many copies of the data do we want in the system?

Consistency Level. How many replicas must respond to declare success?

In addition, to providing us with good definitions Black proceeds to discuss a number of topics. Including partitioning, snitching and placement. Essentially, it provides a good high level intro to some very low level concepts of Cassandra.

Eventual Consistency - Revisited

Werner Vogels, the CTO of Amazon, wrote a fascinating piece on eventual consistency. If you recall, consistency, is one the three properties of the CAP theorem. In his post Werner discusses an ideal world where there is only a single consistency model:

when an update is made all observers would see that update

Werner provides us with an historical perspective of how folks discovered that this was actually something that was pretty hard to do. Werner dives in more and discusses how consistency is viewed from the clients perspective and from the server perspective.

Werner, describes eventual consistency as:

a specific form of weak consistency; the storage system guarantees that if no new updates are made to the object, eventually all accesses will return the last updated value. If no failures occur, the maximum size of the inconsistency window can be determined based on factors such as communication delays, the load on the system, and the number of replicas involved in the replication scheme.

There are more details about various types of weak consistencies and a brief mention of Amazon's Dynamo key/value data store. It's a great read.

Eventually Consistent - Revisited

Project Voldemort Scaling Simple Storage At LinkedIn

The data store whose name is inspired by he who shall not be named is actually the brainchild of LinkedIn. In this presentation by Jay Kreps he walks us through the following:

• LinkedIn's motivations for creating Voldemort.
• Core concepts that are key to understanding Voldemort, i.e. CAP, Consistency Models, Partitioning, etc.
• Implementation details such as client API, versioning, serialization and routing to name a few.
• How Voldemort is being used at LinkedIn
• The results of deploying Voldemort withing LinkedIn, some performance numbers, weaknesses and upcoming features.

The presentation provides a clear concise review of several core concepts that are relevant in almost all NoSQL data stores. In addition, the presentation provides a helpful introduction to Voldemort.