PingCAP CTO 黄东旭：我眼中的未来数据库技术趋势

上面图 11 左半部分是 Hyper，它是慕尼黑工业大学的一个实验性数据库项目，它做了一些分析，第一个柱形是正常的 SQL 语句的执行时间，比如说直接把一语句放到另外一个库里去执行，耗时这么多。第二个柱形是用逻辑日志去存放，耗时大概能快 23%，第三个柱形能看到如果是存放物理日志能快 56%。所以大家仔细想想，TiDB 的架构里的 TiFlash 其实同步的是 Raft 日志，而并不是同步 Binlog 或者其他的。

上面图 11 右半部分是 Aurora，它的架构就不用说了，同步的都是 redo log 。其实他的好处也很明显，也比较直白，就是 I/O 更小，网络传输的 size 也更小，所以就更快。

然后在这一块 TiDB 跟传统的数据库有点不一样的就是，其实如果很多同学对 TiDB 的基础架构不太理解的话就觉得， Raft 不是一个一定要有 Index 或者说是一定强顺序的一个算法吗?那为什么能做到这样的乱序的提交?其实 TiDB 并不是单 Raft 的架构，而是一个多 Raft 的架构，I/O 可以发生在任何一个 Raft Group 上。传统的单机型数据库，就算你用更好的硬件都不可能达到一个线性扩展，因为无论怎么去做，都是这么一个架构不可改变。比如说我单机上 Snapshot 加 WAL，不管怎么写， 总是在 WAL 后面加，I/O 总是发生在这。但 TiDB 的 I/O 是分散在多个 Raft Group、多个机器上，这是一个很本质的变化，这就是为什么在一些场景下，TiDB 能够获取更好的吞吐。

2. Vectorized

第二个大趋势是全面的向量化。向量化是什么意思?我举个简单的例子。比如我要去算一个聚合，从一个表里面去求某一列的总量数据，如果我是一个行存的数据库，我只能把这条记录的 C 取出来，然后到下一条记录，再取再取再取，整个 Runtime 的开销也好，还有去扫描、读放大的每一行也好，都是很有问题的。但是如果在内存里面已经是一个列式存储，是很紧凑的结构的话，那会是非常快的。

图 12 TiDB 向量化面临的挑战

这里面其实也有一些挑战。我们花了大概差不多 2018 年一年的时间去做向量化的改造，其实还挺难的。为什么?首先 TiDB SQL 引擎是用了 Volcano 模型，这个模型很简单，就是遍历一棵物理计划的树，不停的调 Next，每一次 Next 都是调用他的子节点的 Next，然后再返回结果。这个模型有几个问题：第一是每一次都是拿一行，导致 CPU 的 L1、L2 这样的缓存利用率很差，就是说没有办法利用多 CPU 的 Cache。第二，在真正实现的时候，它内部的架构是一个多级的虚函数调用。大家知道虚函数调用在 Runtime 本身的开销是很大的，在《MonetDB/X100: Hyper-Pipelining Query Execution》(http://cidrdb.org/cidr2005/papers/P19.pdf)里面提到，在跑 TPC-H 的时候，Volcano 模型在 MySQL 上跑，大概有 90% 的时间是花在 MySQL 本身的 Runtime 上，而不是真正的数据扫描。所以这就是 Volcano 模型一个比较大的问题。第三，如果使用一个纯静态的列存的数据结构，大家知道列存特别大问题就是它的更新是比较麻烦的， 至少过去在 TiFlash 之前，没有一个列存数据库能够支持做增删改查。那在这种情况下，怎么保证数据的新鲜?这些都是问题。

图 13 TiDB SQL 引擎向量化

TiDB 已经迈出了第一步，我们已经把 TiDB SQL 引擎的 Volcano 模型，从一行一行变成了一个 Chunk 一个 Chunk，每个 Chunk 里面是一个批量的数据，所以聚合的效率会更高。而且在 TiDB 这边做向量化之外，我们还会把这些算子推到 TiKV 来做，然后在 TiKV 也会变成一个全向量化的执行器的框架。

3. Workload Isolation

另外一个比较大的话题，是 Workload Isolation。今天我们在演示的各种东西都有一个中心思想，就是怎么样尽可能地把 OLTP 跟 OLAP 隔离开。这个问题在业界也有不同的声音，包括我们的老前辈 Google Spanner，他们其实是想做一个新的数据结构，来替代 Bigtable-Like SSTable 数据结构，这个数据结构叫 Ressi，大家去看 2018 年 《Spanner: Becoming a SQL System》这篇 Paper 就能看到。它其实表面上看还是行存，但内部也是一个 Chunk 变成列存这样的一个结构。但我们觉得即使是换一个新的数据结构，也没有办法很好做隔离，因为毕竟还是在一台机器上，在同一个物理资源上。最彻底的隔离是物理隔离。

图 14 TiFlash 架构

我们在 TiFlash 用了好几种技术来去保证数据是更新的。一是增加了 Raft Leaner，二是我们把 TiDB 的 MVCC 也实现在了 TiFlash 的内部。第三在 TiFlash 这边接触了更新(的过程)，在 TiFlash 内部还有一个小的 Memstore，来处理更新的热数据结果，最后查询的时候，是列存跟内存里的行存去 merge 并得到最终的结果。TiFlash 的核心思想就是通过 Raft 的副本来做物理隔离。

（编辑：济南站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!