NewSQL三大流派全景：从单店药房到全国连锁

可视化演示

展示CockroachDB、TiDB与YugabyteDB三大NewSQL流派：存储引擎、事务模型与一致性保证对比，通过交互理解SQL兼容与水平扩展选型。

背景与定义

小镇上那家老药房（单机 SQL 数据库）经营了几十年，口碑极好。可随着小镇变成千万人口的都市，药房门口排起长队，老板就算三头六臂也忙不过来。这时有人说：为什么不把药房搬到更多街区去呢？于是出现了没有统一规范的“游医摊”（NoSQL）——它们确实铺得快，可病人在这家看的病、在另一家开的药，完全没有记录关联。NewSQL 的使命，就是造出一家“规范又连锁”的大型药房网络。

连锁药房如何既保持老药房的服务标准（SQL 兼容），又拥有覆盖全国的能力（水平扩展）？答案是“开分店”：把数据切成若干分片，每个分片放在不同的分店（节点）里，同时给每份数据准备几个副本。分店越多，能接待的客流越大；副本越多，单店出问题也不影响整体营业。CockroachDB、TiDB、YugabyteDB 就是三种不同的“连锁管理方案”，它们都将数据分区与复制作为地基，差异体现在对分店的管理方式上。

展开来看，三者有一个共同的数学逻辑：系统的容量与数据被切成的分片数成正比，容错能力则与副本数成正比。于是有了如下关系。

由此可知，NewSQL 并非某种单一技术，而是一套“既要也要”的系统工程。接下来，我们逐一走进三家连锁药房，看它们各自的经营哲学。

CockroachDB：总店强中心

CockroachDB 的连锁模式，像是有一个极有权威的总店：所有分店都严格对齐总店的时钟。你在上海分店上午 10 点开的处方，北京分店 10 点零 1 秒查询时，必定能看到。这种“全局时钟”由混合逻辑时钟（HLC）实现，它把物理时间与逻辑事件序号结合，让所有节点对“谁先谁后”达成一致。

有了统一的时间观，CockroachDB 用 Raft 共识算法管理每个数据分片的副本组。每个分片的数据存 3~5 份，副本之间通过多数派投票决定谁来当“领头店长”（Leader）。写请求只发给 Leader，Leader 将日志复制给多数派 Follower 后才算成功。这种机制保证了即使少数分店失联，系统依然能正常营业。

跨分片的事务则依靠两阶段提交（2PC）协调，配合全局时钟实现可串行化隔离。这让 CockroachDB 成为强一致爱好者的首选——但代价是跨区域延迟较高。它的核心公式在于多数派决策：

CockroachDB 就像纪律严明的连锁总店：每个分店都在同一时间标准下工作，重大决策必须多数店长点头。这种“强中心”风格，换来的是让金融监管都放心的数据一致性。

TiDB：分店自治海报栏

TiDB 的连锁哲学截然不同：分店各自记账，但总部会定期贴出“海报栏”（全局快照），让大家看到某个时刻的完整账本。TiDB 将体系分为三层：最上层是无状态的 TiDB Server（相当于接待前台），中间是存储层 TiKV（一个分布式的 Key-Value 仓库），最底下是 PD 调度模块（负责分片管理与负载均衡）。前台与仓库分离，意味着前台可以随意增减，轻松应对突发客流。

TiKV 底层的存储引擎是 RocksDB，它采用 LSM-Tree 结构，写入像往快递仓库扔包裹一样快。每个数据分片（Region）默认保存 3 份副本，并用 Raft 协议同步。TiDB 的招牌技术是多版本并发控制（MVCC）：每行数据保留多个历史版本，每个版本打上“写入时间戳”。读请求拿到一个全局快照时间戳后，只需找到对应时间点的版本即可，读写互不阻塞。

MVCC 的核心是版本可见性判断。当一个事务的读时间戳为 $T_{read}$ 时，只有满足以下条件的版本才可见。

TiDB 的 MVCC 就像药房的海报栏：顾客看的是贴出来的历史公告，店员在后面改账本也互不打扰。这种设计让 TiDB 在读写混合场景下表现出色，同时高度兼容 MySQL 协议，让无数 MySQL 团队零改造迁移。

YugabyteDB：先写行程单

YugabyteDB 的经营方式更有趣：每个分店在办事之前，先在小黑板上写一份“行程单”——我接下来要做什么——然后按单执行。这个“行程单”其实就是预写日志（WAL）。YugabyteDB 的查询层直接复用 PostgreSQL 的代码，所以它几乎 100% 兼容 PostgreSQL 的语法、类型和扩展生态。存储层叫 DocDB，是一个基于 RocksDB 的分布式文档存储系统，数据模型是“表+行+列”的嵌套结构。

事务被明确分成两层：如果操作只涉及单个分片内的数据，就在本地用 PostgreSQL 风格的事务解决，开销极小；如果操作跨多个分片，才升级为分布式事务（常用两阶段提交）。这种分层的好处非常直观：大多数业务请求只访问少量行，本地事务就够了，不必每次都付出昂贵的跨节点协调成本。

用公式表达本地事务与分布式事务的代价差异：

YugabyteDB 的策略很务实：大多数处方只需一个柜台搞定，少数需要多科室会诊的才大动干戈。这让它成为深度使用 PostgreSQL 的团队最顺手的分布式升级路径。

存储引擎对比：仓库怎么摆货

现在走进三家药房的仓库。仓库的货物摆放方式，直接决定了药房抓药（读）和进货（写）的速度。传统老药房（如 MySQL 的 InnoDB）用的是 B+Tree：货架永远按药品编号排得整整齐齐，找药极快，但每次进货都要重新腾挪位置，写多时效率下降。三家中最特殊的是 TiDB 和 CockroachDB，它们的存储层都建立在 RocksDB（LSM-Tree）之上，而 YugabyteDB 的 DocDB 也用了 RocksDB。

LSM-Tree 的哲学是“先堆后理”：新货物先扔进内存的“待整理区”（MemTable），攒够一批再批量刷到磁盘上的“货架”（SSTable）。写入永远是好玩的追加操作，所以写性能极高；但读取要依次查看内存、各级磁盘文件，数据越久越深，读起来相对费劲。这就引出了一个关键指标——读写放大。

写放大（Write Amplification）衡量实际写入磁盘的数据量是逻辑写入量的多少倍：

选型时看清读写比很重要：日志型、IoT 型业务写多读少，LSM 系（TiDB、CockroachDB）如鱼得水；报表型、复杂查询业务读多写少，也许传统 B+Tree 或带强缓存的方案更合适。

事务模型对比：需要几个科室盖章

一张处方若同时涉及心内科和呼吸科，两个科室都得盖章确认，缺一不可。分布式数据库的事务模型也是这个道理：如果一次操作的数据恰好都在同一个分片内，那只需一个“科室”（节点）盖章，这就是单分片事务；如果数据散落在多个分片，就需要所有相关节点同时确认，这就是分布式事务。

CockroachDB 对跨分片事务采用两阶段提交（2PC）加重试机制，配合全局时钟实现严格的可串行化；TiDB 采用乐观锁思路，先假定事务不会冲突，提交时若检测到版本冲突则让事务重试；YugabyteDB 则偏向悲观锁，在事务开始时加锁，冲突少但等待可能增多。三种风格没有绝对优劣，要看业务冲突的比例。

两阶段提交的提交条件可以形式化为：

跨科室盖章总是比单科室麻烦，但这是保证连锁药房“处方不乱”的必要代价。并发高、单事务涉及行少的业务，应尽量避免频繁触发分布式事务——这也是选型时的优化要点。

一致性保证：各地对账的严苛程度

连锁药房最怕什么？同一张处方在广州是 100 元，在上海查变成 120 元。一致性保证就是规定各分店在什么时间点对账、对账后看到什么。CockroachDB 提供线性一致性：任何读操作都像在“绝对公平的队列”里排队，一旦某条写请求完成确认，之后所有读请求必然读到它——哪怕这些读发生在另一个城市。

TiDB 默认提供快照隔离：每个事务基于一个固定的历史快照运行，比如午时 12:00 整的账本。大家在午时看的是同一份数据，但午时之后新开的处方不会被这个快照看到。YugabyteDB 提供 PostgreSQL 级别的隔离强度，默认是读已提交（Read Committed），可选串行化——即所有事务像排队买单一样，效果上等价于串行执行。

线性一致性的数学刻画是对操作顺序的约束：

选择哪档一致性，取决于业务能否容忍“短暂读旧”。金融转账必须线性一致；而商品库存、内容社区用快照隔离也足够，没必要为极致一致付出高延迟的代价。

选型与最佳实践：按店址选品牌

介绍完三家连锁的脾气，终于到了做决定的时刻。选型就像为一座新城挑选药房品牌，关键看地段和客流：如果业务是金融交易、订单支付，强一致是底线，CockroachDB 的线性一致性最为稳妥；如果团队已有 MySQL 背景、业务要平滑扩容，TiDB 的 MySQL 生态能让你少掉头发；如果公司重度使用 PostgreSQL 的 JSON、地理空间等高级特性，YugabyteDB 是最平滑的分布式延伸。

集群规划时要把容量、分片、跨域复制统筹考虑。数据量暴涨前，应预先设计好分片键，避免热点分店被挤爆；跨区域部署时，把副本放在不同可用区甚至不同城市，保证地震火灾都撼动不了核心账本。日常运维则需要搭好监控体系：三大数据库都原生支持 Prometheus 指标暴露与 Grafana 仪表盘，慢查询日志、副本落后时间、Raft 投票活跃度是重点观测项。

从成本角度综合权衡：

选型没有最好的数据库，只有最匹配业务的数据库。把一致性需求、团队技能、读写特征和运维成本放在一张表里打分，答案会自己浮现。

AI 应用场景

Python 演示

import random  class Node:    """模拟 Raft 副本组中的一个节点。"""     def __init__(self, node_id):        self.node_id = node_id        self.log = []     def append_entry(self, entry):        self.log.append(entry)        return True  class RaftGroup:    """简化版 Raft 法定人数日志复制模拟器。"""     def __init__(self, n_nodes, leader_index=0):        self.nodes = [Node(i) for i in range(n_nodes)]        self.leader = self.nodes[leader_index]        self.quorum = n_nodes // 2 + 1     def write(self, value):        entry = {"value": value, "term": len(self.leader.log) + 1}        self.leader.append_entry(entry)        acks = 1  # leader 自己算一票        for node in self.nodes:            if node is self.leader:                continue            if random.random() < 0.9:  # 成功复制概率 90%                node.append_entry(entry)                acks += 1        if acks >= self.quorum:            print(f"提交成功: {value}  (法定人数={self.quorum}, 确认={acks})")            return True        print(f"提交失败: {value}  (法定人数={self.quorum}, 确认={acks})")        return False     def read_leader_log(self):        return [e["value"] for e in self.leader.log]  if __name__ == "__main__":    group = RaftGroup(n_nodes=5, leader_index=0)    for i in range(1, 7):        group.write(f"处方-{i}")    print("Leader 日志:", group.read_leader_log())    print("各节点日志条数:", [len(n.log) for n in group.nodes])

1. quorum = n_nodes // 2 + 1计算法定人数，5 个节点时需要 3 个确认才能提交。
2. random.random() < 0.9模拟网络可能丢包，让每份副本的复制并非 100% 成功。
3. acks >= self.quorum只有确认数达到法定人数，写操作才真正落盘，这是 Raft 安全性的核心。
4. read_leader_log()读请求由 Leader 处理，确保读到的是已被多数确认的日志。

常见误区

面试题