第 11 章：跨项目全景对比——六大项目横评

结论先行：六个分布式数据库项目代表了四种架构模式、两大 SQL 生态、三种一致性策略。没有”最好的”项目——只有”最适合场景的”项目。本章用多维度矩阵帮你建立全景视角，学会根据需求选择正确的方案。

六个项目一句话回顾

在逐一深入了解了每个项目之后，我们先用最简洁的方式把它们放在一起：

TiDB        = MySQL 兼容 + 存算分离 + HTAP（行+列双引擎）
CockroachDB = PG 兼容 + 存算一体 + 强一致（Serializable 默认）
Vitess      = MySQL 中间件 + 零侵入 + YouTube 验证
Citus       = PG Extension + 极简侵入 + Microsoft 收购
YugabyteDB  = PG+CQL 双协议 + DocDB + HLC
OpenTenBase = PG 内核 Fork + GTM 中心化 + 腾讯出品

架构模式矩阵

                    侵入性
           低 ◄─────────────────► 高
           │                      │
  Vitess   │  ★                   │             ← 代理层
  (代理)   │                      │
           │                      │
  Citus    │     ★                │             ← Extension
  (扩展)   │                      │
           │                      │
  OpenTenBase│           ★        │             ← 内核 Fork
  (Fork)   │                      │
           │                      │
  TiDB     │                  ★   │             ← 原生分布式
  CRDB     │                  ★   │
  YugabyteDB│                 ★   │
           │                      │
           └──────────────────────┘
                    能力深度
           浅 ◄─────────────────► 深

低侵入 = 与现有数据库生态兼容性更好、维护成本低。高侵入 = 分布式能力更深、但独立于上游生态演进。

详细对比表

维度	TiDB	CockroachDB	Vitess	Citus	YugabyteDB	OpenTenBase
架构模式	原生分布式	原生分布式	代理中间件	PG Extension	原生分布式	PG Fork
兼容协议	MySQL	PostgreSQL	MySQL	PostgreSQL	PG + CQL	PostgreSQL
编程语言	Go+Rust+C++	Go	Go	C	C/C++	C
存储引擎	TiKV(RocksDB) + TiFlash	Pebble(自研)	MySQL InnoDB	PG Heap + Columnar	DocDB(RocksDB)	PG Heap + 列存
共识协议	Raft	Raft(深度定制)	无(依赖MySQL复制)	无(依赖PG)	Raft	无(GTM中心化)
全局时钟	TSO(PD中心化)	HLC	无	无	HLC	GTM时间戳
默认隔离级别	SI	Serializable	取决于MySQL	取决于PG	SI	取决于PG
HTAP	强(TiFlash列存)	弱	无	有限(列存扩展)	弱	有(双引擎)
代码文件数	~10K+(多仓库)	~15K+	~5K+	~1K	~10K+	~3K
GitHub Star	~41K	~32K	~21K	~12.5K	~10.5K	~2K

按维度深入对比

一致性模型

强一致性保证     弱一致性保证
│                             │
│  CockroachDB                │
│  (Serializable)             │
│                             │
│     TiDB                    │
│     (Snapshot Isolation)    │
│                             │
│     YugabyteDB              │
│     (Snapshot Isolation)    │
│                             │
│        OpenTenBase           │
│        (依赖GTM快照)         │
│                             │
│           Citus              │
│           (依赖PG本地+2PC)   │
│                             │
│              Vitess          │
│              (应用层负责)    │
│                             │

CockroachDB 是唯一默认使用 Serializable 隔离级别的项目——最严格但代价是更多的事务重试。TiDB 和 YugabyteDB 使用 Snapshot Isolation——性能更好但允许 Write Skew 异常。Vitess 不提供分布式事务，一致性由应用负责。

扩展方式

存算分离 vs 存算一体：

TiDB（存算分离）：
  可以独立扩展计算（加 tidb-server）和存储（加 TiKV）
  弹性更好，但网络依赖更高

CockroachDB / YugabyteDB（存算一体）：
  加节点 = 同时加计算和存储
  更简单，但弹性不如存算分离

Citus / Vitess（利用现有引擎）：
  加 Worker/Shard = 加一个完整的 PG/MySQL 实例
  最简单，但每个实例是完整的数据库进程

OpenTenBase（Coordinator + Datanode）：
  加 Coordinator = 加计算
  加 Datanode = 加存储
  类似存算分离，但 GTM 是瓶颈

查询优化器

项目	优化器类型	特点
TiDB	Cascades 框架	最完整的开源 Cascades 实现，规则驱动，40+ 规则
CockroachDB	基于代价 (CBO)	Cascades 风格，与 Pebble 紧密集成
Vitess	Gen4 Planner	从零实现的 SQL 兼容层，算子丰富
Citus	五层渐进式	命中即停，大部分查询在前两层解决
YugabyteDB	PG Planner + PgGate	复用 PG 原生优化器
OpenTenBase	PG Planner + pgxcship	PG 优化器 + 下推判断

HTAP 能力

HTAP 能力谱：

  完整 HTAP              无 HTAP
  ◄──────────────────────────────►
  │                               │
  TiDB                            Vitess
  (独立列存TiFlash,               (纯OLTP)
   Raft Learner实时同步,
   物理隔离)
  │
     OpenTenBase                  CockroachDB
     (同进程双引擎,              (行存only,
      逻辑隔离)                   有限分析能力)
     │
        Citus                     YugabyteDB
        (列存Extension,           (行存only)
         可选使用)

技术选型决策树

你需要分布式数据库吗？
│
├── 数据量 < 1TB，单机 PG/MySQL 够用？
│   └── 用单机，别上分布式（复杂度不值得）
│
├── 需要分布式
│   │
│   ├── 你现在用的是什么数据库？
│   │   │
│   │   ├── MySQL
│   │   │   ├── 想要零侵入、不改数据库？
│   │   │   │   └── Vitess
│   │   │   └── 想要完整的分布式能力 + HTAP？
│   │   │       └── TiDB
│   │   │
│   │   └── PostgreSQL
│   │       ├── 想要最简单的扩展方式？
│   │       │   └── Citus
│   │       ├── 想要最强的全局一致性？
│   │       │   └── CockroachDB
│   │       ├── 同时需要 SQL + NoSQL？
│   │       │   └── YugabyteDB
│   │       └── 需要 HTAP + 参加犀牛鸟？
│   │           └── OpenTenBase
│   │
│   └── 全新项目，没有历史包袱？
│       ├── 优先正确性（金融级）→ CockroachDB
│       ├── 优先分析能力（HTAP）→ TiDB
│       └── 优先简单运维 → Citus（PG 生态）或 Vitess（MySQL 生态）

社区与生态对比

社区成熟度（从成熟到新兴）：

  CockroachDB ───── 2024 年上市，企业级文档和测试最完善
  TiDB ──────────── 中文社区最活跃，PingCAP 商业支持
  Vitess ─────────── CNCF 毕业项目，YouTube 背书
  Citus ──────────── Microsoft 收购，Azure 集成
  YugabyteDB ────── 活跃开发中，双协议独特定位
  OpenTenBase ───── 腾讯内部大规模使用，开源社区较小

学习资源质量（部分亮点）：

  CockroachDB：pkg/raft/doc.go (398行文档)
               docs/tla-plus/ (形式化验证)
               每个包都有 doc.go

  TiDB：       pkg/planner/cascades/ (完整 Cascades 学习材料)
               多语言实现（Go+Rust 协作的范例）

  Citus：      planner/README.md (开源世界最好的 Planner 文档之一)
               代码量最小，入门最快

  Vitess：     丰富的端到端测试
               CNCF 社区运营成熟

  OpenTenBase：#ifdef __OPENTENBASE__ 标记（改动地图）
               C + PG 内核，适合想学数据库内核的人

代码文化差异

不同项目的代码风格和工程文化差异很大，选择贡献目标时值得考虑：

CockroachDB 的测试文化：
  - TLA+ 形式化验证（数学证明协议正确性）
  - Data-driven 测试遍布每个模块
  - pkg/kv/kvnemesis/ 混沌测试
  - 极致的代码文档（每个包都有 doc.go）

TiDB 的多仓库协作：
  - tidb(Go) + tikv(Rust) + pd(Go) + tiflash(C++)
  - 跨仓库开发需要理解多个项目的接口
  - 用最适合的语言写每个组件

Citus 的极简主义：
  - 整个项目 ~1000 个 C 文件
  - 通过 PG 的 hook 机制实现分布式
  - planner/README.md 文档质量极高

OpenTenBase 的条件编译风格：
  - #ifdef __OPENTENBASE__ 标注所有增量改动
  - 代码考古友好（能精确区分原始代码和改动）
  - C 语言，需要 PG 内核知识

性能特征对比（定性）

性能比较需要非常谨慎——不同场景下结论可能完全相反。以下是定性分析：

OLTP 点查（单行读写）：
  Citus ≈ Vitess > TiDB ≈ CockroachDB ≈ YugabyteDB > OpenTenBase
  原因：Citus/Vitess 的快路径直接路由到单节点，几乎是原生性能
        原生分布式需要走共识协议
        OpenTenBase 需要访问 GTM

OLTP 分布式事务（跨分片）：
  CockroachDB ≈ TiDB > YugabyteDB > OpenTenBase >> Citus ≈ Vitess
  原因：CockroachDB 的 Parallel Commits 减少 RTT
        Vitess 不支持分布式事务

OLAP 分析查询：
  TiDB(TiFlash) >> Citus(列存) > OpenTenBase(列存) > 其他
  原因：TiDB 有独立的列存引擎，物理隔离不影响 OLTP

写入吞吐量：
  TiDB ≈ CockroachDB > YugabyteDB > OpenTenBase > Citus ≈ Vitess
  原因：原生分布式可以在存储层做 Raft 并行写入
        OpenTenBase 受 GTM 瓶颈限制

六项目的”前世今生”

时间线：

2010  ├── Vitess 在 YouTube 内部诞生
2012  ├── Google Spanner 论文发表
      ├── Postgres-XC / Postgres-XL 项目启动
2015  ├── TiDB 创立（PingCAP）
      ├── CockroachDB 创立（Cockroach Labs）
2016  ├── YugabyteDB 创立
      ├── Citus Data 公司成立
2017  ├── Vitess 进入 CNCF
2019  ├── Microsoft 收购 Citus
      ├── OpenTenBase 腾讯开源（基于 Postgres-XL）
2020  ├── Vitess CNCF 毕业
2024  ├── Cockroach Labs 上市
2025  ├── TiDB 8.x 发布
2026  ├── 犀牛鸟 2026 竞赛 ← 我们在这里

常见误区

误区一：”原生分布式一定比中间件好” → 正确理解：原生分布式（TiDB、CockroachDB）能力更强，但运维复杂度也更高。如果你的需求是”MySQL 水平扩展”且不需要跨分片事务，Vitess 可能是更好的选择——它让你继续使用熟悉的 MySQL，只在需要的地方加上分布式能力。

误区二：”Star 数多就是好项目” → 正确理解：Star 数反映社区关注度，不直接等于技术优劣。Citus（12.5K Star）被 Microsoft 收购并集成到 Azure，技术和商业价值不亚于 TiDB（41K Star）。OpenTenBase（2K Star）在腾讯微信支付有大规模生产验证。

误区三：”应该学最热门的项目” → 正确理解：对犀牛鸟参赛者来说，学习目标和贡献目标可以不同。学习时可以从 Citus（代码最少、文档最好）入手理解概念，然后看 CockroachDB（测试最严谨）理解工程实践，最后在 OpenTenBase 上做贡献（社区最小、可见度最高）。

读完本章你能做什么

在白板上画出六个项目的架构模式谱（代理 → 扩展 → Fork → 原生分布式）
给出不同场景下的技术选型建议
解释每个项目在一致性、HTAP、查询优化上的取舍
理解为什么”最好的数据库”这个问题没有答案

导读目录：README.md 上一章：第 10 章 · OpenTenBase 深度解读——从 GTM 到贡献方向下一章：第 12 章 · 十二大核心技术挑战