褚霸：我对MySQL数据库架构的演化观察

哪些数据库是 2019 年的“大势”？

在 DeveloperWeek 上做的一个调研结果显示，数百名开发人员、工程师、软件架构师、开发团队和 IT 领导者的反馈了解到，MySQL 以 38.9% 的使用率高居榜首，其后依次是 MongoDB（24.6%）、PostgreSQL（17.4%）、Redis（8.4%）和 Cassandra（3.0%）。随着 MySQL 数据库使用越来越重度，流行度越来越高，同时伴随着使用场景的丰富、云化的普及和智能化的发展，对原本为单机设计的 MySQL 带来了很多架构上的挑战，包括：性能、成本、安全、容灾，高可用、合规、规模运营等方面，在诸多过去设计层面不被重视的问题。

褚霸老师在此前的一次演讲中，从架构演化角度分析了现有 MySQL 技术和产品的变化趋势和解决实践。（以下为演讲实录） 

大概是 22 年前，我开始第一次接触 MySQL，最近 8 年一直在做 MySQL 相关的研发和业务，除了 MySQL 相关的技术以外，我对底层系统和架构研发都比较感兴趣。

本次主要讨论以下三个点：

1、MySQL 架构演进的动力是什么，是什么让 MySQL 从一个很小的软件，变成现在世界上最流行的数据库软件?

2、架构是怎么一步步过来的，过去架构的演变逻辑是什么，未来大概率可能往哪个方向发展？

3、MySQL 是一个开源软件，其发展是离不开社区，社区对于这些架构的演进需要做什么贡献？

从用户需求角度看，用户需要什么样的 MySQL 可以推演到需要什么样的架构。用户需求非常朴素，因为数据库是生产要素，所以需要购买数据库，它是一个消费品，合理的成本是用户关注点之一。然后去请 DBA 人员，成本很高，类似这种的费用是不是省掉，但是必须有一些业务的延续性。因为数据库在整个架构体系里通常在最下面，数据库的演变对架构的演变影响非常大，能不能满足未来的需求，长期的需求，是非常重要的考量。

因为现在的业务发展非常快，很多公司都在跨界，业务在不停地试错，此种大背景下，对数据库需求面非常广。而站在老板的角度看是不希望五花八门，最好有一个数据库，能满足所有的需求，如果不能的话，最多加一个。老板有权利决策用什么数据库，或者用多大规模，怎么样去用，这些都会影响今天的业务和架构。

今天的数据库一定是一揽子解决方案，而不是装个 MySQL 或者数参就好了它是有场景化的，银行和政府的场景不一样，数据库类型也不一样。像阿里的双十一的场景完全不一样，倾向性完全不一样。所以，这种情况下，需要为每个场景定制一个解决方案。

当然，如果不差钱情况下买最好的，而对于生产要素而言，基本上会在可靠性和性能之间寻求平衡，平衡很重要。我个人觉得稳定性是第一位的，能够达到业务连续。我做云也做了四五年，我感触最深的是稳定压倒一切，所有东西离开稳定都没有意义。如果很大一个业务数据库不可用，整个业务瘫痪了好几个小时，这个事件造成的损失可能远超你的投资。所以，稳定性是架构设计里非常重要的一环。

另外一个比较重要的是尊重用户熟悉的姿势，社区里有大量的 MySQL 产品，都号称和 MySQL 兼容，但都不是 100% 兼容，这会造成非常大的困扰，我在兼容性上体会特别深，哪怕 99.99999，那个 1 不兼容的话整个业务系统也上不去，因为很多用户系统已经是一个遗留系统，源代码都不见了，你让他改一行不可能。所有的系统改动都有风险，所以没人愿意改。能够兼容用户原来的习惯非常重要，这个是很多人忽略的事情。我们架构设计里保持兼容，保持原生非常重要。

可能要证明一件事情，作为一个通用平台，通用数据，如果用户用错了，必定会把锅甩给你，这种情况下怎么证明不是我的错，大家一起解决问题，这也是架构设计里的重要一环。根据我自己的经验，若要做一个能够自证清白的系统，相关的代码会占整个系统代码的 30%。所以整个自证清白能力，在系统架构设计里非常重要。

在做云计算之前对数据库理解为两方面，一是成本，二是性能。之前做性能调优，成本就很好理解，老板每天强调，今年要降 20%，明年要降 20%，这是对系统最直观的感受。

但现在完全不一样，这些关键词都是非常重要的，缺一不可，比如说数据可靠性，在大规模数据场景，数据的可靠性就相当于在一大缸清水里滴一滴墨水，数据污染整个水都要倒掉。系统设计不会没有 Bug，但是在运维过程中可以去控制。数据如果不可靠，可能会影响产品声誉。

比如在银行场景，合规是非常重要的事情，要求所有的数据链路是加密的，而且是高强度的加密，所有的磁盘落地数据是加密的，在数据的复制、传运过程中，数据都是需要保证是不被破解的。它是一个前链路的事情，候补是很难的，比如存储加密，所有环节都要加密，牵一发动全身。

关于业务平滑，过去在用 MySQL 的时候，认为性能是随着缓存的提升而提升的。这样的决策对用户影响非常大，MySQL 如此流行的很重要一个原因在于，MySQL 是一个非常朴素的数据库，它的性能不高也不低，适用于很多业务场景，性能可预期，容量可预期，易于规划。

业务的需求对架构会有影响，架构演化必须有动力。过去十年二十年里，云化的普及对架构非常重要，十年前大家对云的理解各不相同，今天大家说云几乎都一样。云最重要的几个部分：计算、存储、网络、数据库，所有云厂商必须有这四样。国家推动云化的普及使其快速成为基础设施，对数据库的需求也推动了数据库技术的发展。

其次，类似大数据、AI 和 IOT 会带来很多机会，推动大数据库发展。从 T 级别到 P 级别，如果软件行业超过一两个数量级的架构系统，会带来翻天覆地的变化。

最后，是硬件的迭代，现在一个比较主流的机器配置，从 CPU(128 核)，再到网络 (10 us 级别)，I/O(10us 级别)，其次是超大内存 (T 级别)，最后到 NvRAM。硬件上的迭代对业务的保障非常足够了。

内存变化非常快，基础软件变化也非常快，推动架构演化的动力大概分为这几个：         

在学校学数据结构，整个算法是围绕数据转。而今天企业架构图里，基本上是业务围绕数据库转。MySQL 在 DBRanking 排名第二，在业务架构里举足轻重，而且它是一个通用数据库。导致今天围绕 MySQL 变化会非常大，第一个最大的变化就是层次化，每层都可插拔，它加了一个插件层，由此社区有各种各样的插件，数据分层非常重要，它为用户提供了一种选择。其次，数据分层和 SLA 有很大关系，MySQL 有五种产品形态，一种叫单结点，专门对成本优化的；一个双结点的，正常的主备结构；三结点的，针对金融版高可用的场景优化；还有分布式版，数据可以很好的扩展；共享存储版，延迟特别小，性能特别好。最明显的变化是引擎，有了这些分层以后，不同的组织、不同地区，很多工作可以并发执行。

MySQL 最早是一个通用引擎，性能很难达到极致，金融场景下要找一批人针对金融场景去优化，通用和专用成了可能。成本优先或者性能优先都可选，因为分层了。

数据库的组成其实是一个 SQL+ 存储 + 计算，因为有了 SQL，标准接口使用非常方便，数据库本身是个存储，再加上计算，它是一个资源消耗和智力密集型的软件。在演化路径里，主路径很重要一点，如果不能解决一个容量扩展、安全等问题，整个数据库适用面非常小，特别是实时场景，比如分析，很多场景下用户要求秒级同步，或者最多一两分钟级别，这边把数据写进去，那边一分钟读出来，如果不是共享存储，很难做。

数据互通也是必须的能力，就像 Oracle 可以读取存在 AWS 里的表一样。可靠性非常重要，在实践中去运行一个大集群，做了很多的备份和很多冗余设计，可最后还是出问题，因为整个系统是同构的，如果有 Bug，整个体系都有问题，虽然有备份，但是数据拿不出来，因为有 Bug。所以采用异构系统做冗余，两套系统由两波人设计的，完全不一样，能够保证数据的可靠性。

混合计算层面，混合计算非常受关注，也是一种趋势，在保证性能的前提下，把数据存储和数据分析集成到一个系统。

实时化能力，当 MySQL 解决了最基本的问题，会走到下一个阶段，实时化是一个很大的方向。在 SQL 层面，为了更好的解决扩缩容，必须有中间层，包括读写分离，负载均衡，都在中间层。

像运维和支撑系统，有大量的数据需要在 PostgreSQL 和 MySQL 之间互通，如搜索互通，要把 MySQL 数据导到 Elasticsearch 即可搜索，经过 API 这一过程，但如果将用户 SQL 搜索拦截掉，利用中间件的辅助，直接把结果反馈给用户即可，类似这样一个异构系统互通非常关键。另外是服务，Oracle 之前推出自调整的数据库，这是一个大方向。另外一个重点是智能诊断功能，可以替代 DBA 的工作，能提升大规模系统的服务能力。整体来看，从底层引擎到服务层面的演化，MySQL 在其中扮演了关键角色。

架构演变其实是一个突破的过程，最难的点在于计算和存储分离，如果计算和存储不分离，那么既要考虑机器，又要考虑 CPU、内存、I/O、网络，每一部分都会直接影响整体性能。但如果能拆开就很好办了，计算部分只考虑 CPU 加内存，存储部分只要考虑 I/O 加网络，计算和存储靠网络连接，而网络是最大的瓶颈，所有的研究都是围绕怎么去减少网络的瓶颈。第一要提高网络的速度和带宽，可以享受硬件红利。第二是软件红利，比如 Oracle 数据库整个设计理念，着重去减少在网络上的交互次数。如果要交互，加大信息密度；如果在软件层面上，能把这个事情优化好，今天对网络依赖会小很多。现在大部分 MySQL 部署都是多个结点，多个机房，可以利用多机房的并行度解决网络问题，网络问题解决了，架构突破势在必得。

架构突破上还有一点，以前 MySQL 是单机系统，单机有 SQL、事务、Cache、存储，怎么把这 4 件一样一样拆出来？最重要的就是 offload，数据核心逻辑下沉到存储，利用集群分布和闲时资源细水长流计算。接下来是提高效率的问题，拆分完之后用机器资源去分解任务，例如用 FPGA、ASIC，或者盘载计算资源。

另外一个突破就是解决数据副本、数据变形、Schema 演化即刻计算的代价到来。而解决高并发、高扩展（毛刺和突发）是比较困难，如阿里双十一场景，很短时间内储备了几乎全世界的资源，但过几分钟后就不需要了，架构层面怎么去解决？

解决隔离问题，预先分配存储颗粒级别，保证业务的平滑、设备、存储、引擎、事务、SQL、虚拟化整链条互不干扰

解决能力扩展问题:

• 计算能力：一主多读 → 读写分离 → Multi Master

• 存储能力：提高引擎存储效率（新数据结构，压缩）→ 共享存储 → 引擎逻辑下沉的共享存储

解决 SaaS 化二次多租户问题

衡量指标：

• 架构保证业务平滑

• 秒开秒关，秒扩秒缩，数据保持温热（只有做到这样，才称之为有弹性，高级阶段）规模化带来的挑战

之前没有过多考虑，也没有提前容量规划去应对临时的需求，比如微博热点事件，如果热点开始的那一分钟能把资源扩充到位，能省很多钱。另外是辅助运营，比如像 Advisor/CloudDBA 系统，发现业务没做起来，可以把中等规格的实例降成小规格，节省成本。时光回溯的系统也非常关键，用户的每条 SQL 经过的网络，消耗的 I/O 数据都有记录，便于用户查询解决问题。

• 商业驱动技术变化

• 数据库厂商版权收紧推迟开源

• Cloud Native 设计理念、混合云趋势化

技术社区的变化，对整个 MySQL 的架构影响很大，商业驱动技术的变化，过去做系统的时候没有非常明确的商业目标，现在整个社区有非常明确的商业目标，所有做的项目都是贴着钱去做的。今天很多数据库的热度很高，流行的业务发展起来，相应的数据库就出来了，今天的数据迭代会更快、更敏感。

另外是，数据库厂商版权收紧，过去 GPL 改成 AGPL，会推迟开源，对社区变化很大。同时也带来一个好处，商业的产品会越做越好。现在我们在做数据库的时候，我们是根据云的整个基础设施设计，今天不可能再出现在单机上分层结构，它是新的设计理念，对未来的影响深远，对未来的架构有很大的影响。

        褚霸（余锋）阿里巴巴研究员

余锋在阿里巴巴担任研究员职位，从 2013 年起负责阿里云数据库业务，覆盖全球市场的公有云和专有云。作为资深工程师在中间件、数据库、存储系统和硬件等技术领域都有突出的造诣，有超过 20 年的系统软件编码功底和丰富的大规模复杂集群系统的构建和演进经验。

业务场景不一样，所以对于数据库的需求也不同，7 月 12 日深圳 ArchSummit 架构师峰会邀请了业界典型的公司来分享在公司内支撑了庞大业务量的数据库、数据存储方面的研究成果。包括阿里基于 NoSQL 的下一代大规模高速存储系统 TAIR 的设计实践，以及鹏云网络高性能的软件定义存储系统的架构设计话题。报名可以联系票务灰灰：17326843116