PingCAP CTO黄东旭写给社区的回首和瞻望：TiDB 2019, Level Up !

2018 年对付 TiDB 和 PingCAP 来说是一个由少年向成年的转换的一年，假如用一个要害字来归纳综合就是「蜕变」。在这一年很欣喜的看到 TiDB 和 TiKV 在越来越多的用户行使在了越来越普及的场景中，作为一个方才 3 岁多的开源项目，没有背后强盛的社区的话，是没有步伐取得这样的盼望的。

同时在技能上，2018 年我认为也交出了一份令人满足的答卷，TiDB 的几个首要项目本年一共归并了 4380 个提交，这几天在清算 2018 年的 Change Log 时辰，比拟了一下年头的版本，这 4380 个 Commits 背儿女表了什么，这里简朴写一个文章总结一下。

追念起来，TiDB 是最早定位为 HTAP 的通用漫衍式数据库之一，假如认识我们的老伴侣必然知道，我们最早时辰一向都是定位 NewSQL，虽然此刻也是。可是 NewSQL 这个词有个题目，到底 New 在哪，办理了哪些题目，很难一览无余，着实一开始我们就想办理一个 MySQL 分库分表的题目，可是其后逐步跟着我们的用户越来越多，行使的场景也越来越清楚，许多用户的场景已经开始超出了一个「更大的 MySQL 」的行使范畴，于是我们从尝试室和学术界找到了我们认为越发清楚的界说：HTAP，但愿能构建一个融合 OLTP 和 OLAP 通用型漫衍式数据库。可是要告竣这个方针很是伟大，我们的判定是假如不是从最底层从头计划，很难到达我们的方针，我们以为这是一条更坚苦可是正确的路，此刻看来，这条路是走对了，并且将来会越走越快，越走越稳。

在 SQL 层这边，TiDB 选择了 MySQL 的协议兼容，一方面一连的增强语法兼容性，另一方面选择自研优化器和执行器，带来的甜头就是没有任何汗青承担一连优化。回首本年最大的一个事变应该是重构了执行器框架，TiDB的 SQL 层照旧经典的 Volcano 模子，我们引入了新的内存数据布局 Chunk 来批量处理赏罚多行数据，并对各个算子都实现了基于 Chunk 的迭代器接口，这个改造对付 OLAP 哀求的改造很是明明，在 TiDB 的 TPC-H 测试集上能看出来(https://github.com/pingcap/docs-cn/blob/master/benchmark/tpch.md)，Chunk 的引入为我们全面的向量化执行和 CodeGen 支持打下了基本。今朝在 TiKV 内部对付下推算子的执行还没有行使 Chunk 改革，不外这个已经在打算中，在 TiKV 中这个改造，预期对查询机能的晋升也将很是明显。

另一方面，一个数据库查询引擎最焦点的组件之一：优化器，在本年也有长足的前进。我们在 2017 年就已经全面引入了基于价钱的 SQL 优化(CBO，Cost-Based Optimization)，我们在本年改造了我们的价钱评估模子，插手了一些新的优化法则，同时实现了 Join Re-Order 等一系列优化，从功效上来看，今朝在 TPC-H 的测试集上，对付全部 Query，TiDB 的 SQL 优化器大多已给出了最优的执行打算。CBO 的另一个要害模块是统计信息网络，在本年，我们引入了自动的统计信息网络算法，使优化器的顺应性更强。其它针对 OLTP 的场景 TiDB 如故保存了轻量的 RBO 乃至直接 Bypass 优化器，以晋升 OLTP 机能。其它，感激三星韩国研究院的几位工程师的孝顺，他们给 TiDB 引入了 Query Plan Cache，对高并发场景下查询机能的晋升也很明明。其它在成果上，我们引入了 Partition Table 的支持，对付一些 Partition 特征很明明的营业，TiDB 可以或许越发高效的调治数据的写入读取和更新。

一向以来，TiDB 的 SQL 层作为纯 Go 说话实现的最完整的 MySQL 语法兼容层，许多第三方的 MySQL 器材在行使着 TiDB 的 SQL Parser，个中的优越代表好比小米的 Soar(https://github.com/XiaoMi/soar)。为了利便第三方更好的复用 TiDB Parser，我们在 2018 年将 Parser 从主项目中剥离了出来，成为了一个独立的项目：pingcap/parser，但愿能帮到更多的人。

说到 TiDB 的底层存储 TiKV 本年也有许多让人面前一亮的更新。在 TiKV 的基石——同等性算法 Raft 这边，各人知道 TiKV 回收的是 Multi-Raft 的架构，内部通过无数个 Raft Group 动态的破碎、归并、移动以到达动态伸缩和动态负载平衡。我们在本年如故一连在扩展 Multi-Raft 的界线，我们本年插手了动态的 Raft Group 归并，以减轻元信息存储和心跳通讯的承担;给 Raft 扩展了 Learner 脚色(只同步 Log 不投票的脚色) 为 OLAP Read 打下基本;给 Raft 的基本算法插手了 Pre-Vote 的阶段，让整个体系在非常收集状态下靠得住性更高。

Raft Group Merge

在机能方面，我们花了很大的精神重构了我们单机上多 Raft Group 的线程模子(https://github.com/tikv/tikv/pull/3568)， 固然还没有归并到 master 分支，在我们测试中，这个优化带来了两倍以上的吞吐晋升，同时写入耽误低落至此刻的版本的 1/2 ，估量在这两周我们会完成这个庞大的 PR 的 Code Review，列位同窗可以等候一下 :)

第三件工作是我们开始将 TiKV 的当地存储引擎的接口彻底抽象出来，方针是能做到对 RocksDB 的弱耦合，这点的意义很大，不管是社区照旧我们本身，对新的单机存储引擎支持将变得越发利便。

在 TiKV 社区这边，本年的其它一件大事是插手了 CNCF，酿成了 CNCF 的托管项目，也是 CNCF 基金会第一个非布局化数据库项目。 其后许多伴侣问我，为什么捐赠的是 TiKV 而不是 TiDB，着实首要的缘故起因就像我在当天的一条 Tweet 说的，TiKV 更像是的一个越发通用的组件，当你有一个可以弹性伸缩的，支持跨行 ACID 事宜的 Key-Value 数据库时，你会发明构建其他许多靠得住的漫衍式体系会轻易许多，这在我们之后的 TiDB Hackathon 中获得了很好的浮现。其它社区已经开始呈现基于 TiKV 构建的 Redis 协议支持，以及漫衍式行列体系，譬喻meitu/titan 项目。作为一个基金会项目，社区不只仅可以直接行使，更可以或许将它作为构建其他体系的基石，我认为越发故意义。相同的，本年我们将我们的 Raft 实现从主项目中独立了出来(pingcap/raft-rs)，也是但愿更多的人能从中受益。

（编辑：湖南网）

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