NewSQL 选型对比

NewSQL 是一类兼顾关系型数据库的 ACID 事务与 NoSQL 水平扩展能力的分布式数据库。随着 TiDB、CockroachDB 等系统的成熟，NewSQL 正从理论走向大规模生产。本文对比主流 NewSQL 数据库，帮助团队做出合理选型。

1. NewSQL 核心特征

2. 主流产品对比

2.1 对比矩阵

2.2 TiDB 详解

优势：
- MySQL 协议兼容度最高（应用迁移最顺滑）
- HTAP 架构成熟（TiFlash 列存 + MPP）
- 计算存储分离，弹性伸缩
- 中国社区最活跃，中文文档丰富

劣势：
- 强依赖 PD（单点调度中心）
- 分布式事务延迟高于单机
- 复杂查询下推优化有边界

代表用户：小米、知乎、美团、工商银行

2.3 CockroachDB 详解

优势：
- PostgreSQL 协议兼容（PG 生态丰富）
- 默认 SERIALIZABLE 隔离级别（最高安全）
- 全球多区域部署（Region/Disk/Row 级别存活策略）
- 成本优化器（Cost-based Optimizer）强大

劣势：
- 事务冲突频繁场景性能下降明显
- 写入延迟较高（Raft + Serializable）
- 中国社区相对 TiDB 较小

代表用户：Netflix、Bose、_comcast_

2.4 YugabyteDB 详解

优势：
- 同时支持 SQL (YCQL) 和 Cassandra CQL (YEDIS)
- 与 Redis 兼容 API
- 地理分布式事务优化
- 单区域写入性能优秀

劣势：
- 相对较新，生产案例少于 TiDB/CockroachDB
- SQL 功能完善度不如前两者
- 企业级支持生态较小

代表用户：Kroger、Wells Fargo、Narvar

2.5 MongoDB Atlas 详解

优势：
- 文档模型灵活，模式演进简单
- Atlas 云服务成熟（自动扩缩容、备份、监控）
- 全球多集群（Global Clusters）
- 丰富的驱动生态和聚合框架

劣势：
- 单文档事务（4.0+ 多文档，但有限制）
- 关系型查询 JOIN 支持弱
- 强一致性不如 NewSQL（默认最终一致）

代表用户：Adobe、eBay、Google、SEGSA

3. 深入维度对比

3.1 一致性模型

一致性强度从高到低：

线性一致性（Linearizable）
    │
    ├── CockroachDB: SERIALIZABLE + linearizable reads（默认）
    ├── Spanner: 外部一致（TrueTime）
    │
    ├── TiDB: Snapshot Isolation（悲观事务）/ Repeatable Read（快照读）
    │
    ├── YugabyteDB: 可配置（Snapshot/Serializable）
    │
    └── MongoDB: Read Concern majority / snapshot

3.2 全球部署能力

3.3 性能基准

Sysbench OLTP 对比（2024 标准测试，非官方）：

写入 QPS（越高越好）：
TiDB ≈ 15K      CockroachDB ≈ 12K     YugabyteDB ≈ 18K

读取 QPS（越高越好）：
TiDB ≈ 45K      CockroachDB ≈ 35K     YugabyteDB ≈ 40K

延迟 P99（越低越好）：
TiDB ≈ 15ms     CockroachDB ≈ 25ms    YugabyteDB ≈ 12ms

注意：实际性能与硬件、调优、工作负载高度相关，仅供参考。

4. 选型决策框架

4.1 决策树

是否需要 SQL 和 ACID 事务？
  │
  ├── 否 → 考虑 MongoDB / Cassandra / DynamoDB
  │
  └── 是
        │
        ├── 是否有 MySQL 存量？
        │     ├── 是 → TiDB（迁移成本最低）
        │     └── 否 → 看 PG 生态需求
        │
        ├── 是否需要最高隔离级别（SERIALIZABLE）？
        │     ├── 是 → CockroachDB（默认 SERIALIZABLE）
        │     └── 否 → 继续
        │
        ├── 是否需要 HTAP（统一分析）？
        │     ├── 是 → TiDB（TiFlash 最成熟）
        │     └── 否 → 继续
        │
        ├── 是否需要 Redis 兼容？
        │     ├── 是 → YugabyteDB（YEDIS）
        │     └── 否 → 继续
        │
        ├── 是否需要全球多区域强一致？
        │     ├── 是 → CockroachDB（全球事务优化）
        │     └── 否 → TiDB（中国生态最强）
        │
        └── 默认推荐：TiDB（中文社区、MySQL 兼容、HTAP）

4.2 场景匹配

5. 迁移实践要点

5.1 TiDB 迁移路径

MySQL → TiDB 迁移：

1. 兼容性评估
   └── tiup tidb-lightning --check-requirements
   
2. 全量迁移（Dumpling + Lightning）
   └── dumpling -h mysql_host -o /backup/
   └── tidb-lightning --config tidb-lightning.toml
   
3. 增量同步（TiDB DM / TiCDC）
   └── 捕捉 Binlog 实时同步
   
4. 灰度切流
   └── 读写分离：读 → TiDB，写 → MySQL
   └── 验证一致后全切
   
5. 回滚方案
   └── TiCDC 反向同步到 MySQL

5.2 避坑指南

6. 总结

NewSQL 代表了数据库技术的演进方向——在保持 SQL 和 ACID 的同时实现水平扩展：

单机 RDBMS              分库分表               NewSQL
   │                       │                    │
   ▼                       ▼                    ▼
简单 ACID              AP 层分片路由            透明分布式
垂直扩展               分布式事务复杂           SQL 自动路由
数据量 < 1TB           运维成本高              弹性伸缩
                      跨片 JOIN 困难           全局一致

选型没有绝对答案，关键匹配业务需求、团队技术栈和运维能力。对于已有 MySQL 生态的中文团队，TiDB 是最平滑的升级路径；对于全球化部署、要求最高隔离级别的场景，CockroachDB 值得优先考虑。