刘奇:我们最喜欢听用户说的话是「你们搞得定吗?」 | 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 保持好奇的人。今天我主要想跟大家分享一下我们过去一年的一些发展情况,以及我们对于未来的一些想法。

Growth

图 1

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

图 2

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

图 3

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

HTAP Rocks!

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

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

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

图 4

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

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

图 5

当然大的氛围下面,吹牛的很多,但如果我不知道他是怎么 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。大家可以保持期待,这个一定不会让大家失望。我昨天看了一下演示,非常震撼。

TiDB 3.0 Beta

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

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

图 6

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

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

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

图 7

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

图 8

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

图 9

然后整个新的存储引擎的 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 的设计与实现》)

图 10 Titan Data Loading Performance

图 11 Titan Update Performance

图 12 Titan Random Key Lookup Performance

图 13 Titan Sorted Range Performance

TiDB on Cloud

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

图 14

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

What’s Next

图 15

那我们下一步会有什么不一样的地方?我们刚才提到 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 授予证书。

你可能感兴趣的:(刘奇:我们最喜欢听用户说的话是「你们搞得定吗?」 | TiDB DevCon 2019)