共计 5708 个字符，预计需要花费 15 分钟才能阅读完成。
本文依据黄东旭在 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 组成了一个简略易用的实时数仓架构。
说到平安，对于数据库来说，平安其实是十分重要的，在咱们的产品布局外面，平安是放在很高优先级的个性。
我想强调，在 4.0 外面 TiKV 存储层曾经反对全链路的数据通明加密。在 DBaaS 平台外面，咱们正在引入 RBAC，就是基于用户身份的鉴权零碎，同时咱们会跟 AWS 的身份认证零碎进行买通，给用户提供更加平安、更加牢靠的产品与服务保障。
在平安合规方面，随着 TiDB 越来越多地利用在国内、国外一些要害的业务场景，不同的国家，不同的利用场景对于合规的要求出现多样化特点，TiDB 曾经通过了 SOC2Type1 认证，这是在美国金融行业外面十分认可的合规规范，将来咱们将在合规下面投入更多的精力。
将来的数据库是什么样子？
后面是对于 TiDB 5.0 在当初这个工夫点的停顿同步。然而将来在哪里？
咱们每一个分享最初的局部会讲讲到底将来应该是什么样子的，我感觉在比拟近的将来，TiDB 一个重要的方向是更加云化。为什么云如此重要？数据库云化的背地我感觉能够开展几点：
- 一个是 Severless；
- 二是智能的调度能力；
- 第三是利用云的基础设施降低成本。
为什么说云如此重要？大家能够看到左边这张图，横轴是数据量和业务需要，纵轴是企业在 IT 上投入的老本，在云诞生之前咱们在去做面向不确定性的业务，面向暴涨的数据量，如果采纳传统的 IDC 部署形式，老本和投入的曲线跟理论的需要不能齐全吻合，其实存在很多资源的节约。
首先，只有云真正把整个根底软件的商业模式变成了 pay as you go，尽可能地贴合业务的增长曲线，对于数据库这样很重要的根底软件来说，在云上利用云的弹性可能去更正当地满足业务的理论需要。
第二，云很好地屏蔽了底层基础架构实现的复杂性，对于做根底软件的人来说，这具备划时代的意义。比如说利用云的弹性调度能力以及一些 AI 新技术，使得这个零碎更好地了解业务的需要，更加智能地布局该把数据搁置在什么中央，该建设什么样的索引。
第三，云是很好的基础设施，面向云时代的基础设施如何去设计下一代的根底软件，我感觉是一个很重要的课题。最近关注技术圈的敌人，Snowflake 的音讯令大家十分振奋，Snowflake 在技术上的抉择也带给我很多启发，怎么通过云的基础设施来打造新一代的根底软件。
以上是我对近期将来的一些瞻望和认识。最初我想强调的是，回归初心咱们想做的事件就是让数据库真正回归本来的样子，把复杂性暗藏在背地，为用户提供一个应用门槛很低，解放大家生产力的好产品，谢谢大家！
