刘奇：我们最喜欢听用户说的话是「你们搞得定吗？」 | TiDB DevCon 2019

摘要：申砾老师的演讲实录正在整理中，后续会分享给大家同时在里面，我们还做了大量的改进。

1 月 19 日 TiDB DevCon 2019 在北京圆满落幕，超过 750 位热情的社区伙伴参加了此次大会。会上我们首次全面展示了全新存储引擎 Titan、新生态工具 TiFlash 以及 TiDB 在云上的进展，同时宣布 TiDB-Lightning Toolset & TiDB-DM 两大生态工具开源，并分享了  TiDB 3.0 的特性与未来规划，描述了我们眼中未来数据库的模样。
此外，更有 11 位来自一线的 TiDB 用户为大家分享了实践经验与踩过的「坑」，获得了现场观众的阵阵掌声。同时，我们也为新晋 TiDB Committer 授予了证书，并为 2018 年最佳社区贡献个人、最佳社区贡献团队颁发了荣誉奖杯。
错过现场的小伙伴不要太「伤心」，我们将挑选部分精彩实录分享给大家，敬请期待哦～

以下为我司 CEO 刘奇在 TiDB DevCon 2019 上的 Opening Keynote 实录。

首先我想特别感谢每一位来参加 TiDB DevCon 2019 的 Contributor 和用户，还有对 TiDB 保持好奇的人。今天我主要想跟大家分享一下我们过去一年的一些发展情况，以及我们对于未来的一些想法。

从图 1 大家可以很清楚的看到 TiDB 在过去一年的增长。如果大家去对比一下 TiDB 增长曲线和其他同类产品、或者是上一代 NoSQL 产品的增长曲线会发现，TiDB 是遥遥领先的。看完我们的 Contributor 增长和我们在 GitHub 上面的各种状态，在这里也特别感谢我们所有的那些正在使用 TiDB 的用户。

图 2 是过去一年，我们用户自己去分享自己使用 TiDB 的一些经验。我记得我们在筹办这个会的时候，我说我有特别多想讲的东西，掏心窝子的话特别多，能不能让我多讲讲。我们市场的同学不太同意，说我们只有一天时间，我们应该把更多的时间交给我们用户，让他们来分享他们自己的经验，交给在一线的同学。大家如果特别有兴趣的话，可以去翻一翻我们用户使用 TiDB 的一些经验（https://pingcap.com/cases-cn/），里面有一些他们的踩坑经验，也有一些他们比较欣慰的点，还有一些用户吐槽的东西，所以我们在 2018 年年底的时候，搞了一次吐槽大会，请几个用户过去疯狂吐槽一下我们的产品。我们定了几个原则，比如，只允许说缺点，不允许说优点。

这是海外的一些媒体对我们的报道（图 3），大家可能也知道，我们去年拿了 InfoWorld 评选的 Bossie Awards 最佳开源软件奖，接下来的分享 Morgan 会介绍我们在海外的一些发展情况和我们的海外团队。

在过去一年，我们最喜欢听用户讲的一句话是什么？我们最喜欢听的一句话是：你们搞得定吗？我觉得这句话太好了，很多时候，我们突然会去跟用户去讲，你这是 OLAP，你这是 OLTP。其实用户关心的是，你能不能搞定我的问题，而不是说你过来派了一堆专家，告诉我该怎么干。

在过去一年里，用户在用 TiDB 的过程中，也会遇到很多的问题。比如说，OLTP 和 OLAP 的隔离怎么去做。所以我们在今年启用了一个全新的 Design，在这个 Design 里面是彻底地隔离 OLAP 和 OLTP 的 Workload。

我们曾经见到很多争论，也见到很多论文，说到底是行存好，还是列存好。如果大家去看知乎的话，这个讨论现在还没有休止：到底数据库是应该使用行存还是使用列存。而在我们现在的 Design 里面，我们会搁置这个争议——为什么我们不能都有？

大家想一想，在多少年前，我们家里面还有固定电话，我们还在看纸质书，我们听歌用 MP3，我们可能想看一下自己今天跑了多少步，还得用一个专门的硬件或者运动设备。但是到今天，一部手机就搞定这一切。

在之前，我们可能线上需要用 MySQL，或者用 PG，中间我们可能需要用消息队列，去把 binlog 或者 change feeds 都给弄出来，然后再弄到一个 Data ware house 里面，在 Data ware house 里面去 Run。最终我们丧失了实时性，我们丧失了一致性。但是如果我们重新去想一下这个事情，这事儿就像当初的手机和 MP3、纸质书一样的。到今天技术进步到一定程度的时候，为什么我不能 OLTP/OLAP All in one ，我只是一个普通的用户，我不想接受那么一堆东西，同时我要实时性，我现在要的，马上就要。

当然大的氛围下面，吹牛的很多，但如果我不知道他是怎么 Work 的，通常我是不太放心的，所以我们用一个简单的图（图 5）说一下，到底 OLAP 和 OLTP 的 Workload 是怎么隔离的。 在我们全新的 Design 里面，TiDB 的 engine——TiKV ，但是我们通过 Raft 协议，通过 learner 把数据复制出来一份，这份协议是实时通过 Raft 做复制，但是用列式来存储。如果我们的优化器变得更加聪明，当一个查询过来的时候，它不用再去纠结，而是会根据这个 Query 的特点、自动根据这个 SQL 去选择到底是使用行存，还是使用列存，还是一部分使用行存，一部分使用列存，这样就会带来很多额外的好处。在这个图上（图 5）可以看到，Workload 是整个物理上是隔离的，是完全跑在不同的 Server 上面的。

这样带来的好处就非常明显。我们就能够同时去 Join 两个不同格式的数据，同时能得到所有的 OLAP 和 OLTP 的系统的好处，能得到一个更神奇的结果，就是它可以比 OLTP 系统跑的快；你可以在一个 OLTP 的系统，在传统上面不可想象的、在下面去跑一个报表。所以今天我们也非常高兴的去向大家推出我们新的 Design 和对应的产品，这个产品叫 TiFlash。看过美剧 The Flash 的同学知道闪电侠，这个名称是为了形容它的速度，因为它又是 TiDB 的 Ti 系列家族中的一员，所以我们给他取名叫 TiFlash，下午会有一个非常非常 Amazing 的环节会去展示整个 TiFlash。大家可以保持期待，这个一定不会让大家失望。我昨天看了一下演示，非常震撼。

有关注我们微信公众号的同学会发现，在今天早上（1 月 19 日）我们发布了 3.0 Bata 版本，在 3.0 里面，我们发布了大量的新特性，比如去年在 DevCon 上面，我承诺给大家的，我们会支持 Window Fuction、支持 View、支持 Partition，这些东西现在统统都有了。同时我们还有一些新的东西是之前没有的，比如说 Plan binding，就是绑定执行计划，这里也是特别感谢美团同学的 Contribution，让我们能够支持到新的特性。这些特性，稍后申砾老师会给大家分享详细的细节，这边我就先跳过。（申砾老师的演讲实录正在整理中，后续会分享给大家～）

同时在 3.0 里面，我们还做了大量的改进。

大家知道，过去一年有那么多 TiDB 用户，其实他们也有头疼的地方。就是 TiDB 的执行计划跟 TiDB 的统计信息是高度相关的，有时候会遇到执行计划产生变化。所以 2019 年的 Q1，我们将会花大量的时间，去让这个执行计划变的更加稳定。 同时为了便于大家去查看这些慢查询，我们做了一个非常漂亮的 Query Tracing 的界面，上午申砾的分享也会去介绍这个非常漂亮的界面，让大家看到，一个复杂的 Query 下去，最终在每一步耗了多长时间，还有个非常漂亮的树形图。

然后我们也解决了过去一年，我们 Raft Store 是一个单线程的问题。我觉得这个需要消耗大量的时间和精力。我记得我们当初做 Region split 的时候好像没花多久，分裂可能做一个月，然后 merge 做了一年，多线程这个也差不多做了一年。

前一阵大家可能也知道业内出现过删库跑路的事情。当时我们也非常震惊，我就想从我们的层面上能做哪些事情？所以，我们在 3.0 里面提供了一个新的功能，叫 Admin restore table，如果你一不小心把一个数据库，或者把一个 table 给删了，只要还没有对数据做垃圾收集、没有彻底丧失之前，你还可以一个命令，马上恢复这个数据库。

当然通常聊到一个新版本的时候，大家最关心的就是，不服跑个分。所以呢，我们也在最简单最基础的环境下跑了个分，图 7 是 3.0 版本与 2.1 版本的对比。大家知道我们在前不久发布了 2.1，大家可以看到，整体的 Performance 的提升非常的明显，基本上直接 Double 了。大家在实测的过程中，应该会测出比 Double 更高的性能。

当然这个 Performance 的提升，里面有很大一部分是我们一个新的 Storage 的贡献。新的 Storage 叫 Titan。我们也是非常有意思的和美图基于 TiKV 开发的一个 Redis 的实现，使用了一样的名字。大家对于这个希腊神话的热爱，其实是一样的。程序员在选名字的时候，也都有自己的特点，所以大家就重名了，重名之后，我们还讨论了一下，觉得这个名字要不要考虑改一下，后来大家觉得既然都挺喜欢，要不然都用这个吧，我们觉得这也挺好。

然后整个新的存储引擎的 Design 是这样（图 9），我们把 Key 和 Value 做了分离。大家知道，去年我们在做论文分享的时候，有一次专门分享了 《WiscKey: Separating Keys from Values in SSD-conscious Storage》 这篇论文，也是非常感谢这篇论文。Titan 整体上是基于 RocksDB 去做的一个修改或者是一个优化，更多的是在 RocksDB 的外围实现了 Key Value 分离，主要是适应于更大的 Value。

下面是 Titan 的 Performance 跑分。大家看到整体的提升都会非常的明显，从两倍到 N 倍吧，这个 N 的多少，取决于 Value 最终有多大，Value 越大的话，N 会越大（延伸阅读：《Titan 的设计与实现》）。

说了这么多，那么在一个云的时代我们到底是怎样去拥抱云的。
大家知道 TiDB 在最初 Design 的时候，就是为 Cloud 做了大量的优化，同时在三年前我们就相信 Kubernetes 是未来，然后 TiDB 整个就 All-in Kubernetes 了。所以我们一直在等着 Cloud 出一个功能，就是 Cloud 能不能够支持 Native Kubernetes Engine，后来我们看到了 Google 发布了他们的 Kubernetes Engine。所以我们第一时间和 Google 的 K8s 做了一个集成，同时大家现在也可以去访问 Google 云平台（Google Cloud Platform），去试用我们的产品（https://pingcap.com/tidb-cloud/），在那上面真的是一键就可以跑起一个集群，然后都可以由我们来 maintain 整个 TiDB，相当于我们现在有一个 TiDB On Cloud。接下来也会支持 AWS 和 Azure。

其实之前有部分同学都提过，TiDB 做得挺好的为什么不做一套漂亮的界面，然后它的易用性会更佳，更重要的是支持多租户。美团今天也会分享他们在使用 TiDB 的经验，当我们一个集群，两个集群，十个集群，二十个集群，一百个集群的时候怎么办，那么多集群，我怎么用一个简单的方式去维护，那这个时候就需要一套 Database as Service 的东西，能够去帮我管理整个公司的所有 TiDB 集群。所以对于多租户的支持就变得非常有用。同时也会做自动的 Backup 和 Recover。

那我们下一步会有什么不一样的地方？我们刚才提到 3.0 版本有这么多让人非常兴奋的功能，有这么多的巨大改进，什么时候能够把他用到产品里面，是大家接下来关心的一个问题。

首先我们会在今年的 6 月份发布第一个 3.0 的 GA。目前正在不同的用户场景下做大量的测试，通过不同的 Workload  做测试。

另外，大家知道，我们去年写了一个 24 章经——就是 TiDB 源码阅读系列文章，我们写了 24 篇，如果熟悉金庸先生的话应该知道 42 章经，今年我们开始为 TiKV 准备 24 章经，会去详细解读 TiKV 源码的实现。著名 IT 作家、译者侯捷大师说：「源码面前，了无秘密」。我希望大家对于 TiDB 的理解能够深入骨髓。能够自己随意去 Hack 我们的东西，能为整个 TiDB Community 贡献更多东西。

同时我们也会提供更加智能的、基于机器学习的功能。如果大家之前有关注我们的黑客马拉松，会发现我们实现第一个 prototype，是用贝叶斯模型做智能的热点的调度。大家以后应该会跟“人工看热点调度，再人工 split ”这事儿 say goodbye 了。

最后，当我们有大量的用户，有大量的使用场景，有大量的经验的时候，我们需要一个更加强大的 Community 和一个更加强大的 Ecosystem。今天崔秋老师也会去讲我们整个 Community 的运转并为新晋 Committer 授予证书。