Choosing the Right NoSQL Model: From Four Data Types to CAP Trade‑offs

Problem Statement

The goal is to be able to choose among relational, key‑value, document, column‑family, and graph databases after seeing a business requirement, and to explain the query patterns, consistency needs, and cost implications.

Four NoSQL Data Models

A decision tree shows which model fits a given access pattern:

业务首先在问什么？
   |
   |-- 按一个键快速取值 ----------> 键值数据库
   |
   |-- 读取一个完整且结构多变的对象 --> 文档数据库
   |
   |-- 按行键访问海量稀疏记录 ----> 列族数据库
   |
   |-- 沿关系连续查很多跳 --------> 图数据库
   `-- 多表关联和强事务最重要 ----> 关系数据库

Strict rules: do not merely memorize product names, do not assume NoSQL is always faster, do not equate “flexible schema” with “no structure”, and always discuss query, transaction, governance, and operational costs.

1. Key‑Value Database

Structure: key → value. Example keys: session:8f31 → 用户会话, cart:user:1001 → 购物车内容, product:9527 → 商品缓存.

Core operations: PUT(key, value), GET(key), DELETE(key). Typical query: “What value does this key map to?”

Typical scenarios: login sessions, caches, shopping carts, rate‑limiting counters, leaderboards, temporary state.

Products: Redis, Amazon DynamoDB (mentioned as examples only).

“Redis belongs to NoSQL but does not mean Redis can only be used as a cache.”

Pros: simple structure, fast key lookup, easy sharding, good horizontal scalability.

Cons: hard to query when the key is unknown, weak support for ad‑hoc queries on values, limited complex joins and analytics, requires careful key design.

2. Document Database

Stores self‑contained JSON‑like documents. Example product document:

{
  "productId": 9527,
  "name": "降噪耳机",
  "brand": "A品牌",
  "specifications": {"color": "黑色", "batteryHours": 30},
  "tags": ["无线", "降噪"]
}

Queries can target fields inside the document (e.g., productId, brand, specifications.color, tags).

Advantages over key‑value: field‑level indexing and queries, natural representation of nested objects and arrays.

Typical scenarios: product catalogs with heterogeneous attributes, content management, user profiles, forms, configuration data.

Products: MongoDB, CouchDB.

Pros: flexible schema, natural handling of nested data, whole‑object reads.

Cons: possible data redundancy, more complex multi‑document joins and transactions, need for schema governance, versioning, and validation.

“If a business object is often read and written as a whole and its fields vary by type, use a document database; do not store everything in a huge document just because nesting is allowed.”

3. Column‑Family Database

Core concept: a row key identifies a row; columns are grouped into column families. Example layout for a medical device record:

Row Key → device001#20260810#090001
  info:type          → 心电监护仪
  info:hospital      → 第一医院
  metrics:heart_rate → 78
  metrics:oxygen     → 98%
  alert:level        → 低

Rows are sparse: each row stores only the columns it actually has. Example sparse rows for different devices show many empty cells.

Typical scenarios: IoT device logs, user behavior streams, time‑series data, massive sparse datasets.

Products: HBase, Cassandra.

Pros: suited for massive distributed writes, easy row‑key based partitioning, supports sparse wide rows, high throughput for known access patterns.

Cons: wrong row‑key design can cause hotspots, weak ad‑hoc queries and multi‑row joins, requires query‑driven schema design, complex partitioning, compression, replication, and operations.

“Column‑family databases are not the same as analytical columnar stores; the former focuses on row‑key access and sparse data, while the latter stores each column contiguously for OLAP scans.”

4. Graph Database

Core elements: vertices (nodes), edges (relationships), and properties. Example relationships:

张三 --转账5000元--> 账户B
账户B --转账4800元--> 账户C
账户C --使用设备--> 手机X
账户D --使用设备--> 手机X

Typical queries: multi‑hop traversals such as “Is an account within three transfers connected to a known fraud account?”

Products: Neo4j, JanusGraph.

Pros: natural expression of complex relationships, intuitive multi‑hop queries, flexible schema evolution for relationship changes.

Cons: simple primary‑key lookups may not need a graph, large‑scale distributed graph partitioning is hard, teams need to learn graph query languages.

CAP Theorem and Trade‑offs

Recall: C = Consistency, A = Availability, P = Partition tolerance. In a distributed system, P is unavoidable; when a partition occurs you must choose between CP (reject/await to avoid conflicts) or AP (continue serving, allowing temporary inconsistency).

Examples:

Medical insurance balance deduction prefers CP to avoid overdraft.

Product page view counters can tolerate AP because a slight count error is acceptable.

Do not rigidly label a product as CP or AP; the actual behavior depends on replication strategy, consistency level, quorum settings, operation type, and configuration.

Consistency Models

Strong Consistency

After a successful write, subsequent reads see the latest value. Suitable for balances, inventory deductions, payment status, unique quota allocation.

Eventual Consistency

Different replicas may diverge temporarily but converge after synchronization. Suitable for likes, view counts, recommendation results, search indexes, statistical reports. It still requires explicit sync mechanisms, conflict resolution, latency bounds, retry logic, and reconciliation.

Read‑Your‑Writes

Ensures a user sees their own recent write immediately, even if the system overall is eventually consistent.

Quorum Arbitration (N, W, R)

Define total replicas N, write quorum W, read quorum R. Example: N=3, W=2, R=2, satisfying W+R > N to guarantee overlapping replicas.

W + R > N is the exam model for quorum intersection; real linearizability also depends on versioning, conflict handling, and implementation details.

BASE Model

Basically Available, Soft State, Eventually Consistent. It means the system remains functional under failure or load spikes, tolerates intermediate states, and eventually converges to a consistent state via retries, compensation, and reconciliation.

Polyglot Persistence

Using multiple databases in one system, each chosen for its fit to a specific data model. Not a gimmick; it reduces cost by letting each data class use the most appropriate store.

Costs include increased tech stack complexity, more complex ops and monitoring, different backup/recovery procedures, harder cross‑database transactions, data duplication, and higher learning curve.

Comprehensive Case Study: Retail Platform

Requirements:

Orders & payments need strong consistency and multi‑table transactions.

Product specifications vary widely across categories.

Millions of sessions and carts require low‑latency key lookups.

Device and behavior events generate massive write volume.

Fraud detection needs multi‑hop relationship analysis.

Search and reporting can tolerate minute‑level delay.

Step‑by‑step selection:

Match data to model:

Orders, payments, inventory → relational database.

Product specs → document database.

Sessions, carts → key‑value database.

Device logs → column‑family database.

Account‑device‑transfer graph → graph database.

Search & reports → separate search indexes / analytical replicas.

Identify authoritative source for each fact (e.g., order status lives in the relational store).

Synchronize derived data via Change Data Capture (CDC) or event streams, handling duplication, loss, ordering, and long‑term drift with idempotency, retries, version keys, periodic reconciliation, and replayable logs.

Exam answer structure: first state selection criteria, then map each data type to a model, then explain authoritative source and sync, finally discuss consistency trade‑offs and costs.

Key Takeaways for Exams

Never start with “We will use MongoDB”; first ask how data is read, which fields locate it, need for joins, transaction strength, schema volatility, volume, multi‑hop queries, and partition‑vs‑error tolerance.

Use the access‑mode decision tree to pick the right model.

Polyglot persistence is allowed but must be justified and its operational overhead acknowledged.

CAP trade‑offs depend on business impact: financial correctness → CP, user‑experience metrics → AP.

BASE does not abandon correctness; it defines a path to eventual convergence.

Sample Q&A (Self‑Test)

Answers to the ten self‑test questions are provided in the source and reflect the same reasoning above.