TiDB 的如今和将来
本文根据黄东旭在 PingCAP D 轮融资线上发布会的演讲实录进行整理。
TiDB 的如今和将来
你们好，我是黄东旭，是 PingCAP 的联合创始人和 CTO，这是 PingCAP 成立以来的第一次发布会，我想跟你们简单聊聊 TiDB 在产品和技术上的更新。考虑到线上的不少观众不必定是有很强的技术背景，我将尽我所能将技术的部分说得让你们都可以理解。数据库
在讲正题以前有一个小故事，咱们作基础软件的产品经理去跟客户聊需求的时候，客户常常都会说：对于数据库，个人要求特别简单、特别基础、很是朴素，我不要求不少功能，安全稳定是必须的，最好能高可用，性能必定要好，若是数据量大了，能实现弹性伸缩就更好了；另外，最好别让我学太多新东西，用起来跟过去使用的产品差很少，这就是一款完美的数据库产品。安全
就像你们在家里用自来水同样，咱们对自来水的需求就是拧开水龙头水就能出来，可是背后自来水厂是怎么处理的你们不用知道，咱们只须要根据实际状况使用冷水或者热水就好。可是从技术的角度来讲，刚才相似冷热水这个很是朴素的基础需求，类比一下放到数据库的世界这就是一个图灵奖级别的基础需求，稍微解释一下图灵奖是计算机行业学术界最顶级的，至关于计算机界的诺贝尔奖。服务器
这里有两位行业泰斗级的人物，左边 Leslie Lamport 在 2013 年研究相关问题拿了图灵奖，右边这位跟咱们挺有缘的，发型跟（咱们的 CEO）刘奇同窗挺像，他是 UC 伯克利分校的一名教授，也是著名 CAP 定理的提出者，PingCAP 中的 CAP 就是来源于此。虽然看上去这个需求是一个很朴素的需求，可是这是一个值得去花很长时间研究，在技术领域颇有挑战，也是一个很前沿的研究领域。网络
在聊数据库以前，我想带你们回顾一下十年前的电子产品，回顾一下咱们当年的生活，你们回想一下十年前咱们手上的数码产品有哪些，好比咱们打电话有诺基亚，拍照有数码相机，也有用来作导航的独立设备 GPS，听歌用的 MP3 等等，种类繁多。架构
咱们再来回顾一下这十年，这些东西好像在咱们的生活中渐渐消失掉了，一台智能手机把不少这些碎片化的东西统一了起来，我以为这背后一个很重要的点就是咱们对于统一用户体验的追求驱动了整个科技界产品发生翻天覆地的变革，如今一台智能手机基本解决了咱们生活中百分之七八十的数字化生活场景的需求。less
TiDB 是一个 HTAP 系统
接下来进入正题，PingCAP 是作数据库的厂商，若是咱们拉一条数轴来看，左边的业务是更偏实时在线的业务，若是这条数轴的右边是离线业务的话，按照这个数轴来看，数据库这个产品你们可能印象中是在左边的，一些典型场景，好比像 Hadoop 或者一些数据仓库、报表是在右边。运维
再看一个具体的业务场景，假设是一个公司要打造电商平台的 IT 系统，梳理一下如今电商平台内部有各类各样的应用和场景，咱们按照这些场景放到这个数轴上，左边是在线，右边是离线，咱们看到好比交易、订单管理、明细查询，这多是偏在线的业务，用户用手机随时能够打开看；右边离线业务更像是内部运营人员，好比老板查看去年赚了多少钱，这种报表多是一个更偏离线的业务。分布式
你们有没有发现中间有一些实时的报表，实时的促销调价，热销产品的推荐，你放在左边不合适，放在右边好像也不太对，因此中间部分是一个比较模糊的状态，这是一个业务的语言，好比咱们把这个业务放到这条轴上去看，好比说我是电商平台的技术人员，业务人员告诉我，咱们上面这些需求，这些需求翻译成技术的语言会变成什么样子呢？oop
就变成了各类各样的 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 组成了一个简单易用的实时数仓架构。
说到安全，对于数据库来讲，安全实际上是很是重要的，在咱们的产品规划里面，安全是放在很高优先级的特性。
我想强调，在 4.0 里面 TiKV 存储层已经支持全链路的数据透明加密。在 DBaaS 平台里面，咱们正在引入 RBAC，就是基于用户身份的鉴权系统，同时咱们会跟 AWS 的身份认证系统进行打通，给用户提供更加安全、更加可靠的产品与服务保障。
在安全合规方面，随着 TiDB 愈来愈多地应用在国内、国外一些关键的业务场景，不一样的国家，不一样的应用场景对于合规的要求呈现多样化特色， TiDB 已经经过了 SOC2Type1 认证，这是在美国金融行业里面很是承认的合规标准，将来咱们将在合规上面投入更多的精力。
将来的数据库是什么样子？
前面是对于 TiDB 5.0 在如今这个时间点的进展同步。可是将来在哪里？
咱们每个分享最后的部分会讲讲到底将来应该是什么样子的，我以为在比较近的将来，TiDB 一个重要的方向是更加云化。为何云如此重要？数据库云化的背后我以为能够展开几点：
- 一个是 Severless；
- 二是智能的调度能力；
- 第三是利用云的基础设施下降成本。
为何说云如此重要？你们能够看到右边这张图，横轴是数据量和业务需求，纵轴是企业在 IT 上投入的成本，在云诞生以前咱们在去作面向不肯定性的业务，面向暴涨的数据量，若是采用传统的 IDC 部署方式，成本和投入的曲线跟实际的需求不能彻底吻合，其实存在不少资源的浪费。
首先，只有云真正把整个基础软件的商业模式变成了pay as you go，尽量地贴合业务的增加曲线，对于数据库这样很重要的基础软件来讲，在云上利用云的弹性可以去更合理地知足业务的实际需求。
第二，云很好地屏蔽了底层基础架构实现的复杂性，对于作基础软件的人来讲，这具备划时代的意义。好比说利用云的弹性调度能力以及一些 AI 新技术，使得这个系统更好地理解业务的需求，更加智能地规划该把数据放置在什么地方，该创建什么样的索引。
第三，云是很好的基础设施，面向云时代的基础设施如何去设计下一代的基础软件，我以为是一个很重要的课题。最近关注技术圈的朋友，Snowflake 的消息令你们很是振奋，Snowflake 在技术上的选择也带给我不少启发，怎么经过云的基础设施来打造新一代的基础软件。
以上是我对近期将来的一些展望和见解。最后我想强调的是，回归初心咱们想作的事情就是让数据库真正回归本来的样子，把复杂性隐藏在背后，为用户提供一个使用门槛很低，解放你们生产力的好产品，谢谢你们！