首页手记 TiDB 的现在和未来

TiDB 的现在和未来

标签：

大数据

本文根据黄东旭在 PingCAP D 轮融资线上发布会的演讲实录进行整理。

TiDB 的现在和未来

大家好，我是黄东旭，是 PingCAP 的联合创始人和 CTO，这是 PingCAP 成立以来的第一次发布会，我想跟大家简单聊聊 TiDB 在产品和技术上的更新。考虑到线上的很多观众不一定是有很强的技术背景，我将尽我所能将技术的部分说得让大家都能够理解。

在讲正题之前有一个小故事，我们做基础软件的产品经理去跟客户聊需求的时候，客户经常都会说：对于数据库，我的要求特别简单、特别基础、非常朴素，我不要求很多功能，安全稳定是必须的，最好能高可用，性能一定要好，如果数据量大了，能实现弹性伸缩就更好了；另外，最好别让我学太多新东西，用起来跟过去使用的产品差不多，这就是一款完美的数据库产品。

就像大家在家里用自来水一样，我们对自来水的需求就是拧开水龙头水就能出来，但是背后自来水厂是怎么处理的大家不用知道，我们只需要根据实际情况使用冷水或者热水就好。但是从技术的角度来说，刚才类似冷热水这个非常朴素的基础需求，类比一下放到数据库的世界这就是一个图灵奖级别的基础需求，稍微解释一下图灵奖是计算机行业学术界最顶级的，相当于计算机界的诺贝尔奖。

这里有两位行业泰斗级的人物，左边 Leslie Lamport 在 2013 年研究相关问题拿了图灵奖，右边这位跟我们挺有缘的，发型跟（我们的 CEO）刘奇同学挺像，他是 UC 伯克利分校的一名教授，也是著名 CAP 定理的提出者，PingCAP 中的 CAP 就是来源于此。虽然看上去这个需求是一个很朴素的需求，但是这是一个值得去花很长时间研究，在技术领域很有挑战，也是一个很前沿的研究领域。

在聊数据库之前，我想带大家回顾一下十年前的电子产品，回顾一下我们当年的生活，大家回想一下十年前我们手上的数码产品有哪些，比如我们打电话有诺基亚，拍照有数码相机，也有用来做导航的独立设备 GPS，听歌用的 MP3 等等，种类繁多。

我们再来回顾一下这十年，这些东西好像在我们的生活中渐渐消失掉了，一台智能手机把很多这些碎片化的东西统一了起来，我觉得这背后一个很重要的点就是我们对于统一用户体验的追求驱动了整个科技界产品发生翻天覆地的变革，现在一台智能手机基本解决了我们生活中百分之七八十的数字化生活场景的需求。

TiDB 是一个 HTAP 系统

接下来进入正题，PingCAP 是做数据库的厂商，如果我们拉一条数轴来看，左边的业务是更偏实时在线的业务，如果这条数轴的右边是离线业务的话，按照这个数轴来看，数据库这个产品大家可能印象中是在左边的，一些典型场景，比如像 Hadoop 或者一些数据仓库、报表是在右边。

再看一个具体的业务场景，假设是一个公司要打造电商平台的 IT 系统，梳理一下现在电商平台内部有各种各样的应用和场景，我们按照这些场景放到这个数轴上，左边是在线，右边是离线，我们看到比如交易、订单管理、明细查询，这可能是偏在线的业务，用户用手机随时可以打开看；右边离线业务更像是内部运营人员，比如老板查看去年赚了多少钱，这种报表可能是一个更偏离线的业务。

大家有没有发现中间有一些实时的报表，实时的促销调价，热销产品的推荐，你放在左边不合适，放在右边好像也不太对，所以中间部分是一个比较模糊的状态，这是一个业务的语言，比如我们把这个业务放到这条轴上去看，比如说我是电商平台的技术人员，业务人员告诉我，我们上面这些需求，这些需求翻译成技术的语言会变成什么样子呢？

就变成了各种各样的 OLTP 数据库和 OLAP 数据库和数据仓库，比如像 ClickHouse、Greenplum，像离线的数据仓库 Hadoop、HIVE，有很多同学不了解这些名词没关系，我只是想展现一下，业务需求翻译成技术语言，通常需要一系列复杂的数据技术栈来支撑。

可能有很多观众学过计算机技术，我记得我在上大学的时候，我们有一门课是叫数据库系统，老师上课的时候教我数据库就是增删改查，就是存数据、取数据的一个系统、一个软件，几个关键的命令 INSERT\SELECT\UPDATE\DELETE，我回忆了一下好象也没有教哪些场景是 OLTP 的场景，哪些是 OLAP 的系统，并没有这么复杂。

数据库应该就是存数据、取数据天经地义，就像水龙头一样一拧开就出水，我还特地查了一下 database 的定义，在维基百科上面的定义其实并没有说 OLTP 的 database 或者 OLAP 的 database。

我知道这可能是一个细分的领域，但是从数据库这个词的本源来看，本质上像一个容器一样，存储数据和取数据的一个系统，好像也没什么复杂。

为什么今天很多工程师，很多用户就觉得这个数据库或者这个场景一定是个 OLTP，或者是个 OLAP ，要有一个泾渭分明的分类。就像刚才电商的例子，其实有大量中间的场景很难说到底是一个 OLTP 还是 OLAP 。但是现在的现实是对于很多 IT 系统、业务系统来说，对于实时性的要求越来越高，为了解决这个问题，我们构建了各种各样的数据孤岛，构建了各种各样的烟囱式系统。

所以过去这种泾渭分明式的分类方式到底适不适用现在有越来越多实时性要求的时代呢？

回过头来思考这个分类是不是有问题的时候，作为一个理工男或者作为一个学理科出身的工程师，我们特别喜欢寻找一个定义或者寻找一个分类。我们找遍了各种各样的定义，从学术界、工业界、到各类咨询机构，发现 HTAP 是一个更加符合或者说更加适合现在 TiDB 应用场景的一个定义。

TiDB 的定位是一个 Real-Time 的 HTAP 系统，有很多朋友后来问我，TiDB 是一个 HTAP 系统，是不是就意味着你不是一个 OLTP 系统，或者说你到底是一个 OLTP 还是 OLAP ？

我们回到智能手机的那个例子，首先智能手机一定是一个 100% 的手机，肯定能打电话，在打电话的基础上再加上很多其他的常用功能，比如相机、GPS、MP3等在一个系统里面搞定。我想强调的是 TiDB 的定位就是 Real-Time HTAP 系统，首先是一个 100% 的 OLTP 系统，同时还能支持一些 Real-Time OLAP Query。

讲到 TiDB，我其实很感慨，我一直看着这个产品一步步成长起来，最近这一年成长速度尤其快，现在我很高兴地看到 TiDB 4.0 已经成为社区的一个主流版本。

在 4.0 发布的时候，我当时很热情洋溢的发表了一段话，说这是一个非常具有里程碑意义的一个版本，事实上 TiDB 4.0 的表现我觉得是不负众望的，现在大家都非常喜欢，成为了主流。

展望 TiDB 5.0

我想跟大家展望一下 TiDB 5.0，在讲 5.0 之前我想稍微强调一下 TiDB 做产品的思路。我们都是工程师出身，也比较接地气，不说什么高大上的，用大白话来说就四点：稳、快、好用和用着放心。前面提到过用户对于一个数据库产品的朴素需求，我们也是希望按照这种方式来做产品。

但在 TiDB 5.0 里面我们真正把一个具体的目标放到了产品规划的方向里面，那就是 TiDB 要走向各行各业的核心场景。之前，TiDB 从 2.0 到 3.0 和 4.0，已经开始慢慢地走向了各行各业，慢慢地渗透到一些对稳定性、对性能要求非常极致的场景，包括金融、银行的一些核心业务系统。

在 TiDB 5.0 这个版本，我们第一次明确地提出，至少在产品层面上要达到各行业核心场景对于数据库性能和稳定性的要求。

接下来具体谈谈 TiDB 5.0 在这几个方面的进展。

首先第一点稳定性，我经常说一句话：把一个东西做对其实是很难的，把一个数据库做出来不难，做对却很难，所以我们构建了各种各样的正确性的测试系统。现在 TiDB 已经做出来了，下一个阶段是更稳，但是要使得 TiDB 更加稳定还有很多的工作要做，这方面没有捷径，道理谁都懂，魔鬼在细节，只有做得越来越深，越来越细，我很高兴的看到，在 TiDB 5.0 中我们和用户一起把 TiDB 的稳定性又往前推进了一个级别。

下图是 5.0 在某个券商机构的测试结果，在 48 小时高压力的测试场景里面 TiDB 5.0 的系统抖动一直小于 5%，同时在性能上跟 4.0 相比有明显的提升。我想强调的是在做稳定性这件事情上，已经开始进入改革深水区，低垂的果实已经摘的差不多了，剩下就是一些场景和技术上比较硬的难题等着我们去攻克，我们很高兴地看到 5.0 对于 4.0 在稳定性上有比较出色的表现。

第二，性能快。天下武功，唯快不破，尤其是对于数据库这样的基础软件来说，特别是在一些核心应用场景，比如像银行的一些核心交易系统，一个毫秒的额外延迟可能就会对整体的系统和用户体验造成影响。

在 TiDB 5.0 里面我们很高兴地看到，对比 4.0 延迟几乎成倍地下降。这让我想到跟开发团队经常开的玩笑，说 TiDB 每个版本有点像摩尔定律，每一个版本比上一个版本性能提升一倍、延迟下降一倍、成本不变，未来成本还会持续下降。我很高兴看到 5.0 还是保持着这个规律，所以，性能快与延迟降低在 5.0 里面会是一个很重要的标签。

快的另外一个方面，首先熟悉 TiFlash 的同学看到标题肯定会心一笑，我们之前有提到 TiDB 是一个 Real-Time HTAP 架构，AP 这部分是由 TiFlash 分析加速引擎来提供服务的。在 5.0 里面 TiFlash 将支持分布式的聚合和分布式的计算（MPP），能让整个 TiDB 的 OLAP 能力真正延伸到更多的应用场景，应对更多更复杂的 JOIN 场景。

好用，这个方面我想强调的有两点。

首先，大家看到跨数据中心、跨地域一个部署，很多做分布式系统的同学会觉得很兴奋，TiDB 终于可以支持做 Geo-Partition（多地多活跨地域数据分布）。我稍微解释一下，TiDB 是一个分布式数据库，所以有很多用户、很多开发者希望 TiDB 可以实现真正的跨长距离或者跨多个数据中心的部署，可以在全国或者全球都组成一个大的网络。

其次，打通多个流行数据处理栈生态和提供全链路追踪系统，也将使得 TiDB 5.0 变得更加好用。

提到 Geo-Partion，实际上，有很多客户有这样的场景需求，特别是对于一些海外客户，比如一家欧洲公司的业务遍布全球，这时候如果有一个数据库系统，能够支持全球跨长距离的区域部署，能够在不同的国家、不同的位置随时提供服务，运维方面也省去了部署多套技术栈和数据库系统的成本，这对于客户来说就是一个理想之选。

举个例子，我们刚才提到多地部署，怎么降低本地的延迟，如果是一个欧洲公司，大家知道欧洲有很严格的 GDPR ，企业的数据不能出境，这种场景下 Geo-Partition 就是一个非常实用的特性。

如果是现在的 TiDB 去做这件事情，比如说在欧洲、中国、美国同时提供服务，在一些场景下的数据库性能和延迟可能会不太理想，因为需要到一个中央的服务器上去处理，去拿时间戳，然后才能提供服务。

在 TiDB 5.0 里面，我们将中央的授时服务改成了一个分布式授时的服务，能够让这个系统在本地或者在多数据中心场景里面的性能表现更佳。

第二个方面是 TiDB 的“朋友”越来越多，作为一个基础软件，虽然 TiDB 的目标是尽可能的把很多场景统一，但我觉得 TiDB 跟业界其他生态技术栈的互联互通也是一个非常重要的方面。

现在对于 TiDB 来说，已经能够与 Flink、Kafka、Spark，包括 Hadoop、AWS S3 以及 MySQL、Oracle 这些传统的数据库进行互联互通。

举一个具体用户的例子，这是一个在线的实时数仓业务，线上的业务持续在做交易，在做写入，同时这些数据通过 TiDB TiCDC 增量订阅模块输出到 Kafka，同步到 Flink 流式计算引擎去做归纳、聚合与分析，然后再重新写回到 TiDB。写入到 TiDB 的这些数据再去对在线业务进行补充，TiDB 结合 Kafka、Flink 组成了一个简单易用的实时数仓架构。