历时两年半，开源分布式 NewSQL 数据库 TiDB 终于迎来了 1.0 正式版本的发布。作为全新的数据库类型的“探路者”，TiDB 在这过程中遇到了哪些技术难点？后续又将围绕哪些方面进行突破？本期，【开源访谈】邀请到了 PingCAP 联合创始人、CTO 黄东旭，为我们解读 TiDB 的探索之路及未来方向。
【访谈内容】
1、首先请老师介绍一下自己。
黄东旭，PingCAP 的联合创始人和 CTO，TiDB 的设计者和工程师，一直以来从事的基础软件和分布式系统的研发，很小就开始接触编程和开源，受到开源文化和自由软件运动的影响很深，是一个开源信徒，所以后来基本做东西能开源的尽量都会开源，比如早期的 Codis，现在的 TiDB。
2、TiDB 从零到 1.0 历时了两年半左右，遇到的难点主要有哪些，是如何解决的呢？
技术上主要的难点，比较具体的我记得是在早期决定不复用 MySQL 代码的同时还需要做到 MySQL 文法和网络协议上的兼容，同时还需要在很短时间内完成一个可用的查询优化器，虽然技术本身不是特别难，但是在早期确实是个工程上的挑战；另外底层存储上我们选用了 Rust 作为开发语言，作为一个比较新的语言，我们花了一些时间和精力帮助 Rust 社区完善一些第三方库，比如 gRPC 的 Rust 实现就是我们贡献和维护的。
其实遇到技术问题也谈不上有什么特别的解决方案，仔细分析和思考，拥抱和相信社区，重视测试，我们的工程师和在 TiDB 社区活跃的 Committer 的能力都很强，我相信大方向没问题，遇到的技术问题都是能解决的。
到现在，因为前方基本已经是无人区，思考得比较多的是未来数据库的形态和一些前沿的技术，比如如何更好利用新时代的硬件，如何和云更好的整合等等。
另一个方面是商业上的难点，我们几个创始人都是技术出身，过去并没有销售和市场的经验，在早期如何搭建商业和市场团队，如何面试这方面的人才，曾经让我们头疼很久，不过工程师嘛，多聊多总结，发挥学习新技术的精神去了解不同行业的东西，另外我们的投资人也帮了我们不少忙，总体来说，保持一个开放学习的心态，放低姿态多和行业里比较资深的人聊，能学到不少。
3、1.0 之后的 TiDB 将主要围绕哪些方面进行迭代更新？
技术上有几个重要的点：
1. 大集群上的多租户技术，这部分我们一个大的用户 Mobike 的工程师们为 TiDB 提交了这方面很多重要的特性的实现和很多宝贵的建议，在这里特别感谢一下。
2. 实时 OLAP 引擎，TiSpark 项目，TiDB 本身是一个 100% 的 OLTP 数据库，同时它的实时复杂分析能力也会越来越强，1.0 后一个重要的方向就是我们希望能够在 HTAP 上更进一步，打破数据库和数据仓库之间的界限。
3. 进一步减轻用户的迁移成本，我们内部在开发一些工具能够极大加速数据导入和同步线上 MySQL 的速度，降低用户的尝试和使用成本。
4. 拥抱新的硬件，这个时代，新的硬件层出不穷，Optane / NvmeSSD / 万兆网卡的普及，如何设计新的数据结构，使用新的 SDK，Bypass Kernel 使得更好的适应新的硬件。
最后一点，是持续增强稳定性，性能以及测试，这个是一个长期的工作，优化无止境嘛。
4、1.0 发布之后势必会吸引到更多用户使用，但也有许多用户迫切希望能有更多案例和背书，对此要如何解决？
其实这个是一个鸡生蛋蛋生鸡的问题，你需要得有第一批用户案例，才能吸引更多的用户，我们选在这个时间点发布 1.0 也是因为产品已经完成破冰，我们从 RC （Release Candidate）到 1.0 中间大约经过了一年，这一年时间我们已经默默的服务了很多种子用户，在他们的生产系统中锻炼，我们的早期客户中已经有系统稳定运行 TiDB 大规模集群超过一年了，在确保产品质量和有足够的用户背书的情况下，我们这才谨慎的发布了 1.0，我们随后也会持续的输出案例，给予社区更多的信心。
5、国外和国内的用户在特性方面的需求是否有差异，要怎么来协调？
其实特性需求上差异不大。在中国，大家会遇到 MySQL 的扩展性问题，在美国也会遇到。所以这两个市场对于我们这种基础软件公司来说，不会像 to C 的产品公司那样难以在海外复制，基础软件领域是没有国界限制的，目前我们也在布局海外市场。
6、同样在做 NewSQL 的 CockroachDB 在更早一点发布了 1.0 版本，能介绍一下二者的差异和相似之处吗？在进度相差不大的情况下，二者的业务是否有所冲突？
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 在行业内使用更广泛，目前涉及互联网、游戏、金融、政府、电信、制造业等多个领域。
7、从 SQL 到 NoSQL，再到 NewSQL，如何看待数据库的现状和未来发展方向？
个人认为从传统的单机 SQL 到 NoSQL 只是互联网公司在面对大并发量的新业务时的过度的状态，历史是螺旋上升的，现在 SQL 的回归是大势所趋，毕竟 SQL 是一个更好的操作数据的用户接口。
在可见的未来，数据量会是一直在膨胀，业务会越来越复杂。我个人觉得未来的数据库会有几个趋势，这也是 TiDB 项目追求的目标：
- 数据库会随着业务云化，未来一切的业务都会跑在云端，不管是私有云、公有云还是混合云，运维团队接触的可能再也不是真实的物理机，而是一个个隔离的容器或者「计算资源」。这对数据库也是一个挑战，因为数据库天生就是有状态的，数据总是要存储在物理的磁盘上，而移动数据的代价比移动容器的代价可能大很多。目前 TiDB 也与包括腾讯云、UCloud 在内的多家公有云平台完成了整合，提供公有云数据库服务。
- 多租户技术会成为标配，一个大数据库承载一切的业务，数据在底层打通，上层通过权限，容器等技术进行隔离；但是数据的打通和扩展会变得异常简单，结合第一点提到的云化，业务层可以再也不用关心物理机的容量和拓扑，只需要认为底层是一个无穷大的数据库平台即可，不用再担心单机容量和负载均衡等问题。
- OLAP 和 OLTP 会进一步细分，底层存储也许会共享一套，但是 SQL 优化器这层的实现一定是千差万别的。对于用户而言，如果能使用同一套标准的语法和规则来进行数据的读写和分析，会有更好的体验。
- 在未来分布式数据库系统上，主从日志同步这样落后的备份方式会被 Multi-Paxos / Raft 这样更强的分布式一致性算法替代，人工的数据库运维在管理大规模数据库集群时是不可能的，所有的故障恢复和高可用都会是高度自动化的。
- 最后就是我前面说过的要拥抱新的硬件，要跟上新硬件的迭代速度，配合设计新的数据结构来适应新的硬件。
2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务
