读 TiDB 论文有感 | 数据强一致性且资源隔离的 HTAP 数据库

前文中，我们谈到 OLTP 和 OLAP 是两种差异非常大的工作负载，通常要两者兼得的方案分为：

1. 设计一套同时适合 OLTP 和 OLAP 工作负载的存储引擎，在这一个存储引擎来处理所有的数据请求，这样数据的实时性和一致性的问题很好解决，但是 OLTP 和 OLAP 工作负载相互不影响是一个很难解决的问题，并且一套存储引擎要同时适合 OLTP 和 OLAP 工作负载，在存储引擎的设计与优化上的限制是比较多的，感觉这是在设计一种五彩斑斓的黑。

2. 在数据库内部同时存在两套存储引擎，分布负责 OLTP 和 OLAP 工作负载，这可以很好避免上面的问题，但是数据需要从两套存储引擎中复制，这样会导致同时满足数据强一致性和资源相互隔离是一个很难解决的问题。

论文中，TiDB 选择的是方案 2，针对 OLTP 工作负载提供一个行存引擎 TiKV，针对 OLAP 工作负载负载提供一个列存引擎 TiFlash，那么数据强一致性和资源相互隔离怎么解决呢？

一般来说，对于一个分布式存储系统，数据强一致性和资源相互隔离经常是一个二选一的选择题，选择数据强一致性，一般是通过同步复制的方式（比如同步双写等）将数据复制到多个相关的实例上，那么将导致所有的计算与存储资源都会紧耦合在一个系统中，一个局部的小问题可能会导致其他的部分受到影响，牵一发而动全身；而选择资源相互隔离，一般是通过异步复制的方式（比如主从同步等）将数据复制到其他的相关实例上来实现的，这样可以确保资源的相互隔离，但是数据强一致性得不到保证。

TiKV 将每一段连续的数据称为一个 Region（默认 96 M），每一个 Region 是一个 Raft Group，通过 Raft 协议从 Leader 节点向 Follower 节点复制数据，这是一个同步复制的过程（超过半数节点复制完成就算成功复制），如果 TiFlash 也采用 Follower 的方式来同步数据，那么 TiKV 和 TiFlash 之间的数据复制可以简单理解为同步复制（其实严格来说算是介于同步和异步之间的复制，因为如果 TiFlash 的 Follower 同步慢或者挂掉后，相当于增加了一个复制失败的节点，这样就降低了多数派节点复制成功的概率，也就降低了 TiKV 的可用性）的，这样两个存储引擎之间就会相互影响，无法达到资源隔离的目标。

因此，TiDB 扩展了 Raft 算法，增加 Learner 角色。Learner 角色只异步接收 Raft Group 的 Raft 日志，它不参与 Raft 协议来提交日志或选举领导人，这样，在数据的复制过程中，TiFlash 的 Learner 节点对 TiKV 的性能开销非常小。TiFlash 通过 Learner 角色接受到数据后，将行格式元组转换为列式数据存储，达到了数据在 TiDB 集群中同时行存储和列存储的目的。

到这里，大家可能会发现一个问题，TiFlash 的 Learner 角色是异步接受 Raft Group 的 Raft Log，那么怎么保证 TiFlash 的数据强一致性呢？

这个问题是在 TiFlash 读数据的时候来解决的。类似 Raft 的 Follower Read 的机制，Learner 节点提供快照隔离级别，我们可以通过特定时间戳从 TiFlash 读取数据。在接收到读取请求后，Learner 向其 Leader 发送一个 readindex 请求，Learner 根据收到的 readindex 阻塞等待相应的 Raft Log 同步成功并且回放到本地存储后，再根据请求的时间戳过滤出满足要求的数据。

这样，TiDB 就将同步的数据复制机制转变成异步的数据复制机制了，并且保证了数据的强一致性。在 TiFlash 读数据的时候，TiFlash 的 Learner 只需要和 TiKV Leader 节点做一次 readindex 操作，这是一个非常轻量的操作，所以 TiKV 和 TiFlash 之间的影响会非常小。论文中实验的数据也验证了这一点，TiDB 中，同时进行 AP 和 TP 操作，AP 操作对 TP 吞吐量的影响最多不到 10%，TP 操作对 AP 吞吐量的影响最多不到 5%。

到这里，TiDB 有了两个存储引擎：对 OLTP 友好的行存 TiKV，对 OLAP 友好的列存 TiFlash，其实这个不关键，关键的是这个两个存储引擎的数据同步是强一致性的，能对外提供一致的快照隔离级别，这对于计算层的查询优化器来说是一个非常大的优势，对于一个请求，查询优化器可以有三种扫描方式选择：TiKV 的行扫描和索引扫描，TiFlash 的列扫描，并且对于同一个请求，可以针对不同的部分采用不同的扫描方式，这为查询优化器提供了巨大的优化空间。从论文的实验数据也表明，同时使用 TiKV 和 TiFlash 的 AP 请求比单独只使用任何一个都是更优。

我们再回到文章的开头，当初由于数据库由于需要好处理 OLTP 和 OLAP 工作负载，将数据库按工作负载分为 OLTP 和 OLAP 类型数据库，然后让使用者再将请求分类成 OLTP 和 OLAP 类型请求相应类型的数据库，在这里却是另一种解决方式：对于使用者来说只有一个数据库，数据库通过对请求进行分析后决定用哪一个或者同时使用两个存储引擎，将数据库和查询按工作负载进行分类的方式消除，这个一个更高层次的抽象。

目前的分布式存储系统，国外出现了很多完全的去中心化架构设计，比如 Cassandra 和 CockroachDB，但是 TiDB 的架构设计不是完全去中心化的，它有一个中心大脑角色 PD，正好和东西方的意识形态对应上了，小政府与大政府的方案，这也是一个比较有意思的地方。

Vitalik Buterin 指出选择完全去中心化设计的主要原因：fault tolerance、attack resistance、collusion resistance。由于数据库都是部署在内部可信赖的网络，所以 attack resistance、collusion resistance 都不会是问题，这和比特币等数字货币为了确保不能被某一些人或者组织控制，出于社会和政治方面的原因采用去中心化架构是不一样的，并且 fault tolerance 在中心化的架构也是可以解决的。

另外，更重要的是对于 TiDB 等 NewSQL 或者 HTAP 数据库本身就是为海量数据设计的，数据库集群管理的节点和数据量会越来越大，特别是与云原始的弹性能力结合后，数据库的智能调度能力将是决定数据库性能和稳定性的关键因素，但是去中心化的架构会让调度决策变得困难，特别是需要全局视角和多节点协同的调度决策会更加困难。

从 TiDB 的内部来看，我们可以看到 TiDB 是彻底的存储计算分离架构，目前计算层有两个引擎：SQL Engine 和 TiSpark，存储层也有两个引擎：TiKV 和 TiFlash，未来，不论是计算层还是存储层都能很方便的扩展到新的生态中，所以 TiDB 的目标感觉不仅仅只是一个数据库，同时也是在打造一个分布式存储的生态。

从单集群 TiDB 的角度来看，数据强一致性但资源相互隔离的 HTAP 是一个非常高效的能力，省去了数据从 OLTP 数据库同步到 OLAP 数据库的过程，也省去了将 OLAP 数据库计算结果需要提供在线业务使用时，再将数据同步到 OLTP 数据库的过程，这样，工程师都开开心心的搬砖和写 SQL，而不是频繁的搬数据。比起搬砖来说，搬数据像运水，更容易出现洒水、渗水等问题。

最后，我们聊聊这篇论文的价值，一般来说工程论文的价值和学术论文是不一样的，工程论文的贡献，很多时候不是思想、理论等方面有特别大的创新，而是告诉大家，这个方向是可以行的，通过确定性的工程实现来减少了很多不确定的探索。比如 Google 的 GFS、MapReduce、Bigtable 相关的论文，在学术上创新是不大的，几乎所有的思想和理论都是已经存在的，但是它告诉大家，将其分布式实现是可行的，这个意义就非常大了，极大地推进了分布式存储系统的普及与发展。

如果还想了解更多关于 TiDB 论文的内容，欢迎大家关注本周 Infra Meetup 直播间！本周六，我司联合创始人兼 CTO 黄东旭将为我们解读 VLDB 2020 HTAP Session 的三篇精彩论文，和大家深入聊一聊 HTAP 话题，现场更有神秘彩蛋环节。更多活动信息请详见《当我们在谈论 HTAP 时我们在谈论什么——VLDB 2020 HTAP 论文解读》。

扫描下方二维码进入直播交流群，小助手届时会在群内分享直播链接及现场资料哦！

关注公众号：拾黑（shiheibook）了解更多

[广告]赞助链接：

四季很好，只要有你，文娱排行榜：https://www.yaopaiming.com/
让资讯触达的更精准有趣：https://www.0xu.cn/