分布式数据库选型决策树

基于六项目横评（landscape）+ 导读 ch03/ch11 + 六篇精读综合 输入：现有数据库协议、数据量与增长、一致性要求、团队运维能力、是否需要 HTAP

一句话定位

一棵可执行的决策树——从”你已有什么数据库”这个最现实的问题出发，走完 4-5 个判断节点，落到 TiDB、CockroachDB、Vitess、Citus、YugabyteDB、OpenTenBase 六个项目中的一个。不回答”哪个最好”，只回答”哪个最匹配你的约束”。

选型的第一原则来自 ch11 的结论：没有”最好的”项目，只有”最适合场景的”项目。六个项目代表了四种架构模式（原生分布式、中间件代理、PG 扩展、内核 Fork）、两大 SQL 生态（MySQL / PostgreSQL）、三种一致性策略——每一种组合都对应一类真实场景。

六项目横向数据见 行业全景，架构模式详解见 导读第 3 章，终极对决见 导读第 11 章。

主决策树

按顺序回答问题，沿分支向下走。第一个问题永远是”要不要上分布式”——数据量在 1TB 以内、单机 PG/MySQL 还能撑住时，分布式的复杂度不值得。

              ┌──────────────────────────────┐
              │   需要分布式数据库吗？          │
              └──────────────┬───────────────┘
                             │
            ┌────────────────┴────────────────┐
            │ Q0: 数据量 < 1TB，单机还够用？    │
            └──────┬──────────────────┬───────┘
                是 │                  │ 否
                   ▼                  │
          ┌─────────────────┐         │
          │ 用单机 PG/MySQL  │         │
          │ （复杂度不值得）  │         │
          └─────────────────┘         │
                     ┌────────────────┴─────────────────┐
                     │ Q1: 现有存量是什么数据库/协议偏好？ │
                     └───┬──────────────┬────────────┬──┘
                   MySQL │              │ PostgreSQL │ 全新项目
                         │              │            │ 无历史包袱
             ┌───────────┴───────┐      │            │
             │ Q2: 需要 HTAP 或   │      │            │
             │ 透明分布式事务？    │      │            │
             └───┬───────────┬───┘      │            │
              否 │           │ 是       │            │
                 ▼           ▼          │            │
          ┌──────────┐ ┌──────────┐     │            │
          │  Vitess  │ │   TiDB   │     │            │
          │ (零侵入   │ │ (原生分布 │     │            │
          │  代理)   │ │  式 HTAP) │     │            │
          └──────────┘ └──────────┘     │            │
                                        │            │
                  ┌─────────────────────┴──┐         │
                  │ Q3: 同时需要 SQL+NoSQL   │         │
                  │ 双数据模型？             │         │
                  └───┬────────────────┬───┘         │
                   是 │                │ 否           │
                      ▼                │              │
              ┌────────────┐          │              │
              │ YugabyteDB │          │              │
              │ (YSQL+YCQL │          │              │
              │  双协议)   │          │              │
              └────────────┘          │              │
                    ┌─────────────────┴─────────┐    │
                    │ Q4: 一致性要求多高？        │    │
                    └─┬───────────┬───────────┬─┘    │
            全球多活   │           │ 需要 HTAP │      │
            金融级强   │           │ +深度分布 │ 轻量  │
            一致      │           │ 式事务    │ 扩展  │
                      ▼           ▼           ▼      │
             ┌────────────┐ ┌───────────┐ ┌───────┐ │
             │CockroachDB │ │OpenTenBase│ │ Citus │ │
             │(Serializ-  │ │(GTM+行列  │ │(PG 扩 │ │
             │ able 默认) │ │ 双引擎)   │ │ 展)   │ │
             └────────────┘ └───────────┘ └───────┘ │
                                                     │
                     ┌───────────────────────────────┴──┐
                     │ Q5: 全新项目最看重什么？            │
                     └──┬─────────────┬──────────────┬──┘
              正确性优先 │   分析能力   │      简单运维 │
              （金融级） │  （HTAP）   │              │
                        ▼             ▼              ▼
               ┌────────────┐  ┌──────────┐  ┌──────────────┐
               │CockroachDB │  │   TiDB   │  │ Citus (PG系) │
               └────────────┘  └──────────┘  │ Vitess(MySQL)│
                                             └──────────────┘

隐含的第六个维度是团队运维能力，它不出现在树上，但会否决部分叶子：原生分布式（TiDB/CockroachDB/YugabyteDB）的运维复杂度显著高于 Citus/Vitess——TiDB 是 tidb + tikv + pd + tiflash 多组件多仓库，YugabyteDB 是约 10,000 文件的 C/C++ 巨型代码库。如果团队没有专职 DBA 或分布式系统经验，即使功能匹配也应降级到低侵入方案。

叶子节点详解：三个理由 + 两个警告

TiDB —— MySQL 存量 + HTAP 需求

选它的三个理由：

1. MySQL 兼容阵营的绝对领导者（约 41K Star），国内金融、电商、游戏行业大量生产部署，中文社区最活跃，踩坑资料最多
2. 唯一具备完整 HTAP 的 MySQL 系方案——TiKV 行存 + TiFlash 列存，通过 Raft Learner 异步复制打通 TP 和 AP，实时分析成为事务系统的”副产品”而非独立 ETL 基础设施
3. 存算分离架构可以独立扩展计算（加 tidb-server）和存储（加 TiKV），弹性优于存算一体方案

两个警告：

• MySQL 兼容性高但非 100%——存储过程、触发器等功能有限，迁移前必须做兼容性验证
• 多仓库多组件（tidb/tikv/pd/tiflash）带来部署复杂度；TiFlash 需要额外资源，小规模场景是”杀鸡用牛刀”；Raft Learner 同步有秒级延迟

CockroachDB —— 全球多活 + 金融级一致性

选它的三个理由：

1. 六项目中唯一默认 Serializable 隔离级别，业界最强一致性保证；Parallel Commits 协议经 TLA+ 形式化验证，把 2PC 延迟从 2 轮 RTT 降到 1 轮
2. 存算一体设计让高可用成为架构的内在属性——每个节点都是完整数据库，任何节点故障不影响整体
3. 工程质量最高：Data-driven 测试遍布每个模块，pkg/raft/doc.go 398 行文档，2024 年 Cockroach Labs 已上市，企业级文档和测试最完善

两个警告：

• HTAP 能力弱——只有行存引擎，没有列存做分析加速，重分析场景不适合
• Serializable 默认隔离级别带来更多事务重试，应用端必须实现重试逻辑；约 15,000 文件的单体大仓库对二次开发者门槛高

Vitess —— MySQL 零侵入水平分片

选它的三个理由：

1. 不改 MySQL 一行代码，完整保留 MySQL 生态（备份工具、监控工具、DBA 经验），存量业务迁移成本最低
2. YouTube 十余年生产验证，管理数万个 MySQL 节点；CNCF 毕业项目，Kubernetes 原生；Slack、Block、JD.com 都在用
3. VSchema 声明式分片让分片策略与应用代码完全解耦，在线 resharding 通过 VReplication 实现原子切换，停机仅几秒

两个警告：

• 分布式事务支持有限——跨 shard 事务需要应用层自行管理，一致性由应用负责
• 能力天花板受限于 MySQL 单实例——Vitess 不能让单个查询跑得更快；分片键选择不当会导致热点

Citus —— PG 生态内轻量扩展

选它的三个理由：

1. 侵入最低：CREATE EXTENSION citus; 一条命令安装，不 fork 不魔改，PG 新版本发布装上就能用，兼容性成本为零
2. 六项目中代码量最小（约 1,000 文件），五层渐进式查询规划命中即停，planner/README.md 是开源世界最好的分布式规划器文档之一——学习和排障成本最低
3. Microsoft 收购后集成到 Azure Database for PostgreSQL，商业背书充分；列存通过 Table AM 接口实现，ALTER TABLE ... USING columnar 一条命令切换

两个警告：

• 分布式事务依赖 2PC，没有原生分布式那样的全局一致性保证；受限于 PG 暴露的 hook 接口，底层优化（存储格式、锁机制）做不了
• 单协调节点是潜在瓶颈；OLTP 点查性能好，但跨分片事务性能显著弱于 TiDB/CockroachDB

YugabyteDB —— SQL + NoSQL 双模型

选它的三个理由：

1. 一个存储引擎（DocDB）同时暴露 YSQL（PG 兼容）和 YCQL（Cassandra 兼容），可以用一个数据库替代 PostgreSQL + Cassandra 两套系统，减少运维成本
2. Spanner 架构 + Hybrid Logical Clock，不需要 GPS/原子钟就能实现接近全局一致的时间戳排序
3. 积极拥抱 AI 场景——内建 HNSW 向量索引（src/yb/vector_index/），可直接服务 RAG、推荐系统，省掉单独的向量数据库

两个警告：

• 代码量庞大（C/C++ + Java，约 10,000 文件），学习曲线最陡；YSQL 层是修改过的 PG fork，PG 版本跟进可能滞后
• YSQL 和 YCQL 的事务语义、一致性保证不完全相同，团队必须理解差异，否则双协议的灵活性会变成事故来源

OpenTenBase —— PG 兼容 + HTAP + 深度分布式事务

选它的三个理由：

1. PG 原生内核（fork 而非 extension），存储过程、触发器、自定义类型全都能用，PG 兼容度和 Citus 同级但分布式能力更深——GTM 提供全局一致的分布式事务和分布式 DDL
2. 行存 + 列存双引擎在同一个 Datanode 上，数据同步延迟为零，是 TiDB 之外唯一具备完整 HTAP 的项目
3. 腾讯内部（微信支付等）大规模生产验证；社区小（约 500 Star，2026-07 核实）意味着贡献者 PR 可见度高，是犀牛鸟参与的候选项目

两个警告：

• GTM 是中心化单点——所有事务都要经过它，高并发下可能成为吞吐天花板（GTM Proxy 批量聚合只能缓解，不能根治）
• 每次 PG 大版本升级需要重新合并所有内核改动，版本跟进滞后；开源社区和文档成熟度不如头部项目

维度速查表

三个典型场景推演

场景一：MySQL 存量业务分库分表

画像：电商业务跑在 MySQL 上，单表过亿、主从延迟恶化，应用层手写分库分表逻辑已经难以维护。团队有资深 MySQL DBA，但没有分布式数据库经验。

推演：Q0 数据量已超单机 → Q1 现有 MySQL → Q2 关键问题是”要不要透明分布式事务和 HTAP”。这个场景的核心诉求是”把手写分片逻辑下沉到基础设施”，而不是新增能力，所以答案是否 → Vitess。

VSchema 声明分片规则后，应用只连 VTGate（伪装成 MySQL 服务端），改分片规则不动应用代码；DBA 的备份、监控、调优经验全部保留。如果推演到后期发现确实需要跨分片事务或实时分析，再评估迁移 TiDB——但那是一次真正的数据库更换，成本完全不同，不要在第一步就为”未来可能需要”买单。

场景二：新建全球多活 SaaS

画像：从零开始的 SaaS 产品，用户分布在多个大洲，合同承诺数据强一致（计费、配额），要求任意单区域故障不影响服务。没有历史包袱。

推演：Q0 目标架构就是分布式 → Q1 全新项目 → Q5 正确性优先 → CockroachDB。

存算一体意味着每个区域的节点都是全功能数据库，区域故障时其余节点照常服务；默认 Serializable 从根上消灭 Write Skew 类异常，计费逻辑不需要为隔离级别妥协。代价要提前接受：应用端必须写事务重试逻辑，且不要指望在它上面跑重型报表——分析负载应该通过 CDC 导出到专门的分析系统。

场景三：PG 生态内轻量扩展

画像：SaaS 后端跑在 PostgreSQL 上，数据量增长到单机吃力（几个 TB），但团队只有两三个后端工程师，深度依赖 PG 生态（PostGIS、pg_dump、各种 FDW），不可能供养一套独立的分布式数据库。

推演：Q0 单机确实到顶 → Q1 现有 PG → Q3 不需要 NoSQL → Q4 一致性要求普通、无 HTAP 硬需求、最看重”改动最小” → Citus。

装扩展、声明分布列、把大表 create_distributed_table，其余照旧——PG 的全部生态工具继续可用，PG 升级 Citus 自动跟上。警惕两点：跨分片 JOIN 和事务的性能要提前用真实查询验证（Citus 的强项是能下推的查询）；如果未来出现”全球多活”这类需求，Citus 的 2PC 一致性模型撑不住，那是换 CockroachDB 的信号，不是调优 Citus 的信号。

决策之后：验证清单

决策树给出的是候选，不是结论。上生产前用 POC 验证以下各项——每一项都对应素材文档中记录过的真实断层：

1. 协议兼容性回归：把现有应用的全量 SQL（尤其存储过程、触发器、特殊函数）在候选库上回放。TiDB/CockroachDB 是自研解析器，兼容”高”不等于”全”；Citus/OpenTenBase 是 PG 本体，这项风险最低
2. 分片键与热点验证：用真实数据分布模拟分片。Vitess 的 Vindex 选错、Citus 的分布列选错，都会造成单分片热点——这类错误上线后修复成本极高
3. 跨分片事务压测：如果业务有跨分片写，实测吞吐和延迟。ch11 的定性结论是 CockroachDB ≈ TiDB > YugabyteDB > OpenTenBase » Citus ≈ Vitess，用你的负载验证这个排序对你是否成立
4. 故障注入：杀节点、断网络分区、磁盘打满，观察恢复时间和数据一致性。特别验证 OpenTenBase 的 GTM 主备切换、Vitess 的 VTGate/拓扑服务故障路径
5. HTAP 隔离验证（如果选 TiDB/OpenTenBase）：在 TP 压测的同时跑重型分析查询，确认 AP 负载不拖垮 TP 延迟；验证 TiFlash 的秒级同步延迟对业务是否可接受
6. 运维演练：完整走一遍扩容、缩容、备份恢复、版本升级。多组件方案（TiDB、OpenTenBase）的升级编排复杂度要在 POC 期暴露，不要留到生产
7. 一致性异常验证：SI 隔离级别（TiDB/YugabyteDB）允许 Write Skew，用业务中真实的并发模式（如余额扣减、库存超卖）验证是否需要显式加锁

POC 的止损原则：如果候选方案在前三项（兼容性、热点、跨分片事务）中任何一项需要大改应用代码才能通过，回到决策树重新走一遍——大概率是 Q1/Q2 的回答不诚实。

相关阅读