NoSQL Databases: the Four Types, ACID vs. BASE & CAP

Why NoSQL exists

NoSQL ("Not only SQL") is a family of data stores *not based on the relational model*. It emerged to handle workloads where relational systems struggle: web-scale volume, highly variable/unstructured data, and the need to scale out (add cheap commodity servers) rather than scale up (buy one bigger server). The thing the exam wants you to remember about what NoSQL optimizes for is flexibility — *not* minimizing storage, *not* avoiding replication, and *not* normalization.

The four NoSQL types (memorize a product for each — this is Part B Q8a)

| Type | One example | What it stores | Sweet spot | |---|---|---|---| | Key-value | Redis (also Riak, DynamoDB) | a value (any bytes) under a unique key; only put/get/delete | caching, session state, simple lookups by known key | | Document | MongoDB (also Couchbase) | JSON/BSON documents whose internal fields are queryable | content management, catalogs, flexible schemas | | Wide-column | Cassandra (also HBase) | rows that may each have a different set of columns, grouped in column families | massively distributed, highly scalable semi-structured data | | Graph | Neo4j | nodes (with properties) connected by relationships (edges) | social networks, recommendations, fraud detection — relationship traversal |

Key-value is the *fastest and simplest* but cannot query on a value's contents. Document stores add queries on nested fields. Wide-column excels at distribution. Graph is unique for *highly connected* data where traversing relationships is the main query. Most NoSQL systems do not support joins — relationships are handled by *embedding* related data or by application-level lookups.

ACID vs. BASE

Relational databases give you ACID transactions (Atomic, Consistent, Isolated, Durable) — strong guarantees that every transaction leaves the database valid. Most NoSQL systems trade some of that away for availability and scale, following BASE:

- Basically Available — the system answers requests (possibly with stale data) rather than failing. - Soft state — state may change over time even without new input, as replicas reconcile. - Eventually consistent — replicas converge to the same value *eventually*, not instantly.

Worked example: applying the CAP theorem

Brewer's CAP theorem says a *distributed* system can guarantee at most two of three properties:

- Consistency — every node sees the same data at the same time. - Availability — every request gets a (non-error) response. - Partition tolerance — the system keeps working when the network splits.

Because network partitions are unavoidable at scale, real systems must keep P and then choose between C and A:

Network splits a 3-node cluster into {A} and {B,C}.
 A write arrives on node A.
 CP choice: refuse the write on {B,C} until the split heals  -> consistent, NOT available
 AP choice: accept writes on both sides, reconcile later        -> available, NOT consistent (yet)

Traditional relational databases lean CA (consistent + available, assuming no partition); most NoSQL stores lean AP (available + partition-tolerant, accepting eventual consistency). This is *why* NoSQL is not "better" than relational — it is tuned for a different point on the trade-off triangle.