全球部署的分布式数据库 YugabyteDB，了解一下？

做者：Eric Fu\
连接：https://ericfu.me/yugabyte-db...

Yugabyte DB 是一个全球部署的分布式数据库，和国内的 TiDB 和国外的 CockroachDB 相似，也是受到 Spanner 论文启发，因此在不少地方这几个数据库存在很多类似之处。

与 Cockroach 相似，Yugabyte 也主打全球分布式的事务数据库——不只能把节点部署到全球各地，还能完整支持 ACID 事务，这是他最大的卖点。除此之外还有一些独特的特性，好比支持文档数据库接口。若是我猜的没错，Yugabyte 早期被设计成一个文档数据库，后来才调整技术路线开始主打 SQL 接口。

本文信息主要来自于 Yugabyte 的官方文档：

https://docs.yugabyte.com/

以及其 GitHub 主页：

https://github.com/yugabyte/y...

系统架构

逻辑上，Yugabyte 采用两层架构：查询层和存储层。不过这个架构仅仅是逻辑上的，部署结构中，这两层都位于 TServer 进程中。这一点和 TiDB 不一样。

Yugabyte 的查询层支持同时 SQL 和 CQL 两种 API，其中 CQL 是兼容 Cassandra 的一种方言语法，对应于文档数据库的存储模型；而 SQL API 是直接基于 PostgresQL 魔改的，能比较好地兼容 PG 语法，据官方说这样能够更方便地跟随 PG 新特性，有没有官方说的这么美好咱们就不得而知了。

Yugabyte 的存储层才是重头戏。其中 TServer 负责存储 tablet，每一个 tablet 对应一个 Raft Group，分布在三个不一样的节点上，以此保证高可用性。Master 负责元数据管理，除了 tablet 的位置信息，还包括表结构等信息。Master 自己也依靠 Raft 实现高可用。

基于 Tablet 的分布式存储

这一部分是 HBase/Spanner 精髓部分，Cockroach/TiDB 的作法几乎也是如出一辙的。以下图所示，每张表被分红不少个 tablet，tablet 是数据分布的最小单元，经过在节点间搬运 tablet 以及 tablet 的分裂与合并，就能够实现几乎无上限的 scale out。每一个 tablet 有多个副本，造成一个 Raft Group，经过 Raft 协议保证数据的高可用和持久性，Group Leader 负责处理全部的写入负载，其余 Follower 做为备份。

下图是一个例子：一张表被分红 16 个 tablet，tablet 的副本和 Raft Group leader 均匀分布在各个节点上，分别保证了数据的均衡和负载的均衡。

和其余产品同样，Master 节点会负责协调 tablet 的搬运、分裂等操做，保证集群的负载均衡。这些操做是直接基于 Raft Group 实现的。这里就再也不展开了。

有趣的是，Yugabyte 采用哈希和范围结合的分区方式：能够只有哈希分区、也能够只有范围分区、也能够先按哈希再按范围分区。之因此这么设计，猜想也是由于 Cassandra 的影响。相比之下，TiDB 和 Cockroach 都只支持范围分区。

哈希分区的方式是将 key 哈希映射到 2 字节的空间中（即 0x0000 到 0xFFFF），这个空间又被划分红多个范围，好比下图的例子中被划分为 16 个范围，每一个范围的 key 落在一个 tablet 中。理论上说最多可能有 64K 个 tablet，这对实际使用足够了。

哈希分区的好处是插入数据（尤为是从尾部 append 数据）时不会出现热点；坏处是对于小范围的范围扫描（例如 pk BETWEEN 1 AND 10）性能会比较吃亏。

基于 RocksDB 的本地存储

每一个 TServer 节点上的本地存储称为 DocDB。和 TiDB/Cockroach 同样，Yugabyte 也用 RocksDB 来作本地存储。这一层须要将关系型 tuple 以及文档编码为 key-value 保存到 RocksDB 中，下图是对文档数据的编码方式，其中有很多是为了兼容 Cassandra 设计的，咱们忽略这些，主要关注如下几个部分：

• key 中包含

  • 16-bit hash：依靠这个值才能作到哈希分区
  • 主键数据（对应图中 hash/range columns）
  • column ID：由于每一个 tuple 有多个列，每一个列在这里须要用一个 key-value 来表示
  • hybrid timestamp：用于 MVCC 的时间戳

• value 中包含

  • column 的值

若是撇开文档模型，key-value 的设计很像 Cockroach：每一个 cell （一行中的一列数据）对应一个 key-value。而 TiDB 是每一个 tuple 打包成一个 key-value。我的比较偏好 TiDB 的作法。

分布式事务：2PC & MVCC

和 TiDB/Cockroach 同样，Yugabyte 也采用了 MVCC 结合 2PC 的事务实现。

时间戳

时间戳是分布式事务的关键选型之一。Yugabyte 和 Cockroach 同样选择的是 Hybrid Logical Clock (HLC)。

HLC 将时间戳分红物理（高位）和逻辑（低位）两部分，物理部分对应 UNIX 时间戳，逻辑部分对应 Lamport 时钟。在同一毫秒之内，物理时钟不变，而逻辑时钟就和 Lamport 时钟同样处理——每当发生信息交换（RPC）就须要更新时间戳，从而确保操做与操做之间可以造成一个偏序关系；当下一个毫秒到来时，逻辑时钟部分归零。

不难看出，HLC 的正确性实际上是由 Logical Clock 来保证的：它相比 Logical Clock 只是在每一个毫秒引入了一个额外的增量，显然这不会破坏 Logical Clock 的正确性。可是，物理部分的存在将本来无心义的时间戳赋予了物理意义，提升了实用性。

我的认为，HLC 是除了 TrueTime 之外最好的时间戳实现了，惟一的缺点是不能提供真正意义上的外部一致性，仅仅能保证相关事务之间的“外部一致性”。另外一种方案是引入中心授时节点（TSO），也就是 TiDB 使用的方案。TSO 方案要求全部事务必须从 TSO 获取时间戳，实现相对简单，但引入了更多的网络 RPC，并且 TSO 过于关键——短期的不可用也是极为危险的。

HLC 的实现中有一些很 tricky 的地方，好比文档中提到的 Safe timestamp assignment for a read request。对于同一事务中的屡次 read，问题还要更复杂，有兴趣的读者能够看 Cockroach 团队的这篇博客 Living Without Atomic Clocks：

https://www.cockroachlabs.com...

事务提交

绝不惊奇，Yugabyte 的分布式事务一样是基于 2PC 的。他的作法接近 Cockroach。事务提交过程当中，他会在 DocDB 存储里面写入一些临时的记录（provisional records），包括如下三种类型：

• Primary provisional records：还未提交完成的数据，多了一个事务ID，也扮演锁的角色
• Transaction metadata：事务状态所在的 tablet ID。由于事务状态表很特殊，不是按照 hash key 分片的，因此须要在这里记录一下它的位置。
• Reverse Index：全部本事务中的 primary provisional records，便于恢复使用

事务的状态信息保存在另外一个 tablet 上，包括三种可能的状态：Pending、Committed 或 Aborted。事务从 Pending 状态开始，终结于 Committed 或 Aborted。

事务状态就是 Commit Point 的那个“开关”，当事务状态切换到 Commited 的一瞬间，就意味着事务的成功提交。这是保证整个事务原子性的关键。

完整的提交流程以下图所示：

另外，Yugabyte 文档中提到它除了 Snapshot Isolation 还支持 Serializable 隔离级别，可是彷佛没有看到他是如何规避 Write Skew 问题的。从 Release Notes 看来这应该是 2.0 GA 中新增长的功能，等更多信息放出后再研究吧！

竞品对比

如下表格摘自 Compare YugabyteDB to other databases：

https://docs.yugabyte.com/lat...

References

1. https://www.yugabyte.com/
2. https://docs.yugabyte.com/
3. https://www.cockroachlabs.com...

近期热文推荐：

1.600+ 道 Java面试题及答案整理(2021最新版)

2.终于靠开源项目弄到 IntelliJ IDEA 激活码了，真香！

3.阿里 Mock 工具正式开源，干掉市面上全部 Mock 工具！

4.Spring Cloud 2020.0.0 正式发布，全新颠覆性版本！

5.《Java开发手册（嵩山版）》最新发布，速速下载！

以为不错，别忘了随手点赞+转发哦！