NoSQL overview

Implementation free
Benoit Perroud 21. January 2011, 01. March 2011

Disclaimer

Any views or opinions presented in this presentation are solely those of the author and do not necessarily represent those of Verisign.

Outline
Introduction Scalability and Availability Difficulties to scale CAP Theorem NoSQL Goals NoSQL Taxonomy Concepts and Patterns Existing implementations NoSQL in the Real World Conclusion

Introduction

NoSQL Term
Mandatory name disambiguation : NoSQL stands for Not Only SQL. The term NoSQL is more or less attributed to Eric Evans, a Rackspace employee, who used it in early 2009 when Johan Oskarsson, a Last.fm employee, wanted to organize an event to discuss open-source distributed databases.

Wikipedia Definition
[Wikipedia] NoSQL is a term used to designate database management systems that differ from classic relational database management systems (RDBMS) in some way. These data stores may not require fixed table schemas, usually avoid join operations, do not attempt to provide ACID (atomicity, consistency, isolation, durability) properties and typically scale horizontally.

Tag Cloud

Why NoSQL ?
Is there really a problem with SQL and RDBMS ?

No there isn't !
SQL is powerful, ACID (atomicity, consistency, isolation, durability) properties are well-established, developers and DBAs have dominated it.

So why the hell need we NoSQL ? What was the motivations of Google and Amazon to invest huge amount in research around NoSQL ? Why social sites are so hard to scale ?

Scalability and Availability

Scalability definition
[Wikipedia] Scalability is a desirable property of a system, a network, or a process, which indicates its ability to either handle growing amounts of work in a graceful manner or to be readily enlarged. In summary : handle load and peaks. Scalability in two dimensions :
Scale up scale vertically (increase RAM in an existing node) Scale out scale horizontally (add a node to the cluster)

10

Availability definition
[Wikipedia] Availability refers to the ability of the users to access and use the system. If a user cannot access the system, it is said to be unavailable. Generally, the term downtime is used to refer to periods when a system is unavailable. In summary : minimize downtime.

Availability % 90% ("one nine") 95% 99% ("two nines") 99.9% ("three nines") 99.99% ("four nines") 99.999% ("five nines") 99.9999% ("six nines")

Downtime per year 36.5 days 18.25 days 3.65 days 8.76 hours 52.56 minutes 5.26 minutes 31.5 seconds

Downtime per month 72 hours 36 hours 7.20 hours 43.2 minutes 4.32 minutes 25.9 seconds 2.59 seconds

Downtime per week 16.8 hours 8.4 hours 1.68 hours 10.1 minutes 1.01 minutes 6.05 seconds 0.605 seconds

11

Difficulties to Scale

12

RDBMS Scalability
RDBMS are hard to scale. Hard should be understood as costly
RDBMS licenses, hardware, DBAs' and operational costs grow non linearly with the load.

RDBMS have either : single point of failure (SpoF)

the master DB

or replication latency
distributed transactions : two-phase commit, paxos algorithm.

13

Hardware Scalability
Commodity hardware and appliances are I/O bound
But network throughput is cheaper than hard disk throughput.

Hard disks is (was?) the main bottleneck in today's computing.

Random access have a high latency (disk seek) Throughput have increased, but not proportionally with the storage

Distributing data across a network of small computers (and applying the data locality concept) scale better (cheaper) than a huge appliance.

14

Pioneers in Scaling The Big

Google : huge amount of data (hundreds of petabytes, do not fit on a single appliance)
need to be partitioned MTBF is proportional to number of machines. BigTable.

Amazon : high availability (99.999%)

need to have redundancy and write scalability Dynamo

Facebook, Twitter, "social sites

no cluster of data to be partitioned, long tail (old data still time to time accessed), lots of users connected in the same time, user specific content (predictions hard to achieve, few static pages)

15

CAP Theorem

16

Remind of CAP theorem

Consistency : all nodes see the same data at the same time Availability : node failures do not prevent survivors from continuing to operate Partition Tolerance : the system continues to operate despite arbitrary message loss According to the theorem, a distributed system can satisfy any two of these guarantees at the same time, but not all three.

17

NoSQL trade-offs
NoSQL datastores have typically done other trade-offs than RDBMS to the CAP theorem
Most of them gave up the C of the theorem, giving up the ACID properties in the same way.

NoSQL datastores also have a more simpler data access pattern

value = get(key) put(key, value) remove(key)

18

NoSQL Goals

19

NoSQL promises
NoSQL finality is to achieve (horizontal) scalability and high availability.
Business goal : Keep cost growing proportionally with the load (tight provisioning). Operational goal :
Scale the system by simply adding node (or removing). The system runs on commodity hardware.

20

NoSQL Taxonomy

21

Taxonomy
NoSQL most common types are : Document store
store document which structure can be explored.

Key/value store
simple hash map data access pattern.

Column oriented store

Something between simple key/value and complex document store

Graph database
store node and edges, walk-through data access

Object database

22

Classification

23

Picture from http://blog.nahurst.com/visual-guide-to-nosql-systems

Concepts and Patterns

24

Implementation side : Consistent Hashing

[Wikipedia] Consistent hashing is a scheme that provides hash table functionality in a way that the addition or removal of one slot does not significantly change the mapping of keys to slots.

25

Picture from http://www.lexemetech.com/2007/11/consistent-hashing.html

Implementation side : Bloom Filter

[Wikipedia] Bloom filter is a space-efficient probabilistic data structure that is used to test whether an element is a member of a set.

26

Picture from http://en.wikipedia.org/wiki/File:Bloom_filter.svg

Implementation side : Quorum

[Wikipedia] A quorum is the minimum number of votes that a distributed transaction has to obtain in order to be allowed to perform an operation in a distributed system. A quorum-based technique is implemented to enforce consistent operation in a distributed system. Quorum : R + W > N
N : number of replica, R : number of node read, W : number of node written. R = 1, W = N R = N, W = 1 R = N/2, W = N/2 (+1 if N is even)

27

Implementation side : Vector Clocks

[Wikipedia] Vector Clocks is an algorithm for generating a partial ordering of events in a distributed system and detecting causality violations.

28

Picture from http://en.wikipedia.org/wiki/File:Vector_Clock.svg

Implementation side : other Common Concepts

Replication
Multi-master (Gossip, agents, P2P) Master-slave (+failover)

Merkle Tree
The main use of hash trees is to make sure that data blocks received from other peers in a peer-to-peer network are received undamaged and unaltered

Multiversion concurrency control

MVCC is a concurrency control method commonly used by database management systems to provide concurrent access to the database and in programming languages to implement transactional memory.

SEDA
Staged Event-Driven Architecture

LMT (Log Merge Tree)

Efficient replacement of B-Tree that require less disk seeks.

29

User side : Map Reduce

[Wikipedia] MapReduce is a framework for processing huge datasets on certain kinds of distributable problems using a large number of computers (nodes). It is inspired by the map and reduce functions commonly used in functional programming.

30

Picture from http://code.google.com/edu/parallel/mapreduce-tutorial.html

User side : Inverted Indexes

[Wikipedia] An inverted index is an index data structure storing a mapping from content, such as words or numbers, to its locations in a database file, or in a document or a set of documents. The purpose of an inverted index is to allow fast full text searches, at a cost of increased processing when a document is added to the database (data denormalization).

31

Picture from http://developer.apple.com/library/mac/

User side : other Patterns

Idempotent updates
Repeating the update twice do not lead to inconsistent data.

Offline (asynchronous) processing

Push on change (vs. pull on demand), batches

SOA and services isolation

Service failure resilience. Product is a mash-up of back-end services.

Schemaless (ColumnFamily-based data model)

Schema update is no more required

Data locality
Processing is sent to data instead of data sent do workers.

32

Existing Implementations

33

Non exhaustive list of Existing Implementations

Google BigTable, Megastore Amazon Dynamo, Apache Hbase, Apache Cassandra, Riak, Project Voldemort, Flockdb, Neo4j, Hypertable, Jackrabbit, Solr, ElsaticSearch, ... CouchDB, MongoDB, Tokyo Cabinet, SimpleDB, Redis, Memcached, Infinispan, Scalaris, Terrastore, Mysql HandlerSocket, Almost a new project every week ...

34

NoSQL in the Real World

35

Real World Example

Facebook new messaging system
Based on Hbase (consistency model simplier than Cassandra)

Amazon shopping cart

Based on Dynamo, never delete a row. Only add delta (+1, +2, -1) in the cart.

Twitter
Use Cassandra for real time analytics

Google Megastore
ACID within partitions, lower consistency across partitions Synchronous replication with Paxos algorithm

36

Real World Example (2)

Digg, Last.fm, NYT, Guardian, Yahoo, Flickr, NetFlix, Adobe, Mozilla, Github, Linkedin, StumbleUpon, ... MapReduce usage is increasing daily
Google and Amazon have sat their domination in being the first to masterize big data.

Can your business jump into the NoSQL wave ?

37

Conclusion

38

Conclusion
NoSQL is not a general purpose datastore !
Eventually consistent model can be tricky, and can reserve nasty surprises if not used carefully. MapReduce search job have high latency

SQL and NoSQL are complementary

Knowing both allow to put the right technology to the right place.

NoSQL has challenged RDBMS supremacy

New ideas for RDBMS are emerging See HandlerSocket, a mysql NoSQL plugin.

39

Thanks for listening Questions ?

Benoit Perroud bperroud@verisign.com @killerwhile on Twitter

40