数据库选型 — 不是『SQL 还是 NoSQL』那么简单Database Selection: SQL vs NoSQL, OLTP vs OLAP, ACID vs BASE

问题场景

面试官问『你为什么选 MongoDB』，资深工程师会被这种问题问翻车——因为正确答案不是『因为它快』，而是『因为我的访问模式是按 user_id 聚合读、写多读少、schema 经常变』。数据库选型不是技术信仰，是约束推导：数据模型、访问模式、一致性要求、规模、运维成本，五个轴决定一切。

反面案例多得很：Uber 2016 年从 Postgres 迁到 MySQL（因为 Postgres 复制协议的写放大），又在 2020 年自研 Schemaless 在 MySQL 上跑 KV；Pinterest 2012 年从 MongoDB 迁到 MySQL + 自家分片；Discord 2017 年从 MongoDB 迁到 Cassandra（消息存储 1 亿条/天），2023 年又迁到 ScyllaDB；Stripe 至今主库仍是 MongoDB——但他们用一套精密的应用层一致性。没有最优数据库，只有最匹配的。

需求与约束（面试必问）

• 访问模式：是『按主键点查』『按二级索引扫』『范围查询』『join 多表』还是『全表聚合』？这决定数据库类型。
• 读写比与 QPS：写 100k QPS 的场景，Postgres 单机不够（极限约 50k），需要 Cassandra / DynamoDB / 分片 MySQL。
• 数据量与增长：100GB？10TB？1PB？10TB 以上单机 OLTP 数据库基本不行，必须分片或换分布式 SQL（CockroachDB / TiDB / Spanner）。
• 一致性要求：账户余额（强一致）vs 社交点赞（最终一致）。
• 延迟要求：p99 1ms（Redis）、10ms（DynamoDB）、100ms（Postgres + index）、秒级（OLAP）。
• Schema 稳定性：业务还在快速迭代（NoSQL 灵活）还是已稳定（SQL 结构化更安全）。
• 运维能力：团队会调 Postgres 还是 Cassandra？托管（Aurora / DynamoDB）还是自建？

高层架构（典型数据栈）

graph LR
    APP["Application
API / Service"]
    CACHE["Redis
KV cache · 会话 · 排行榜"]
    OLTP["OLTP
Postgres / MySQL · DynamoDB"]
    SEARCH["Search
Elasticsearch · OpenSearch"]
    QUEUE["CDC / Kafka
binlog → 下游"]
    DWH["Data Warehouse
Snowflake / BigQuery · OLAP"]
    LAKE["Data Lake
S3 + Iceberg · 冷数据"]

    APP --> CACHE
    APP --> OLTP
    APP --> SEARCH
    OLTP -->|binlog| QUEUE
    QUEUE --> DWH
    QUEUE --> SEARCH
    QUEUE --> LAKE

    classDef app fill:#1a2530,stroke:#64c8ff,color:#e8eef5
    classDef cache fill:#1a1a30,stroke:#ffb450,color:#e8eef5
    classDef oltp fill:#0e2030,stroke:#5eead4,color:#e8eef5
    classDef olap fill:#2a1530,stroke:#ff7ab6,color:#e8eef5
    class APP app
    class CACHE cache
    class OLTP,SEARCH oltp
    class QUEUE,DWH,LAKE olap

现代后端往往是『多数据库共存』：OLTP 跑交易、OLAP 跑分析、Search 跑搜索、Cache 抗读

关键技术点

1. SQL vs NoSQL：不是二元对立，是数据模型选择

原理：『NoSQL』是个糟糕的命名，它其实是 4 类完全不同的数据库的总称：

2. OLTP vs OLAP：行存 vs 列存的本质区别

原理：交易系统（OLTP）和分析系统（OLAP）的访问模式完全相反：

• OLTP：每次读写少量行（按主键）、写多、低延迟（ms）、ACID。例如『查 user 123 的订单』『扣库存』。
• OLAP：扫描海量行、读多写少、长查询（秒-分钟）、聚合统计。例如『过去 30 天按地区统计 GMV』。

这决定了存储格式：OLTP 用行存（一行所有字段在一起，便于点查整行）；OLAP 用列存（同一列的值在一起，便于聚合 + 高压缩比 + SIMD）。

graph LR
    subgraph Row["Row Store (Postgres / MySQL)"]
        R1["[1, Alice, 30, US]"]
        R2["[2, Bob, 25, UK]"]
        R3["[3, Carol, 28, JP]"]
    end
    subgraph Col["Columnar Store (BigQuery / Snowflake)"]
        C1["id: [1, 2, 3]"]
        C2["name: [Alice, Bob, Carol]"]
        C3["age: [30, 25, 28]"]
        C4["country: [US, UK, JP]"]
    end
    Row -->|"SELECT * WHERE id=2 ✅"| Q1["点查快"]
    Col -->|"AVG(age) GROUP BY country ✅"| Q2["聚合快 · 压缩 10x"]
    classDef row fill:#0e2030,stroke:#5eead4,color:#e8eef5
    classDef col fill:#2a1530,stroke:#ff7ab6,color:#e8eef5
    class Row,R1,R2,R3 row
    class Col,C1,C2,C3,C4 col

# 列存为什么聚合快：只读需要的列
# 一张表 100 列、10 亿行
# OLTP 行存做 SELECT AVG(salary):
#   要扫 10 亿 × 100 列的全部数据 = 海量 IO
# OLAP 列存做 SELECT AVG(salary):
#   只读 salary 这一列（10 亿 × 1 列），压缩后可能 1GB
#   + SIMD 向量化执行 → 秒级返回

3. ACID vs BASE：一致性的两种哲学

ACID（Atomicity, Consistency, Isolation, Durability）：传统 RDBMS 的承诺。BASE（Basically Available, Soft state, Eventual consistency）：NoSQL 的妥协。

但 2010 年代起，这条界线在模糊：

• Spanner / CockroachDB / TiDB：分布式 SQL，靠 Paxos/Raft + TrueTime 提供 ACID + 水平扩展。
• DynamoDB 2018+：支持事务（TransactWriteItems / TransactGetItems），最多 100 个 item / 4MB。
• MongoDB 4.0+：多文档事务（性能比单文档低 10 倍，但有了）。

# Postgres SERIALIZABLE 事务（最高隔离级别）
BEGIN;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

SELECT balance FROM accounts WHERE id = 1 FOR UPDATE;
-- 如果 balance >= 100, 扣款
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;

COMMIT;
-- ⚠️ Serializable 下如果有并发冲突, 会抛 SerializationFailure
-- 应用层要捕获并重试 (退避 + jitter)

4. 选型决策树：Postgres / DynamoDB / Cassandra / Redis

原理：四个主流选项覆盖 90% 场景。下面是一个实用决策路径。

graph TD
    Start{"需要事务 & Join?"}
    Start -->|"是"| SQL_q{"数据量 > 1TB?"}
    Start -->|"否"| KV_q{"延迟要求 < 1ms?"}

    SQL_q -->|"否"| PG["✅ Postgres
事务 · 复杂查询 · JSONB"]
    SQL_q -->|"是"| Dist_q{"全球多区?"}

    Dist_q -->|"是"| Span["✅ Spanner / CockroachDB
跨区 ACID"]
    Dist_q -->|"否"| TiDB["✅ TiDB / Vitess
分布式 MySQL"]

    KV_q -->|"是"| Redis["✅ Redis
内存 KV · 缓存 · 排行榜"]
    KV_q -->|"否"| Scale_q{"QPS > 50k 写 & 海量数据?"}

    Scale_q -->|"是"| Wide_q{"托管 / 自建?"}
    Scale_q -->|"否"| PG2["✅ Postgres
通常够用"]

    Wide_q -->|"托管"| DDB["✅ DynamoDB
无运维 · 按访问付费"]
    Wide_q -->|"自建"| Cass["✅ Cassandra / Scylla
多区写 · BASE"]

    classDef sql fill:#0e2030,stroke:#5eead4,color:#e8eef5
    classDef kv fill:#1a1a30,stroke:#ffb450,color:#e8eef5
    classDef wide fill:#2a1530,stroke:#ff7ab6,color:#e8eef5
    classDef q fill:#1a2530,stroke:#64c8ff,color:#e8eef5
    class PG,PG2,Span,TiDB sql
    class Redis kv
    class DDB,Cass wide
    class Start,SQL_q,KV_q,Dist_q,Scale_q,Wide_q q

扩展与优化（增长后怎么办）

• Postgres 单机顶不住：先 read replica（读写分离）→ 垂直分库（按业务拆 user / order / inventory）→ 水平分片（Citus / Vitess / 应用层）。
• 跨业务 join：CDC（Debezium 抓 binlog）→ Kafka → 物化到搜索/数仓，应用层 join 转为下游消费。
• OLAP 拖慢 OLTP：千万别在主库上跑分析 SQL；用 read replica 或 CDC 到独立 OLAP（Snowflake / ClickHouse）。
• 多区：单区 OLTP（避免分布式事务）+ 异步复制到其他区；或者上 Spanner / CockroachDB（全球 ACID 但写延迟 100ms+）。
• 冷数据归档：热数据留 OLTP（最近 90 天），冷数据走 S3 + Iceberg/Parquet，查询用 Athena/Trino。

常见陷阱（资深工程师也常翻车）

面试问题示例

1. 你设计一个 Twitter，timeline 用什么存？为什么不全用 MySQL？
2. Postgres 和 MySQL 选哪个？说出 3 个真实差异（不要说『差不多』）。
3. 什么场景下你会选 Cassandra 而不是 DynamoDB？
4. 解释 BASE 模型的『S』（soft state）是什么意思，给个例子。
5. 用户量从 10w 到 1 亿，数据库怎么演进？分几个阶段、每个阶段瓶颈是什么。
6. HTAP 数据库（TiDB）和『OLTP + CDC 到 OLAP』两套方案，怎么选？

关键资源

• 《Designing Data-Intensive Applications》Ch 2-3（Kleppmann）：数据模型与存储引擎的本质讨论，本主题最权威读物。
• 《Dynamo: Amazon's Highly Available Key-value Store》（SOSP 2007）+ 《Spanner: Google's Globally Distributed Database》（OSDI 2012）：NoSQL 与分布式 SQL 的两座里程碑。
• Discord 工程博客《How Discord Stores Trillions of Messages》（2023）：MongoDB → Cassandra → ScyllaDB 的迁移史，含 latency 数据。

English Summary

Database selection is constraint derivation, not technology religion. Five axes determine the choice: data model (relational / KV / document / wide-column / graph / search / time-series), access pattern (point lookup vs range scan vs aggregation vs join), consistency (ACID vs BASE), scale (QPS, data size, geo distribution), and operational cost. Default to Postgres unless you have a specific reason — its versatility (JSONB, full-text, geo, time-series extensions) covers 80% of needs. Reach for DynamoDB / Cassandra when write throughput exceeds ~50k QPS or you need horizontal scale-out; Redis when sub-ms latency is required; columnar warehouses (Snowflake / BigQuery / ClickHouse) when analytical aggregation dominates. Modern stacks combine multiple stores via CDC pipelines: OLTP handles transactions, search handles full-text, warehouse handles analytics.

深入思考（点击展开答案）