刘奇：当今一切都要更实时、更弹性、更简单，TiDB 就是这样的基础设施 | TiDB DevCon 2020

6 月 7 日，TiDB 社区年度技术大会 TiDB DevCon 2020 圆满落幕，本届大会采起线上直播的形式，汇聚了来自全球各地的 80+ 开发者、TiDB 用户及合做伙伴分享第一手开发及实践经验，议题覆盖金融、电信、电商、物流、视频、资讯、教育、医疗等诸多行业，干货满满，应接不暇。会上咱们正式发布了具备里程碑意义的 TiDB 4.0 GA 版本，并分享了技术细节及生产环境的实战效果，并为过去年在 TiDB 社区做出卓越贡献的 Contributor、Committer、Maintainer 授予了荣誉奖杯与证书。

本届大会历时 2 天，共设置 7 个论坛，29 小时累计分享时长，直播间人气值高达 2.3 万，错过的小伙伴们能够继续“蹲守”本公众号近期推送，咱们将陆续挑选整理部分精彩内容输出，敬请期待！

如下是我司联合创始人兼 CEO 刘奇的现场分享实录。

每一年我都有一个时间会特别激动，就是产品大版本发布的时候，一般也是社区年度技术大会 TiDB DevCon 举办的时间。去年 TiDB DevCon 2019，咱们发布了 TiDB 3.0 Beta，固然今年 TiDB 4.0 GA 也如约而至。

Serverless

很长一段时间 TiDB 用户使用的集群规模都很大，而后就会再提出一个诉求说“怎么下降个人使用成本”。TiDB 4.0 拥有了 Serverless 能力以后，会根据用户的实际业务负载，基于 K8s 自动作弹性伸缩。

从前，当咱们在上线一个系统的时候，第一件事就是 Capacity Planning，去评估一下咱们大概须要多少台服务器，好比提早准备了 50 台，可是实际上线以后跑了一个月，发现 5 台机器就够了。这就致使了大量的资源浪费。若是整个系统可以在云上全自动弹性伸缩，就能避免这种资源浪费。

更重要的是，TiDB 的弹性伸缩，意味着你永远不须要按照业务的峰值配备系统资源。好比你们的业务会有早、晚两个明显的高峰，但实际上每一个高峰持续时间一般只有 2 个小时左右，也就是说，为了这 4 个小时的高峰，而咱们配置了 24 小时的最高资源配置，并为此付费，但非高峰时间的资源和成本彻底是能够节省的，可能算下来，咱们可以节省的成本大概在 70% 左右，甚至更高。

另外，可以弹性伸缩的 TiDB 能够应对没法预测的 Workload，没有人知道哪个商品在何时会大卖，没有人知道我卖的哪个基金在何时会火，这时若是咱们给系统一个权限，让它可以自动根据业务当前的实际状况，扩充服务器，这对某个企业或者某个业务来讲，多是“救命之道”，好比像上图的状况，人为介入每每是太慢了，来不及了。

Real-Time HTAP

在当今这个世界，你们但愿全部的东西都要更快、更简单。但若是你们仍是按照传统的方式去运用一个数据库，就不能知足这个“更快、更简单”的需求了，由于传统的方式须要通过一系列很是复杂的过程从数据库里面去提取这些变化的信息、事件、日志，再去作分析，那这个过程每每会带来比较长的延迟，这些「延迟」让咱们失去了不少直接的经济价值。

在 TiDB 4.0，咱们正式推出了 TiFlash，TiFlash 是配合 TiDB 体系的列存引擎，它和 TiDB 无缝结合，在线 DDL、无缝扩容、自动容错等等方便运维的特色也在 TiFlash 中获得继承，同时 TiFlash 能够实时与行存保持同步。

有了 TiFlash，TiDB 4.0 在大量的复杂计算场景下，至少可以比上一个版本快 10 倍，而且咱们永远不须要去操心“一致性”的问题。无论，面临的是简单的 OLTP 类型的 Workload，仍是复杂的 OLAP 类型的 Workload，它老是一致的、实时的，而且可以自动弹性扩张或伸缩。

上面的架构图你们应该很是熟悉，几乎每一家拥有必定数据规模的公司都经历过。曾经有一个用户，他们在一个大概只有几十 T 数据规模的场景下，搭建了相似上图那样复杂的系统，就是为了可以作 OLTP 和一个报表查询。这中间不得不接入 Kafka 和 ETL，而后将这个报表查询的结果又从新序列化到 HBase 之类的存储系统里面。有没有办法去简化整个系统呢？

当咱们用 TiDB 4.0 的视角去看的时候，用户已经给出了他们上线的答案。如上图所示，当咱们把 TiDB 放在中间这一层，整个系统的复杂度就下降了很是多。接下来也会有用户分享他们使用 TiFlash 的经验，以及他们在架构上面作了哪些简化。

说回来，站在基础架构这一层，用户其实并不想知道这个 Workload 究竟是长查询仍是短查询，站在用户的角度，只是但愿尽快获得结果，尽量减小过程的复杂度以节省成本、提升开发速度，创造更多价值。

Cloud-Native

我知道你们都很是期待 PingCAP 可以提供 TiDB 的云服务，如今我很高兴发布 TiDB Cloud，由 PingCAP 来管理，维护，优化的 TiDB 云。

咱们从四年前就开始作了这个准备，今天 TiDB 能够无缝地在“云端跳舞”。

若是有人说：“我不想安装 TiDB，我不想去维护 TiDB”。那这个事，你也能够选择交给 PingCAP 来作。目前咱们已经支持了 AWS、GCP 两个云平台（其它云平台的支持也在稳步推动），若是你正在使用这两个平台，那么你什么都不须要作，点几下鼠标就能够轻松使用 TiDB，真正的「开箱即用」。

在 TiDB 4.0 中咱们提供了超过 70 个新特性，能够阅读这篇文章《TiDB 4.0：The Leading Real-Time HTAP Database is Ready for Cloud》。

Dashboard

在 TiDB 4.0 里面内置了 Dashboard，很是适合像我这种好久没有写 SQL 的人，经过图形界面解决大多数问题，观察整个系统里的热点数据、慢查询，业务在数据库上具体是什么样子，经过多种不一样的视图去理解业务负载等等。咱们但愿在 10 秒钟内就帮用户定位大部分故障和问题，下面的 Dashboard 知足了个人全部“幻想”。

性能：Faster and faster

性能是一个永远都会“使人兴奋”的问题。对比 3.0 版本，TiDB 4.0 总体的性能提高了 50% 左右；若是是跑聚合查询，在不少场景下能作到提高 10 倍，甚至是更高，TPC-H 的性能也提高了一倍。这个成果也来自于整个 TiDB 开源社区的贡献，去年年末咱们举办了 TiDB 挑战赛 第一季“性能挑战赛”，总共有 165 位社区开发者参赛，包括 23 支参赛队伍和 122 位我的参赛者，他们的参赛成果都落地到了 TiDB 产品当中。

TiUP 一键安装部署

以前有同窗吐槽说，我安装 TiDB 太麻烦了，花了几十分钟甚至一天，才把整个系统部署起来。

在 TiDB 4.0 中，咱们专门写了一个工具，叫 TiUP，它是一个包管理器。经过 TiUP，你们能够在一分钟内本地把 TiDB 跑起来，一分钟就可以体验 TiDB。而部署 15 个节点的生产集群也只须要 45 秒，也就是彻底作到 1 分钟内快速体验。TiUP 是一个巨大的易用性体验的提高，欢迎你们去体验。

TiUP: A component manager for the TiDB eco-system

Try TiDB (playground) within 1 minute with 1 command

$ curl https://tiup-mirrors.pingcap.... | sh && tiup playground nightly --monitor

Deploy a production cluster in 45 seconds

TiUP 对用户来讲是一个巨大的易用性体验的提高，欢迎你们去体验。

Security matters!

随着 TiDB 在全球的应用规模愈来愈大，愈来愈多的用户在更加严肃的场景里使用 TiDB，所以咱们也提供了你们很是关注的安全特性，来符合各个国家对安全和隐私的合规要求。目前全部 TiDB 通信组件的通信过程都是所有加密的，全部存储的数据都支持透明加密，包括 PingCAP 或者任何一家云厂商，都不能侵犯到 TiDB 用户的数据隐私与安全。当 TiDB 跑在这个云上时，没有人可以看到数据库，没有人可以从中截获到通信过程的数据。

实战效果如何？

相信有人会有疑问，讲了这么多，TiDB 4.0 是否真的准备好了？能不能上生产环境？有没有实战数据分享？

上图知乎的已读服务，前几天知乎刚升级到 TiDB 4.0 的最大的一个内部集群。整个集群容量有 1 PB，目前的存储数据量已经达到了 471TB。

我第一次看到这个数据的时候仍是很是震惊的，不只仅是由于数据规模，还震惊和感动于孙晓光老师（知乎，TiKV Maintainer）对 4.0 的信心，他们在 5 月 28 日 4.0 GA 版本正式发布的第4天，就已升级。固然，看到这个结果，个人信心也更强了，TiDB 不只仅支撑这么大数据规模，更重要的是让知乎已读服务的整个系统计算能力有了很大的提高，极大改善了整个系统的延迟。

从上图能够看到，TiDB 4.0 与上一个版本相比，下降了 40% 的延迟，换句话说，若是在维持相同的延迟的状况下，大约可以下降 40% 的成本。

Why is TiDB so Popular ?

过去的一年，我也会常常被问到一个问题，为何 TiDB 如此的流行？为何 TiDB 可以走遍全世界？为何可以获得这么多用户的使用和赞扬（固然也有吐槽，用户的吐槽也让咱们很积极、颇有动力去改进，去快速迭代）？

其实这一切不只仅是 PingCAP 的功劳，而是整个开源社区的功劳，PingCAP 只是 Community 的一部分。正是由于有全球各地的开发者参与贡献，好比美国的 Square、Azure、Zoom、法国的 Dailymotion、日本的 PayPay 等等，给咱们提意见、提需求，提 PR 贡献代码，一块儿打磨、一块儿成就了今天的 TiDB ，组成了如今庞大的 TiDB 开源社区。

在 4.0 发布的时候，咱们也作了一个词云，看了看 TiDB 代码贡献者所属的组织，而且按照组织的贡献程度，画了一张图出来，咱们才发现原来有这么多的组织，在 TiDB Community 中持续贡献：

同时，常常会让我感到惊喜的是社区的创造性。好比 TiDB Contributor 刘东坡把贡献排名前 100 的 Contributor 作了可视化的展现：

<div class="caption-center">https://rustin-liu.github.io/...</div>

这位小伙伴也在本届 TiDB DevCon 的开发者社区专题论坛中分享了参与社区的心路历程，咱们也但愿更多人可以像这位小伙伴同样，在 TiDB 社区中有所收获，更在贡献中感觉到乐趣&归属感。

另外，无论你是谁，只要你想参与 TiDB 的打造或者想使用 TiDB，咱们都为你准备好了：

• 若是你在用 TiDB 过程当中，遇到任何问题，你均可以去 AskTUG（https://asktug.com）提问，有超过 2700 个会员，他们都在 AskTUG 中分享实战经验或者踩过的坑，或许你遇到的问题，在这里搜索一下就能获得解答。
• 若是你还想进一步再深刻的学习 TiDB，咱们也推出了 PingCAP University（https://university.pingcap.com）线上及线下的培训课程。最后你们也能够验证一下本身的学习效果，也能够去参加认证考试（以下图所示）。

在过去的几个月里，TiDB 社区伙伴们也作了一些比较疯狂的事情。好比，咱们花了 48 小时写了一本书《TiDB 4.0 in Action》（阅读地址：book.tidb.io）。或许乍一听以为很神奇，48 小时怎么可能能写一本书呢？但你们去看一下做者的数量就能理解了，这本书有 100 多位做者，每一个人写一小节，就是 100 小节，48 小时轻松搞定。固然这个事情也不是轻松促成的，它的实现实际上是整个社区长时间的知识&精神力量的积累。

若是看到这里，你雄心勃勃，还想再精进一步，想写一个属于本身的分布式数据库。没问题，咱们还准备了 Talent Plan 课程，能够根据课程规划一步步 build 一个分布式数据库的计算层、存储层，这门课程还会有来自全球各地的导师帮你 Review 代码和做业，目前暂时支持中文和英文。

Bonus: Chaos Mesh™!

最后聊一聊咱们在混沌工程方面的实践，在软件领域有一个常识是，“现实中全部能够预见的故障，最后都必然会发生”，系统的复杂性是没法逃避的、必需要面对的，也是咱们必需要去解决的。在今天，整个系统的复杂性已经不只仅局限于数据库了，而是延展到了整个业务的全链路，最终落脚在系统为用户提供的服务质量。

如上图所示，Amazon 和 Netflix 两家公司的微服务可视化以后的样子，不能简单用蜘蛛网来比喻，它实际上比蜘蛛网还要复杂得多。因此咱们须要一套系统，去模拟现实中全部可能发生的故障，而且让这个故障不断的发生，未雨绸缪地加强系统的鲁棒性。

所以，咱们在开发 TiDB 的整个过程当中，构建了一套系统 Chaos Mesh。它会作什么？

好比，它能够模拟磁盘坏掉。在咱们的测试环境中，磁盘每分钟坏一次，网络每分钟都会产生隔离。尽管这种状况在现实世界中极少出现，可是一旦出现就会造成灾难性的故障。而模拟磁盘坏掉只是 Chaos Mesh 能够提供的众多功能之一。

Chaos Mesh 将帮助你们在业务的全链路上，作完整的、全部可能出现的故障测试。以往你们凭经验所说的 “有 99.99% 或者有 99.999% 的概率系统可以正常运行”，都包含了一些“运气”成分在其中。由于，咱们用 Chaos Mesh 去测试了各类故障状况，会发现某个系统要作到“99.99% 或者 99.999% 正常运行”是很是很是少见的、极其困难的一件事。在 TiDB 的开发过程当中，咱们同步使用了 Chaos Mesh 来测试 TiDB，TiDB 4.0 在测试用户中的反馈很是好，一部分也要归功于 Chaos Mesh “疯狂摧残式”的测试。固然咱们也很是欢迎你们使用 Chaos Mesh 测试和打磨本身的系统。

结语

实际上，TiDB 发展到今天，已经不只仅是一个数据库产品，它已是不少系统的基石，做为一个基础设施的存在。你们在使用以前，也能够参考其余人的成熟经验或者解决方案，TiDB DevCon 2020 上有 80+ TiDB 用户&合做伙伴分享一手实践经验，无论你来自哪一个行业，好比金融、电商、物流、新零售、出行、电信、医疗、能源、制造业、高科技、教育、视频、资讯；仍是应用在不一样的使用场景，好比实时分析、数据汇聚、Data Mart，元数据存储、日志审计、日志统计分析，还有 IM 等等。全部你想看了解的行业参考，你想了解的场景实践，咱们已经准备好了。后续 TiDB DevCon 2020 部分视频&文字回顾将陆续整理输出，敬请期待。

感谢社区伙伴们的热情参与和支持，将来咱们继续携手同行，走向开源世界的星辰大海！关注 PingCAP 微信公众号(pingcap2015)，在后台回复“ DevCon2020”获取部分通过讲师受权后整理的 PPT 资料。

TiDB DevCon 是 PingCAP 团队面向 TiDB 社区推出的技术会议，每一年在北京举办。本届 DevCon 在 6 月 6 ～ 7 日举办，以线上直播的方式，为你们展现 TiDB 近一年的产品技术蜕变，分享最新的海内外生态进展，并邀请了来自全球的 80+ 位开发者、用户及合做伙伴，分享他们的实战经验和开源思考，覆盖金融、制造业、电信、电商、物流、能源、快消、新零售、云计算等多个领域。

本文内容以 PingCAP 官网博客栏为准，欢迎点击【这里】查看原文。

若对 TiDB 的使用有所疑问，也能够登陆 Asktug.com 搜索或发帖交流～