聊聊数据库的将来，写在 PingCAP 成立五周年前夕

数据是架构的中心

做为一个互联网行业的架构师，几乎是每天都在和各类类型的数据打交道，这么多年的经验，不一样行业不一样系统，从技术层面来讲，抽象到最高，总结成一句话就是：

数据是架构的中心。

仔细想一想，咱们其实作的一切工做，都是围绕着数据。数据的产生，数据的存储，数据的消费，数据的流动……只不过是根据不一样的需求，变化数据的形态和服务方式。计算机系的同窗可能还记得老师说过的一句话：程序 = 算法 + 数据结构，我这里斗胆模仿一下这个句式：系统 = 业务逻辑 x 数据。能够说不少架构问题都是出在数据层，例如常见的「烟囱式系统」带来的种种问题，特别是数据孤岛问题，其实本质上的缘由就出在没有将数据层打通，若是不从数据架构去思考，就可能「头疼医头、脚疼医脚」，费了半天劲仍是很别扭，反过来若是将数据层治理好，就像打通「任督二脉」同样，起到四两拨千斤的效果。

可是理想一般很丰满，现实却很骨感。至少在咱们五年前出来创业那会儿，咱们以为并无一个系统可以很好的解决数据的问题。可能好奇的读者就要问了：不是有 Hadoop？还有 NoSQL？再不济关系型数据库也能分库分表啊？其实列出的这几个几乎就是当年处理存储问题的所有候选，这几个方案的共同特色就是：不完美。

具体一点来讲，这几个解决方案对于数据应用的场景覆盖其实都不大，对于复杂一点的业务，可能须要同时使用 n 多个方案才能覆盖完整。这就是为何随着近几年互联网业务愈来愈复杂，相似 Kafka 这样的数据 Pipeline 愈来愈流行，从数据治理的角度其实很好理解：各类数据平台各负责各的，为了作到场景的全覆盖，必然须要在各个「岛」之间修路呀。

咱们当年就在想，能不能有一个系统以一个统一的接口尽量大的覆盖到更多场景。

咱们须要一个 Single Source of Truth。数据应该是贯穿在应用逻辑各个角落，我理想中的系统中对于任意数据的存取都应该是能够不加限制的（先不考虑权限和安全，这是另外一个问题），这里的“不加限制”是更广义的，例如：没有容量上限，只要有足够的物理资源，系统能够无限的扩展；没有访问模型限制，咱们能够自由的关联、聚合数据；没有一致性上的限制；运维几乎不须要人工干预……

以分布式数据库为统一中心的架构

我当年特别着迷于一个美剧：Person of Interest （疑犯追踪），这个电视剧里面有一个神同样的人工智能 The Machine，收集一切数据加以分析，从而预测或是干预将来人们的行动。虽然这部美剧仍是比较正统的行侠仗义之类的主题，可是更让我着迷的是，是否咱们能设计一个 The Machine？虽然直到目前我还不是一个 AI 专家，可是给 The Machine 设计一个数据库彷佛是可行的。这几年创业过程当中，咱们发现更使人兴奋的点在于：

以分布式数据库为统一中心的架构是可能的。

这个怎么理解呢？举个例子，就像在上面提到的分裂带来的问题，数据层的割裂必然意味着业务层须要更高的复杂度去弥补，其实不少工程师其实偏向于用线性的思惟去思考维护系统的成本。可是实际的经验告诉咱们，事情并非这样的。一个系统只有一个数据库和有十个数据库的复杂程度其实并非的简单的 10x，考虑到数据的流动，维护成本只多是更多，这里尚未考虑到异构带来的其余问题。

以分布式数据库为中心的架构是什么样子的呢？很好理解，整个架构的中心是一个场景覆盖度足够广，且具备无限的水平伸缩能力的存储系统。大部分数据的流动被限制在这个数据库内部，这样应用层就能够几乎作到无状态，由于这个中心的数据库负责了绝大部分状态，每一个应用能够经过本身的缓存来进行加速。 这里我想提醒的是，为何我在上面强调水平扩展能力，是由于受限的扩展能力也是致使分裂的一个重要的缘由。咱们历来都没有办法准确的预测将来，咱们很难想象甚至是一年后业务的变化（想一想此次疫情），有句老话说的很好：惟一不变的就是变化。

另一个常常被问到的问题，为何要强调缓存层须要离业务层更近，或者说，为何位于中心的这个巨型数据库不该该承担缓存的责任？个人理解是，只有业务更懂业务，知道应该以什么样的策略缓存什么样的数据，并且出于性能（低延迟）考虑，缓存离业务更近也是有道理的。

对应上面那句话「惟一不变的就是变化」，这个架构带来最大的好处正是「以不变应万变」，或者更简单的一个词：简洁。Google 其实在很早就想清楚了这个问题，由于他们很早就明白什么是真正的复杂。

另外一个例子是 HTAP，若是关注的数据库的发展的话，最近必定对 HTAP 这个词很熟悉，其实在我看来的 HTAP 的本质在于上面提到的覆盖度，下面是一个典型的架构：

传统的数据架构一般将 OLTP、OLAP、离线数仓分离，各个系统各司其职，中间经过独立的 Pipeline 进行同步（有时候还会加上 ETL）。 下面是一个 HTAP 的系统的样子：

虽然从表面上看，只是简单的将接口层进行整合，可是这个意义实际上是深远的，首先数据同步的细节被隐藏了一块儿来，这意味着数据库层面能够本身决定经过何种方式同步数据，另外因为 OLTP 引擎和 OLAP 引擎在同一个系统内部，使得不少细节信息不会在同步的过程当中丢失，好比：事务信息，这就意味着在内部的分析引擎可以作到传统的 OLAP 没办法作的事情。另外对于业务层的使用来讲，少一个系统意味着更统一的体验和更小的学习和改形成本，不要低估统一带来的力量。

将来在哪里？

上面这些是过去五年发生的事情，也几乎按照咱们创业时候的设想一步步的变为现实，那么接下来的五年会发什么？随着对于行业和技术的理解的加深，至少有一点我深信不疑的是：

弹性调度会是将来的数据库的核心能力

谁都不会否定，最近十年在 IT 技术上，最大的变革是由云带来的，这场革命还在进行时。云的核心能力是什么？我认为是弹性。计算资源分配的粒度变得愈来愈细，就像从只能买房变成能够租房，甚至能够像住酒店同样灵活。这意味着什么？本质在于咱们能够不用为「想象中」的业务峰值提早支付成本。

过去咱们的采购服务器也好，租赁机柜也好，都是须要设定一个提早量的，当业务峰值没有到来以前，其实这些成本是已经提早支付的了。云的出现将弹性变成了基础设施的一个基础能力，我预计数据库也会发生一样的事情。郑州妇科医院那个好：http://www.xbhnzzyy.com/

可能有不少朋友会有疑问，如今难道不是几乎全部数据库都号称可以支持透明水平扩展嘛？其实这里但愿你们不要将「弹性调度」狭隘的理解为扩展性，并且这个词的重点在「调度」上，我举几个例子以方便你们理解：

1. 数据库能不可以自动识别 workload，根据 workload 进行自动伸缩？例如：预感到峰值即未来临，自动的采购机器，对热数据建立更多副本并重分布数据，提早扩容。在业务高峰过去后，自动回收机器进行缩容。

2. 数据库能不能感知业务特色，根据访问特色决定分布？例如：若是数据带有明显的地理特征（好比，中国的用户大几率在中国访问，美国用户在美国），系统将自动的将数据的地理特征在不一样的数据中心放置。

3. 数据库能不能感知查询的类型和访问频度，从而自动决定不一样类型数据的存储介质？例如：冷数据自动转移到 S3 之类比较便宜的存储，热数据放在高配的闪存上，并且冷热数据的交换彻底是对业务方透明的。

这里提到的一切背后都依赖的是「弹性调度」能力。将来我相信物理资源的成本会持续的下降，计算资源的单价持续降低带来的结果是：当存储成本和计算资源变得不是问题的时候，问题就变成「如何高效的分配资源」。若是将高效分配做为目标的话，「能调度」就是显而易见的基础。 固然就像一切事物发展的客观规律同样，学会跑步以前，先要学会走路，我相信在接下来的一段时间内，咱们会看到第一批初步拥有这样能力的新型数据库，让咱们拭目以待。

下一个阶段是智能

对于更远的将来是怎么样子的？我不知道，可是就像 The Machine 同样，只有足够数据才能诞生出智能，我相信就像咱们不了解宇宙和海洋同样，咱们如今对于数据的认识必定是肤浅的，甚至大量的数据咱们都还没记录下来，必定有更大奥秘隐藏在这海量的数据中，从数据中能获取什么样的洞察，可以怎么样更好的改变咱们的生活，我并不知道，可是作这件事情的主角我猜不会是人类。虽然在这个小节咱们讨论的东西可能就有点像科幻小说了，不过我愿意相信这样的将来，从数据的海洋中诞生出新的智能体。郑州试管婴儿费用：http://jbk.39.net/yiyuanfengcai/tsyl_zztjyy/3100/

尾声

创业这五年的时间，回头看看那个最朴素的出发点：写一个更好的数据库完全解决烦人的 MySQL 分库分表问题。彷佛也算没有偏离初心，可是在这个旅途中一步步看到了更大的世界，也愈来愈有能力和信心将咱们相信的东西变为现实：

我有一个梦想，将来的软件工程师不用再为维护数据库加班熬夜，各类数据相关的问题都将被数据库自动且妥善的处理；

我有一个梦想，将来咱们对数据的处理将再也不碎片化，任何业务系统都可以方便的存储和获取数据；

我有一个梦想，将来的咱们在面临数据的洪流时候，能从容地以不变应万变。

最近我听到一句话，我我的很喜欢：雄心的一半是耐心。构建一个完美的数据库并非一朝一夕的工做，可是我相信咱们正走在正确的道路上。

凡所过往，皆为序章。