【开源访谈】黄东旭：“无人区”的探索者，TiDB 的前行之路

摘要：日前，我司联合创始人兼黄东旭接受了开源中国的开源访谈，公开解读了的探索之路及未来方向。应用场景上在行业内使用更广泛，目前涉及互联网游戏金融政府电信制造业等多个领域。目前也与包括腾讯云在内的多家公有云平台完成了整合，提供公有云数据库服务。

日前，我司联合创始人兼 CTO 黄东旭接受了开源中国的【开源访谈】，公开解读了 TiDB 的探索之路及未来方向。本文为专访实录~ :)

记者：王练

口述：黄东旭

黄东旭，PingCAP 的联合创始人和 CTO，TiDB 的设计者和工程师，一直以来从事的基础软件和分布式系统的研发，很小就开始接触编程和开源，受到开源文化和自由软件运动的影响很深，是一个开源信徒，所以后来基本做东西能开源的尽量都会开源，比如早期的 Codis，现在的 TiDB。

技术上主要的难点，比较具体的我记得是在早期决定不复用 MySQL 代码的同时还需要做到 MySQL 文法和网络协议上的兼容，同时还需要在很短时间内完成一个可用的查询优化器，虽然技术本身不是特别难，但是在早期确实是个工程上的挑战；另外底层存储上我们选用了 Rust 作为开发语言，作为一个比较新的语言，我们花了一些时间和精力帮助 Rust 社区完善一些第三方库，比如 gRPC 的 Rust 实现就是我们贡献和维护的。

其实遇到技术问题也谈不上有什么特别的解决方案，仔细分析和思考，拥抱和相信社区，重视测试，我们的工程师和在 TiDB 社区活跃的 Committer 的能力都很强，我相信大方向没问题，遇到的技术问题都是能解决的。

到现在，因为前方基本已经是无人区，思考得比较多的是未来数据库的形态和一些前沿的技术，比如如何更好利用新时代的硬件，如何和云更好的整合等等。

另一个方面是商业上的难点，我们几个创始人都是技术出身，过去并没有销售和市场的经验，在早期如何搭建商业和市场团队，如何面试这方面的人才，曾经让我们头疼很久，不过工程师嘛，多聊多总结，发挥学习新技术的精神去了解不同行业的东西，另外我们的投资人也帮了我们不少忙，总体来说，保持一个开放学习的心态，放低姿态多和行业里比较资深的人聊，能学到不少。

技术上有几个重要的点：

大集群上的多租户技术，这部分我们一个大的用户 Mobike 的工程师们为 TiDB 提交了这方面很多重要的特性的实现和很多宝贵的建议，在这里特别感谢一下。

实时 OLAP 引擎，TiSpark 项目，TiDB 本身是一个 100% 的 OLTP 数据库，同时它的实时复杂分析能力也会越来越强，1.0 后一个重要的方向就是我们希望能够在 HTAP 上更进一步，打破数据库和数据仓库之间的界限。

进一步减轻用户的迁移成本，我们内部在开发一些工具能够极大加速数据导入和同步线上 MySQL 的速度，降低用户的尝试和使用成本。

拥抱新的硬件，这个时代，新的硬件层出不穷，Optane / NvmeSSD / 万兆网卡的普及，如何设计新的数据结构，使用新的 SDK，Bypass Kernel 使得更好的适应新的硬件。

最后一点，是持续增强稳定性，性能以及测试，这个是一个长期的工作，优化无止境嘛。

其实这个是一个鸡生蛋蛋生鸡的问题，你需要得有第一批用户案例，才能吸引更多的用户，我们选在这个时间点发布 1.0 也是因为产品已经完成破冰，我们从 RC （Release Candidate）到 1.0 中间大约经过了一年，这一年时间我们已经默默的服务了很多种子用户，在他们的生产系统中锻炼，我们的早期客户中已经有系统稳定运行 TiDB 大规模集群超过一年了，在确保产品质量和有足够的用户背书的情况下，我们这才谨慎的发布了 1.0，我们随后也会持续的输出案例，给予社区更多的信心。

其实特性需求上差异不大。在中国，大家会遇到 MySQL 的扩展性问题，在美国也会遇到。所以这两个市场对于我们这种基础软件公司来说，不会像 to C 的产品公司那样难以在海外复制，基础软件领域是没有国界限制的，目前我们也在布局海外市场。

CockroachDB 也是一个很好的项目，在很多人看来，TiDB 和 CockroachDB 都是为了解决关系型数据库的可扩展性问题，并且二者都是受 Google Spanner/F1 的启发。 具体细节上，有以下几点不同：

二者兼容性不同，TiDB 是 100% MySQL 协议兼容，CockroachDB 兼容的是 PostgreSQL 。我们的用户可以直接使用 MySQL 的客户端来连接 TiDB ；

架构上的区别，TiDB 产品架构是分层的，由分布式 SQL 层（TiDB）和分布式 KV 存储引擎（TiKV）组成，而 CockroachDB 没有分层，所有的东西都在一个 binary 里面；

事务模型不同，虽然 TiDB 与 CockroachDB 都支持 ACID 事务，但是 TiDB 采用的是 Google Percolator 的模型，这个模型的关键特性是，它需要一个独立的 timestamp allocator，CockroachDB 所采用的是与 Google 相似的 TrueTime API，但是跟 Spanner 不一样的是，CockroachDB 并没有原子钟和 GPS 时钟来保证不同数据中心时间的一致性；

TiDB 是一个 HTAP 数据库，既具备 OLTP 的强大在线交易能力，也具备 OLAP 的在线分析能力。CockroachDB 暂时不具备 OLAP ；

二者开发语言不同，CockroachDB 用的 Go 语言，TiDB 整体项目用了两种语言，SQL 层（TiDB）用的是 Go，KV 层（TiKV）用的是 Rust。

应用场景上：TiDB 在行业内使用更广泛，目前涉及互联网、游戏、金融、政府、电信、制造业等多个领域。

个人认为从传统的单机 SQL 到 NoSQL 只是互联网公司在面对大并发量的新业务时的过度的状态，历史是螺旋上升的，现在 SQL 的回归是大势所趋，毕竟 SQL 是一个更好的操作数据的用户接口。

在可见的未来，数据量会是一直在膨胀，业务会越来越复杂。我个人觉得未来的数据库会有几个趋势，这也是 TiDB 项目追求的目标：

数据库会随着业务云化，未来一切的业务都会跑在云端，不管是私有云、公有云还是混合云，运维团队接触的可能再也不是真实的物理机，而是一个个隔离的容器或者「计算资源」。这对数据库也是一个挑战，因为数据库天生就是有状态的，数据总是要存储在物理的磁盘上，而移动数据的代价比移动容器的代价可能大很多。目前 TiDB 也与包括腾讯云、UCloud 在内的多家公有云平台完成了整合，提供公有云数据库服务。

多租户技术会成为标配，一个大数据库承载一切的业务，数据在底层打通，上层通过权限，容器等技术进行隔离；但是数据的打通和扩展会变得异常简单，结合第一点提到的云化，业务层可以再也不用关心物理机的容量和拓扑，只需要认为底层是一个无穷大的数据库平台即可，不用再担心单机容量和负载均衡等问题。

OLAP 和 OLTP 会进一步细分，底层存储也许会共享一套，但是 SQL 优化器这层的实现一定是千差万别的。对于用户而言，如果能使用同一套标准的语法和规则来进行数据的读写和分析，会有更好的体验。

在未来分布式数据库系统上，主从日志同步这样落后的备份方式会被 Multi-Paxos / Raft 这样更强的分布式一致性算法替代，人工的数据库运维在管理大规模数据库集群时是不可能的，所有的故障恢复和高可用都会是高度自动化的。

最后就是我前面说过的要拥抱新的硬件，要跟上新硬件的迭代速度，配合设计新的数据结构来适应新的硬件。