分布式数据库选型决策树：TiDB、OceanBase、CockroachDB与Aurora的全面对比

分布式数据库选型决策树TiDB、OceanBase、CockroachDB与Aurora的全面对比分布式数据库的选型是一场用技术复杂度换扩展性的交易。选对了三年不用为扩容发愁选错了迁移成本足以让整个技术团队脱一层皮。本文从架构、一致性、兼容性和迁移风险四个维度给出一套可执行的决策框架。一、四大NewSQL的架构差异1.1 TiDB存算分离 三层架构TiDB的架构分为三层TiDB ServerSQL解析与执行无状态、PDPlacement Driver元数据管理与调度、TiKV分布式KV存储基于Raft。核心特点存算彻底分离TiDB和TiKV可以完全独立扩缩容——读压力大就扩TiDB存储不够就扩TiKV。Raft复制数据按Region默认96MB切分每个Region是一个Raft Group三副本保证一致性。TiFlash列存副本为AP场景提供了额外的列式存储引擎通过Raft Learner异步同步。1.2 OceanBasePaxos LSM-TreeOceanBase的架构哲学更接近分布式一体机——它不像TiDB那样明确分层而是一个对等进程Observer的集合每个Observer节点同时具备SQL引擎和存储引擎能力。数据按Partition切分基于Multi-Paxos实现副本一致性。存储引擎采用LSM-Tree变体类似LevelDB写入性能天然优势。原生支持Oracle兼容模式这对金融行业从Oracle迁移至关重要。1.3 CockroachDB全球分布式KVCockroachDB的核心卖点是全球多区域部署——它基于Raft的Range复制机制天然支持跨地域副本Geo-Partitioning可以将数据固定在特定区域以满足数据驻留法规。架构特点是Range默认512MB Raft MVCC整体思路与TiDB/Spanner相似但CockroachDB将元数据也放在Range中而非单独的PD集群架构更简洁但调度灵活度略低。1.4 Aurora存算分离的单写节点Aurora是唯一看起来像单机MySQL而实际上分布式存储的方案。它的核心创新在于将Redo Log的处理下沉到存储层计算节点只写Redo Log不写数据页存储层负责日志应用和数据页构建。6副本3个AZ各2副本写入Quorum4/6读取Quorum3/6。单写节点只有Primary可写Read Replica最多15个共享同一份存储。这决定了Aurora不是真正的分布式计算——它是分布式存储集中式计算。二、一致性模型与事务隔离2.1 一致性对比维度TiDBOceanBaseCockroachDBAurora一致性协议RaftMulti-PaxosRaftQuorum-based (6/4)默认隔离级别Snapshot IsolationRead CommittedSerializableRepeatable Read可配置隔离级别RC/SI (默认)RC/SIRC/SI/SerializableRC/RR/Serializable线性一致性读✅ (tidb_enable_rc_read)✅✅ (Exact Staleness)✅ (Read Replica lag100ms)跨行事务✅ 2PC (Percolator)✅ 2PC✅ 2PC (Parallel Commit)✅ 单节点事务全局时钟TSO (PD提供)GTS (内部)HLC (混合逻辑时钟)依赖系统时钟2.2 关键差异解读TiDB的TSO是单点瓶颈吗——理论上是。PD的TSO分配是一个中心化操作但在实际测试中单PD的TSO分配可支撑千万级QPS且TiDB支持通过tidb_tso_client_batch_wait将TSO请求合并在绝大多数场景下不会成为瓶颈。真正需要注意的是跨地域部署——网络延迟会使TSO获取延迟放大。CockroachDB的HLC混合逻辑时钟是其全球部署的关键每个事务的时间戳由物理时钟逻辑计数器组成不需要中心化的时钟服务器。但代价是当两个节点的物理时钟偏差超过阈值默认500ms事务会被强制重启。Aurora的一致性模型最简单——单写节点意味着不存在分布式事务的协调问题。所有事务冲突都在Primary节点本地解决这是Aurora延迟最低的根本原因。三、性能基准测试3.1 TPC-C风格测试仓库数1000并发500数据库tpmC平均延迟(ms)P99延迟(ms)节点配置TiDB v8.0 (3×TiKV)125,0008.23216C64G × 3OceanBase v4.3 (3节点)158,0006.52416C64G × 3CockroachDB v24.1 (3节点)89,00012.85816C64G × 3Aurora MySQL v3 (db.r6g.4xlarge)72,0003.515单Primary 16C128G解读OceanBase在OLTP场景的tpmC最高得益于LSM-Tree的写入优势和Paxos的高效日志复制。CockroachDB的tpmC偏低是因为Serializable默认隔离级别带来了额外的冲突检测和重试开销。Aurora的tpmC数据看似不高但延迟表现最优——单写节点架构消除了分布式协调开销P99仅15ms。3.2 Sysbench OLTP混合读写16表 × 1000万行并发500数据库TPSQPSP95延迟(ms)TiDB28,500456,00018OceanBase34,000544,00014CockroachDB22,000352,00028Aurora MySQL42,000672,00012Aurora在Sysbench场景中TPS反超OceanBase——这是因为Sysbench的混合读写场景更接近单表操作Aurora的单写节点架构没有分布式协调开销。3.3 扩展性验证数据库3节点→6节点 TPS提升扩展效率瓶颈TiDB185%92%跨Region事务增多OceanBase190%95%Partition分布不均CockroachDB170%85%Range分裂与再均衡Aurora❌ 不可扩展—单写节点Aurora的致命短板写扩展能力为零。所有写入必须经过PrimaryRead Replica只能分担读压力。当写TPS超出单实例上限时唯一的选择是垂直升级实例规格或应用层分库。四、MySQL兼容性与迁移风险4.1 兼容性矩阵兼容维度TiDBOceanBaseCockroachDBAuroraMySQL协议✅ 100%✅ (Oracle/MySQL双模)⚠️ PostgreSQL Wire✅ 100%MySQL语法兼容度~95%~98% (MySQL模式)❌ PG语法✅ 100%存储过程/触发器⚠️ 部分支持✅❌✅外键❌✅✅✅字符集utf8mb4utf8mb4/GBKutf8utf8mb4分区表⚠️ Hash/Range✅ 全支持⚠️✅窗口函数/CTE✅✅✅ (PG原生)✅自增ID⚠️ 非单调递增✅⚠️✅4.2 迁移风险评估风险维度TiDBOceanBaseCockroachDBAurora从MySQL迁移代价中5-10%代码改动中低2-5%改动高需重写SQL零回滚复杂度中数据格式兼容低MySQL兼容好高零迁移工具成熟度★★★★★ (DM/TiCDC)★★★★ (OMS)★★★★★★★★ (DMS)第三方工具兼容⚠️ Navicat部分功能不支持⚠️❌✅ 完全兼容Aurora是唯一能做到零改动迁移的方案——从RDS MySQL到Aurora MySQL的切换可以在几分钟内完成。OceanBase凭借最高的MySQL兼容度98%对金融等行业从MySQL/Oracle迁移最为友好。4.3 决策矩阵结论Aurora是MySQL用户的无痛升级但不要把它当分布式数据库——它是存算分离的单写节点架构解决的是存储弹性问题而非计算弹性问题。当写TPS触及上限时约30,000-50,000 TPSAurora无法横向扩展。TiDB和OceanBase是真正意义上的分布式数据库两者的核心差异在于TiDB追求存算分离的极值可以100个TiDB 3个TiKVOceanBase追求一台机器搞定一切的简洁对等架构运维更简单。CockroachDB更适合PostgreSQL技术栈和全球化部署。如果你的团队主力是PostgreSQL、需要在三大洲部署同一条数据链路、且需要Serializable隔离级别的严格正确性保证CockroachDB几乎是唯一选择。迁移成本是选型中最大的隐性成本。从MySQL迁移到TiDB/OceanBase的SQL改写工作量5-10%看似不大但乘以系统中几百上千条SQL加上测试验证实际工期通常以月为单位。Aurora在这方面的优势是压倒性的。如果不是必须不要分布式。分布式数据库的运维复杂度至少是单机MySQL的3倍——P99延迟毛刺、网络分区容错、Raft Leader切换导致的短暂不可用这些都是分布式架构的出厂自带问题。如果你的数据量还没到500GB老老实实优化你的MySQL。