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 的副原来做物理断绝。

（编辑：湖南网）

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