← back to databases

NoSQL and Beyond

Wikipedia · wpNoSQL · CC BY-SA 4.0

NoSQL databases abandon the relational model when it does not fit. Four main types: key-value stores (Redis), document stores (MongoDB), column-family stores (Cassandra), and graph databases (Neo4j). The CAP theorem says you can have at most two of Consistency, Availability, and Partition tolerance.

Key-Value k1 -> v1 k2 -> v2 k3 -> v3 Document {"name":"A", "age": 30, "tags":[..]} Column cf1: a b c cf2: x y Graph Four NoSQL data models.

Key-value stores

The simplest model: a dictionary. Store and retrieve values by key. No schema, no query language beyond GET/SET/DELETE. Extremely fast for point lookups. Examples: Redis, DynamoDB, Riak.

Scheme

Document stores

Store semi-structured documents (JSON, BSON). Each document can have different fields. Queries can reach into nested structure. Good for heterogeneous data that does not fit a fixed schema. Examples: MongoDB, CouchDB.

Python

Graph databases

Store nodes and edges directly. Queries traverse relationships without expensive joins. Good for social networks, recommendation engines, knowledge graphs. Examples: Neo4j, Amazon Neptune.

Scheme

CAP theorem

The wpCAP theorem (wpBrewer, 2000): a distributed data store can satisfy at most two of three properties. Consistency (every read returns the latest write), Availability (every request gets a response), Partition tolerance (the system works despite network splits). In practice, partitions happen, so the real choice is between consistency and availability during a partition.

Scheme

Eventual consistency

AP systems trade strong consistency for availability. After a write, replicas may temporarily disagree. Given enough time without new writes, all replicas converge to the same value. This is eventual consistency. Many applications tolerate this: a social media timeline that is a few seconds stale is acceptable.

Python
Neighbors

Cross-references

Foundations (Wikipedia)