NoSQL

[ ]

NoSQL is a collection of data items represented in a key-value store, document store, wide column store, or a graph database. Data is denormalized, and joins are generally done in the application code. Most NoSQL stores lack true ACID transactions and favor eventual consistency.

BASE is often used to describe the properties of NoSQL databases. In comparison with the CAP Theorem, BASE chooses availability over consistency.

• Basically available - the system guarantees availability.
• Soft state - the state of the system may change over time, even without input.
• Eventual consistency - the system will become consistent over a period of time, given that the system doesn’t receive input during that period.

Key-value store

A key-value store generally allows for O(1) reads and writes. Data stores can maintain keys in lexicographic order, allowing efficient retrieval of key ranges.

Key-value stores provide high performance and are often used for simple data models or for rapidly-changing data, such as an in-memory cache layer.

Examples:

• redis
• memcache

Document store

A document store is centered around documents (XML, JSON, binary, etc), where a document stores all information for a given object. Document stores provide APIs or a query language to query based on the internal structure of the document itself.

Document stores provide high flexibility and are often used for working with occasionally changing data.

Examples:

• MongoDB
• CouchDB
• DocumentDB
• ElasticSearch

Wide column store

A wide column store’s basic unit of data is a column (name/value pair). A column can be grouped in column families (analogous to a SQL table). Super column families further group column families. You can access each column independently with a row key, and columns with the same row key form a row. Each value contains a timestamp for versioning and for conflict resolution.

Wide column stores offer high availability and high scalability. They are often used for very large data sets.

Examples:

• BigTable
• HBase
• Cassandra

Graph database

In a graph database, each node is a record and each arc is a relationship between two nodes. Graph databases are optimized to represent complex relationships with many foreign keys or many-to-many relationships.

Graphs databases offer high performance for data models with complex relationships, such as a social network.

Examples:

• neo4j
• FlockDB

SQL or NoSQL

Reasons for SQL:

• Structured data
• Strict schema
• Relational data
• Need for complex joins
• Transactions
• Clear patterns for scaling
• More established: developers, community, code, tools, etc
• Lookups by index are very fast

Reasons for NoSQL:

• Semi-structured data
• Dynamic or flexible schema
• Non-relational data
• No need for complex joins
• Store many TB (or PB) of data
• Very data intensive workload
• Very high throughput for IOPS

Written on March 30, 2019