想象你是一家计划在全国开分店的连锁奶茶店老板。选址、后厨、收银、冷链都要复制到每一家分店，而顾客无论走进哪一家，都应该喝到同一杯配方、付同一套价格。这正是云原生分布式数据库要做的事：数据散落在多个节点，却对外表现得像一台可靠的机器。TiDB、CockroachDB、YugabyteDB 就是三位装修风格完全不同的店长，他们的后厨布局，直接决定这杯茶怎么做、做多快、能不能防泼洒。本文会走进这三家后厨，对比它们存储原料的方式、点单的方言、做奶茶的事务流程，以及全国门店如何同步，最后帮你算一笔加盟账。

岗位关联

学习云原生数据库架构，能让你在技术选型、性能诊断和迁移方案设计时，不只看到表面跑分，而是理解每款产品背后的取舍逻辑，成为团队里最懂“怎么选”的那位专家。

目录
  1. 可视化演示
  2. 架构全景：三家连锁的“后厨总览”
  3. 存储引擎：奶茶原料的摆放密码
  4. SQL 兼容层：点单要用什么方言
  5. 事务模型：做一杯奶茶如何不洒
  6. 多区域高可用：全国门店如何同步
  7. 性能与选型：哪家出杯快
  8. 选型场景：你的店该加盟哪家
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示TiDB/CockroachDB/YugabyteDB分布式架构、多模型对比与水平扩展分片，交互切换查看核心设计。

本节配有交互动效（进入视口后自动加载，约 3KB）。

分布式架构 多节点Raft共识，Leader处理写入Follower同步 SQL层与存储层分离，计算无状态可弹性扩展 Quorum = floor(N/2) + 1 调节节点数查看共识与副本变化

架构全景：三家连锁的“后厨总览”

想象你是一家计划在全国开分店的连锁奶茶店老板。选址、后厨、收银、冷链都要复制到每一家分店，而顾客无论走进哪一家，都应该喝到同一杯配方、付同一套价格。这正是云原生分布式数据库要做的事：数据散落在多个节点，却对外表现得像一台可靠的机器。TiDB、CockroachDB、YugabyteDB 就是三位装修风格完全不同的店长，他们的后厨布局，直接决定这杯茶怎么做、做多快、能不能防泼洒。

三个后厨都分三层：门口的收银员负责听顾客点单、承诺出杯时间，这就是无状态的 SQL 层；中间的原料仓库负责存储茶、奶、珍珠，这就是存储引擎；店长则调度哪家分店缺货、新店开在哪里，这就是调度组件。TiDB 把这三层拆成 TiDB Server、TiKV、PD 三个独立角色；CockroachDB 把所有角色塞进同一个二进制，只在逻辑上区分 SQL 层、事务层和存储层；YugabyteDB 用 YB-Master 管元数据、YB-TServer 管数据。无论分工怎么变，它们都共用一句行话：过半确认。

这句行话正是 Raft 共识协议。在一个有 n 个副本的集群里，只有超过一半副本确认，一条数据才能算真正提交。n=3 时需要 2 票，n=5 时需要 3 票。这样少数派节点慢一点、甚至暂时宕机，集群都不会卡死，也不会出现两个节点都宣称写入成功的数据分叉。

回到奶茶店，三套方案都守着同一条规矩：过半门店确认新配方收到，新品才允许上架。后厨可以各有千秋，但这条“过半再开卖”的底线，是所有云原生分布式数据库共同的骨架。

q=⌊n2⌋+1q = \left\lfloor \frac{n}{2} \right\rfloor + 1
多数派公式：过半确认，既保证可用性，又阻止脑裂。
  1. n 表示副本总数指参与投票确认的节点数量，比如 3 个分片副本。
    nn
  2. 整除 2 向下取整先看“一半”是多少，再取整数部分，忽略小数。
    ⌊n2⌋\left\lfloor \frac{n}{2} \right\rfloor
  3. 加 1 形成多数在半数基础上多 1 票，保证任何两个多数派必然有重叠。
    ⌊n2⌋+1\left\lfloor \frac{n}{2} \right\rfloor + 1

存储引擎：奶茶原料的摆放密码

茶叶、牛奶、珍珠摆在哪里，决定了后厨效率。TiDB 的 TiKV 把每一行奶茶数据编码成一个键值对，底层借助 RocksDB 落盘；CockroachDB 用 Go 语言重写了 Pebble 引擎，追求更小的内存开销；YugabyteDB 的 DocDB 则把一行记录当成一份文档，兼顾 JSON 灵活性与关系表的严谨。

光有原料还不够，分店多了要按地区切分库存。TiKV 把数据切成默认约 96MB 的 Region，CockroachDB 切成约 64MB 的 Range，YugabyteDB 切成 Tablet。每个分片都拥有多副本，散落在不同节点，这样既能横向扩容，又能在节点故障时把副本补位。

无论哪种引擎，落盘前都要给行数据一个唯一地址。地址由表前缀和行 ID 拼接，再对分片数量取模，就知道该进哪个格子。

三家的货架摆法各有味道：TiKV 像把每杯成品分装成独立小包装，CockroachDB 用更轻的 Pebble 抽屉减少浪费，YugabyteDB 的 DocDB 则在每张卡片上写满配方、温度、甜度。但殊途同归，都是为了在海量订单里快速找到一杯茶，并把新店无痛接入。

key=tablePrefix⊕rowID,regionID=hash(key) mod N\mathrm{key} = \mathrm{tablePrefix} \oplus \mathrm{rowID}, \quad\mathrm{regionID} = \mathrm{hash}(\mathrm{key}) \bmod N
行数据先编码为键值对，再哈希取模找到分片，存储引擎读写时才能精准定位。
  1. 键值对编码整行数据作为 value，key 是它在分布式系统中的唯一地址。
    value=rowData\mathrm{value} = \mathrm{rowData}
  2. key 拼接表前缀避免不同表的数据混淆，rowID 在一张表内唯一。
    key=tablePrefix⊕rowID\mathrm{key} = \mathrm{tablePrefix} \oplus \mathrm{rowID}
  3. 哈希运算把 key 打散成看似随机的数字，让数据均匀分布到 N 个分片。
    hash(key)\mathrm{hash}(\mathrm{key})
  4. 取模定位对 N 取余数，决定这条数据属于哪个 Region、Range 或 Tablet。
    regionID=hash(key) mod N\mathrm{regionID} = \mathrm{hash}(\mathrm{key}) \bmod N

SQL 兼容层：点单要用什么方言

点单要靠方言。TiDB 选择说 MySQL 方言，无数老应用只要改改连接串就能进门；CockroachDB 和 YugabyteDB 选择说 PostgreSQL 方言，支持更丰富的类型、索引和窗口函数；YugabyteDB 还额外派出一个会讲 Cassandra 方言的服务生 YCQL，照顾过去用 NoSQL 的客人。

说方言只是第一步，真正考验人的是后厨协作。SQL 层收到一条查询后，不会把整张表拉回一台机器硬算，而是把查询计划拆成多个子任务，交给不同分片的存储节点并行执行，最后再合并结果。这就是分布式执行器。

所以选店不能只看招牌。如果老团队只会 MySQL 话术，TiDB 是顺手的续杯；如果团队天天写 PostgreSQL，CockroachDB 和 YugabyteDB 更亲切。点单方言影响迁移成本，分布式执行器则决定大单会不会压垮后厨。

result=⋃r=1mσθ(Rr)\mathrm{result} = \bigcup_{r=1}^{m} \sigma_{\theta}(R_r)
一条 SQL 会被拆成对每个分片 \(R_r\) 的过滤操作，再把结果并集合并起来。
  1. 分片关系 \(R_r\)表示第 r 个分片中的那张表的数据。
    RrR_r
  2. 过滤操作 \(\sigma_{\theta}\)按查询条件 \(\theta\) 只留下满足条件的行。
    σθ(Rr)\sigma_{\theta}(R_r)
  3. 并集合并把每个分片的过滤结果合并成完整结果集。
    ⋃r=1mσθ(Rr)\bigcup_{r=1}^{m} \sigma_{\theta}(R_r)

事务模型：做一杯奶茶如何不洒

做一杯奶茶，最怕做到一半洒了。分布式数据库的事务，就是保证“茶、奶、珍珠要么都加，要么都不加”。TiDB 采用 Percolator 模型的两阶段提交，先给主记录打 prepare 标记，所有参与者确认后再写 commit；CockroachDB 用混合逻辑时钟 HLC 给事务排序，实现可串行化快照隔离；YugabyteDB 则用 DocDB 的冲突检测与重试，在写冲突时自动回滚。

三家的最终目标都是 ACID 事务。TiDB 靠全局时间戳决定先后，CockroachDB 靠 HLC 保证不依赖单一授时中心，YugabyteDB 则把事务状态记录在 DocDB 里。它们都遵循一个朴素法则：先准备，再落锤。

就像你点单时，收银员先跟后厨确认所有原料都齐，再一次性打小票。TiDB 靠中央时间戳，CockroachDB 靠自带时钟，YugabyteDB 靠文档状态机；不管哪种办法，都没人敢在原料没备齐时先把奶茶递给顾客。

txn∈{prepare,commit,abort},commit_ts>all_start_ts\mathrm{txn} \in \{\mathrm{prepare}, \mathrm{commit}, \mathrm{abort}\}, \quad\mathrm{commit\_ts} > \mathrm{all\_start\_ts}
事务先在 prepare 阶段试探，拿到一个大于所有已开始事务时间戳的 commit_ts，才能安全提交。
  1. 事务状态集合事务只有在 prepare、commit、abort 三种状态间流转。
    txn∈{prepare,commit,abort}\mathrm{txn} \in \{\mathrm{prepare}, \mathrm{commit}, \mathrm{abort}\}
  2. commit_ts 是提交时间戳记录事务真正生效的全局时间点。
    commit_ts\mathrm{commit\_ts}
  3. 提交条件提交时间戳必须大于所有已开始事务的开始时间戳，才能保证不会读到旧数据。
    commit_ts>all_start_ts\mathrm{commit\_ts} > \mathrm{all\_start\_ts}

多区域高可用：全国门店如何同步

全国门店同步，最难的是跨城市保持一致。三款数据库都把 Raft 作为复制骨架：每个分片的多个副本分布在不同的机房或区域，Leader 更新日志后，Follower 跟着补货。只有多数派确认，数据才算安全。

差异在策略细节。TiDB 的 PD 可以根据机房拓扑下发 Placement Rules，把副本放到指定城市，还能用 Raft Learner 做异地只读备份；CockroachDB 提出区域生存目标，可以选择“区域级可用”或“机房级别可用”，并用 leaseholder 把读写放到离用户最近的副本；YugabyteDB 默认同步复制，也提供 xCluster 做跨集群异步容灾。

所以跨城调货，永远看最远的确认店脸色。想要顾客在成都拿到和北京同一口味的奶茶，商家必须算清楚：哪些城市进 Q 集合，以及 Leader 该放在离用户最近的地方。

Trepl=max⁡i∈QRTT(L,i)T_{\mathrm{repl}} = \max_{i \in Q} \mathrm{RTT}(L, i)
同步复制的耗时，取决于多数派集合 Q 中离 Leader 最远的那个副本的往返延迟。
  1. 多数派集合 Q是本轮提交必须确认的那组副本。
    QQ
  2. 往返延迟 RTT(L, i)Leader L 与副本 i 之间一次网络请求的往返时间。
    RTT(L,i)\mathrm{RTT}(L, i)
  3. 取最大值同步复制不会比最慢的确认者更快。
    max⁡i∈QRTT(L,i)\max_{i \in Q} \mathrm{RTT}(L, i)

性能与选型：哪家出杯快

比出杯速度，不能只看单店效率。跨地域延迟上，CockroachDB 的 leaseholder 路由和区域表设计优势明显；扩展性上，三款都能水平扩分片，但 YugabyteDB 对高并发写入的吞吐提升更直接；TiDB 的独门武器是 TiFlash 列存，让同一份数据既能做事务又能跑分析，也就是 HTAP。

运维复杂度同样影响“出杯”。TiDB 组件多，部署和调优门槛高；CockroachDB 只有一个二进制，上云最省心；YugabyteDB 居中，还保留了 PostgreSQL 生态的运维习惯。性能对比不能只看跑分，还要看团队养得起几个店长。

快不是唯一指标。TiDB 像大而全的旗舰店，CockroachDB 像标准化的连锁快闪店，YugabyteDB 像会多国语言的社区店；选哪家，得看你手里有多少店员、顾客分布在哪里，以及是不是马上要上数据分析。

WA=physical bytes writtenlogical bytes written\mathrm{WA} = \frac{\text{physical bytes written}}{\text{logical bytes written}}
写放大衡量存储引擎为了写入 1 字节业务数据，实际在磁盘上写了几字节；LSM-Tree 引擎通常会有一定写放大。
  1. 实际写入字节数磁盘物理层真正落盘的字节数，包含排序、合并等额外写操作。
    physical bytes written\text{physical bytes written}
  2. 逻辑写入字节数应用层认为业务数据只写入了多少字节。
    logical bytes written\text{logical bytes written}
  3. 比值含义比值越大，SSD 磨损越严重，高并发写入性能越差。
    physical bytes writtenlogical bytes written\frac{\text{physical bytes written}}{\text{logical bytes written}}

选型场景：你的店该加盟哪家

加盟哪家品牌，本质是选适配自己场景的答案。已经有 MySQL 存量代码、还想在一个集群里跑风控报表，TiDB 的兼容性和 HTAP 能力最省事；业务横跨多个大区、订单对一致性要求极高，CockroachDB 的多区域强一致更安心；团队熟悉 PostgreSQL、又希望写入能随业务暴涨而水平扩展，YugabyteDB 值得优先测试。

部署考量也不可少：自建机房与公有云托管、副本数、跨区域带宽、监控告警、备份恢复，都应该变成可以打分的指标。

没有最好的奶茶店，只有最适合你的加盟方案。先把自己的需求列成评分表，再用三家后厨的真实架构打分，答案往往不会太远。

Score=∑i=1nwi×si\mathrm{Score} = \sum_{i=1}^{n} w_i \times s_i
把兼容性、延迟、写放大、运维复杂度等维度分别打分，再按业务权重加权求和，得到选型总分。
  1. 第 i 个维度权重 \(w_i\)表示这个维度对你业务的重要性，比如金融业务更看重强一致。
    wiw_i
  2. 第 i 个维度得分 \(s_i\)对每款数据库在该维度上的表现打一个分。
    sis_i
  3. 加权求和所有维度的权重乘得分累加，得到一个可比较的总分。
    ∑i=1nwi×si\sum_{i=1}^{n} w_i \times s_i

AI 应用场景

金融核心系统迁移适配

阶段：数据基础设施选型与迁移

解决的问题：传统银行系统基于 MySQL，单库容量见顶，分库分表改造成本高、运维复杂。TiDB 提供 MySQL 协议兼容和 HTAP 能力，让同一套集群既能跑在线交易，又能支撑实时风控和报表，大幅降低迁移风险。

具体案例：某支付平台把账户流水从分库分表架构迁到 TiDB，SQL 层基本不改，仅调整连接串和少量语法，同时用 TiFlash 列存能力支持实时对账查询。

跨境电商多区域订单中心

阶段：在线交易数据层

解决的问题：订单数据需要跨区域强一致，传统主从复制延迟高、故障时可能丢数据。CockroachDB 通过多区域 Range 和 leaseholder 路由，让读写尽量发生在用户就近的区域，同时保持强一致。

具体案例：跨境电商把订单和库存表设置为区域表，欧、亚、美三地用户下单，写入延迟明显下降，跨区域故障时依然可以自动切换。

AI 实时推荐的特征存储

阶段：特征服务数据层

解决的问题：推荐系统需要高频写入用户行为、实时读取特征，PostgreSQL 单机写入容易成为瓶颈。YugabyteDB 提供 PostgreSQL 兼容接口和水平写入扩展，同时支持事务性更新特征。

具体案例：内容推荐团队把用户画像表迁移到 YugabyteDB，保留原有 ORM 代码，通过 YSQL 接口访问，写入吞吐提升明显，且多副本保证特征不丢。

Python 演示

python33 行
# 一个简化版 Raft 投票模拟器, 用于理解分布式数据库多数派机制def quorum(n):    return n // 2 + 1  class RaftVote:    def __init__(self, total):        self.total = total        self.approved = 0     def approve(self):        self.approved += 1     def can_commit(self):        return self.approved >= quorum(self.total)  PROFILES = [    {"name": "TiDB", "engine": "TiKV/RocksDB", "dialect": "MySQL"},    {"name": "CockroachDB", "engine": "Pebble", "dialect": "PostgreSQL"},    {"name": "YugabyteDB", "engine": "DocDB/RocksDB", "dialect": "PostgreSQL"},] if __name__ == "__main__":    print("=== Cloud-native DB profiles ===")    for item in PROFILES:        print("name:", item["name"], "| engine:", item["engine"], "| dialect:", item["dialect"])     vote = RaftVote(3)    vote.approve()    vote.approve()    print("3 replicas, 2 approved, commit allowed:", vote.can_commit())    print("Expected majority count:", quorum(3))
目的：用一个小型 Python 类模拟三副本 Raft 集群的“多数派确认”，同时打印三款数据库的核心架构配置，帮你把抽象概念变成可运行的直觉。
  1. def quorum(n):定义多数派门槛函数，这是 Raft 提交的核心规则。
  2. return n // 2 + 1整数除法向下取整后加 1，得到过半票数。
  3. class RaftVote:模拟一次分布式写入的投票过程。
  4. self.approved += 1每收到一个副本确认，就把赞成票加一。
  5. return self.approved >= quorum(self.total)赞成票达到多数派时允许提交。
  6. PROFILES = [用列表记录三款数据库的存储引擎和 SQL 方言。
  7. vote.approve()模拟两个副本给出确认，对应三副本中的多数派。

常见误区

误区TiDB 兼容 MySQL，CockroachDB 兼容 PostgreSQL，那我原来用的存储过程、触发器、分区语法应该都能无缝迁移吧？

正解兼容层主要覆盖常用 SQL 语法、协议握手和连接驱动，不等于实现每一个数据库特性。比如 TiDB 对存储过程和触发器的支持有限，CockroachDB 对部分 PostgreSQL 扩展也有差异。比喻：两家店都叫“奶茶店”，点单方式一样，但这家有芋圆那家没有。选型前一定要做 SQL 兼容性测试。

为何常见：因为厂商宣传常强调“兼容”，用户容易把“协议兼容”理解成“语义完全一致”。

误区为了保证强一致，三副本肯定要三个节点都写完才能给客户端返回成功吧？

正解Raft 只需多数派确认即可提交，三副本中两票就能成功。少数派落后只会被 Leader 日志追平，不会阻塞正常写入。比喻：店长只要收到两家分店“已收到”就开卖，第三家稍后补签，不会让顾客等所有店长都点头。

为何常见：直觉上“全确认最安全”，忽略了多数派与少数派互补的数学性质。

误区把 MySQL 打成 Docker 镜像扔到 Kubernetes 上，就是云原生数据库了吧？

正解云原生数据库的核心是架构上计算与存储分离、分片弹性扩缩容、按需使用；跑在 K8s 只是部署形态之一。比喻：把奶茶店搬进购物中心不叫连锁化，真正的连锁要统一配方、实时调货、复制分店。

为何常见：因为“云原生”这个词和容器、Kubernetes 经常一起出现，产生语义混淆。

误区三款分布式数据库都能横向扩展，那分析型大查询也交给同一个集群跑就行了吧？

正解TiDB 有 TiFlash 列存专门支持分析负载；CockroachDB 和 YugabyteDB 主要还是 OLTP 优化，重型分析查询仍需要外部数仓或数据导出。比喻：能快速出杯不等于能包下整场宴会的外烩，后厨设备不同。

为何常见：因为三者在宣传中都会讲“扩展能力”，用户把扩展性等同于全场景能力。

面试题

Q1. TiDB 的 SQL 层主要负责什么？

单选题 · easy

  • A.兼容 MySQL 协议并生成分布式执行计划← 正确答案
  • B.直接存储每一行数据
  • C.负责 Raft 日志复制
  • D.只做负载均衡不解析 SQL

答案：A。TiDB Server 是无状态 SQL 层，负责协议接入、解析、生成执行计划；数据存储由 TiKV 负责，调度和分片由 PD 负责。B、C、D 都把职责错误地安到 SQL 层身上。

Q2. 三款云原生数据库共同使用的多副本共识协议是？

单选题 · easy

  • A.Paxos
  • B.Raft← 正确答案
  • C.PBFT
  • D.Gossip

答案：B。TiDB、CockroachDB、YugabyteDB 都使用 Raft 保证多副本日志一致。Paxos 是另一种共识算法，PBFT 用于拜占庭容错，Gossip 常用于节点信息传播而非强一致日志复制。

Q3. 三副本 Raft 集群中，Leader 提交一条日志至少需要几个副本确认？

单选题 · easy

  • A.1 个
  • B.2 个← 正确答案
  • C.3 个
  • D.0 个（不需确认）

答案：B。根据多数派公式，3 个副本需要 2 个确认即可提交。Leader 自身算一票，再加任意一个 Follower 确认就达到多数派，这也是 Raft 容错 1 个节点故障的原因。

Q4. CockroachDB 使用哪种机制为分布式事务排序？

单选题 · mid

  • A.Unix 时间戳
  • B.混合逻辑时钟 HLC← 正确答案
  • C.单调递增计数器
  • D.原子钟同步

答案：B。CockroachDB 使用混合逻辑时钟，把物理时间和逻辑计数器结合，避免依赖单一授时中心。Unix 时间戳无法保证跨节点因果顺序，单调计数器无法全局统一，原子钟同步成本过高。

Q5. YugabyteDB 的 YSQL 接口主要兼容哪种数据库方言？

单选题 · mid

  • A.MySQL 8.0
  • B.PostgreSQL← 正确答案
  • C.Oracle
  • D.SQL Server

答案：B。YugabyteDB 的 YSQL 主要兼容 PostgreSQL，YCQL 则兼容 Cassandra 风格。TiDB 面向 MySQL 生态，CockroachDB 也更贴近 PostgreSQL 方言。

Q6. TiDB 集群中负责分片调度与全局时间戳分配的核心组件是？

单选题 · mid

  • A.TiKV
  • B.TiDB Server
  • C.PD← 正确答案
  • D.TiFlash

答案：C。PD（Placement Driver）负责维护元数据、分片调度、负载均衡和全局时间戳分配。TiKV 负责存储，TiDB Server 负责 SQL 层，TiFlash 负责列存分析。

Q7. 关于三款数据库的多区域高可用机制，正确的说法包括哪些？

多选题 · hard

  • A.都使用 Raft 在副本间复制日志← 正确答案
  • B.都支持把副本部署到不同机房或区域← 正确答案
  • C.都只能部署在单个可用区
  • D.多数派确认后才能提交写入← 正确答案

答案：ABD。三款数据库都用 Raft 复制日志，且支持跨机房、跨区域部署，提交时遵循多数派确认。C 说“只能部署单可用区”与云原生多区域方向完全相反。

Q8. 云原生分布式数据库的典型架构特征有哪些？

多选题 · easy

  • A.计算层无状态，可弹性伸缩← 正确答案
  • B.数据按分片分布并多副本← 正确答案
  • C.所有数据仅保存在单个节点
  • D.通过共识协议保证容灾← 正确答案

答案：ABD。云原生数据库强调计算与存储分离、分片扩展、多副本容灾，并通过共识协议保持一致性。C“单节点保存所有数据”是单体数据库的特征，不属于分布式架构。

Q9. 从技术选型角度看，以下判断正确的有哪些？

多选题 · hard

  • A.TiDB 便于 MySQL 存量业务平滑迁移← 正确答案
  • B.CockroachDB 对多区域强一致访问友好← 正确答案
  • C.YugabyteDB 完全不支持 PostgreSQL 特性
  • D.运维复杂度应计入选型评分权重← 正确答案

答案：ABD。TiDB 兼容 MySQL 协议，适合 MySQL 迁移；CockroachDB 的多区域路由和区域表适合跨地域强一致；运维复杂度会直接影响长期成本，应当计入评分。C 错误，YugabyteDB 的 YSQL 非常重视 PostgreSQL 兼容。

Q10. 一个已有 PostgreSQL 应用且需要高写入扩展的团队，最应该优先考察哪款数据库？

单选题 · extreme

  • A.优先选 TiDB 做平滑迁移
  • B.优先选 CockroachDB 做跨域强一致
  • C.优先选 YugabyteDB 做写入扩展← 正确答案
  • D.优先选 SQLite 做单机存储

答案：C。已有 PostgreSQL 应用意味着需要保留 PostgreSQL 兼容层，高写入扩展要求良好的分片写入能力，YugabyteDB 的 YSQL 兼容 PostgreSQL，并以 Tablet 分片支撑横向扩展。TiDB 更偏 MySQL，CockroachDB 强项不在“高写入扩展”这个诉求，SQLite 则完全不支持分布式。