NoSQL / CAP Theorem

NoSQL (CAP Theorem)

Non-Relational Database & CAP Theorem

1. Overview of NoSQL and the CAP Theorem — A Theory Defining the Trade-off Among Three Properties of Distributed Systems

    flowchart LR
    A["Limits of relational DBs<br/>(volume, speed, unstructured<br/>data)"] --"Design choice based<br/>on the CAP theorem"--> B["Choose 2 of 3:<br/>C, A, P"] --"Optimize by<br/>data model"--> C["Adopt NoSQL to fit<br/>business requirements"]

    style A fill:#FFEBEE,stroke:#D32F2F,color:#000
    style B fill:#E3F2FD,stroke:#1976D2,color:#000
    style C fill:#E8F5E9,stroke:#388E3C,color:#000

Definition: NoSQL is a general term for non-relational databases that overcome the schema constraints and vertical-scaling limits of relational databases (RDBMS), while the CAP theorem proves that a distributed system cannot simultaneously guarantee all three of Consistency (C), Availability (A), and Partition tolerance (P).

Characteristics: (Choosing CP or AP) Per the CAP theorem, a distributed NoSQL system must choose either CP (consistency + partition tolerance) or AP (availability + partition tolerance). (Flexibility and scalability) Supports a flexible, schema-less design, horizontal scale-out, and high-performance reads/writes. (Diverse data models) Offers a choice of models — key-value, document, column-family, graph — to match the nature of the data.

2. Core Structure of NoSQL/CAP Theorem

A. Consistency, Availability, Partition Tolerance

    flowchart TD
    subgraph CAP["CAP Theorem (Brewer's Theorem)"]
        direction TB
        C["Consistency<br/>All nodes return<br/>the same data"]
        A["Availability<br/>Every request<br/>gets a response"]
        P["Partition Tolerance<br/>The system keeps running<br/>even if the network splits"]
    end

    CP["CP systems<br/>HBase, MongoDB<br/>ZooKeeper"]
    AP["AP systems<br/>Cassandra, DynamoDB<br/>CouchDB"]
    CA["CA systems<br/>RDBMS<br/>(not viable in a<br/>distributed setting)"]

    C --- CP
    P --- CP
    A --- AP
    P --- AP
    C --- CA
    A --- CA

    style C  fill:#E3F2FD,stroke:#1976D2,color:#000
    style A  fill:#E8F5E9,stroke:#388E3C,color:#000
    style P  fill:#FFF3E0,stroke:#F57C00,color:#000
    style CP fill:#1E3A5F,stroke:#1E3A5F,color:#fff
    style AP fill:#388E3C,stroke:#388E3C,color:#fff
    style CA fill:#f5f5f5,stroke:#ccc,color:#666

Property	Definition	Meaning in a Distributed Environment
C — Consistency	All nodes return the same data at the same time	A read after a write always returns the latest data
A — Availability	Every request receives a response (though it may not be the latest data)	The system keeps responding even during node failure
P — Partition Tolerance	The system continues to operate even when the network is partitioned	Essential in any real distributed environment — P cannot be sacrificed

Comparing CAP Combinations

Combination	Properties Guaranteed	Property Sacrificed	Representative Systems	Suitable Use Cases
CP	Consistency + partition tolerance	Availability	HBase, MongoDB, Redis	Financial transactions, inventory management
AP	Availability + partition tolerance	Consistency	Cassandra, DynamoDB	Social networking, IoT, log collection
CA	Consistency + availability	Partition tolerance	MySQL, PostgreSQL	Single-server transactions

B. Classification by Data Model

    flowchart TD
    subgraph R1["　"]
        direction LR
        KV["Key-Value Store<br/>Redis, DynamoDB<br/>Simple lookup/caching<br/>O(1) access"]
        DOC["Document Store<br/>MongoDB, CouchDB<br/>JSON/BSON documents<br/>Flexible schema"]
    end
    subgraph R2["　"]
        direction LR
        COL["Column-Family<br/>Cassandra, HBase<br/>Column-oriented storage<br/>Time series, large scale"]
        GRAPH["Graph DB<br/>Neo4j, Neptune<br/>Node-edge structure<br/>Optimized for relationship traversal"]
    end

    style KV    fill:#E3F2FD,stroke:#1976D2,color:#000
    style DOC   fill:#F3E5F5,stroke:#7B1FA2,color:#000
    style COL   fill:#FFF3E0,stroke:#F57C00,color:#000
    style GRAPH fill:#E8F5E9,stroke:#388E3C,color:#000
    style R1 fill:none,stroke:none
    style R2 fill:none,stroke:none

Model	Structure	Strength	Suitable Cases
Key-Value	A simple store of key-value pairs	Ultra-fast reads/writes, horizontal scaling	Session management, caching, shopping carts
Document	Hierarchical documents in JSON/BSON form	Flexible schema, nested queries	Product catalogs, content management
Column-Family	Storage organized by row, column, and timestamp	High-volume writes, efficient column compression	Time-series data, logs, IoT
Graph	A graph of nodes (entities) and edges (relationships)	Optimized for complex relationship traversal	Recommendation systems, social networks, fraud detection

3. Expected Benefits and Application of NoSQL/CAP Theorem

Category	Key Benefit	Application in Practice
Scalability	Handling high-volume traffic through horizontal scale-out	Building elastic infrastructure via sharding/replication in the cloud
Design fit	Optimizing for requirements through CAP-based database selection	Choosing technology to fit the case — finance (CP) vs. social/IoT (AP)
Performance optimization	Securing read/write performance specialized to each data model	Mixing caching (Redis), analytics (Cassandra), and relationship traversal (Neo4j) by purpose
Flexibility	Accommodating unstructured data with a schema-less structure	Choosing the optimal database per service in a microservices architecture (polyglot persistence)

Data Mesh Data Quality Management (DQC)