十年磨一剑，云原生分布式数据库PolarDBX的核心技术演化

PolarDB-X前身是淘宝内部使用的分库分表中间件TDDL（2007年，Java库的形态），早期以DRDS（2012年开始研发，2014年上线，分库分表中间件+MySQL Proxy的形态）的品牌在阿里云上提供服务，后来（2019年）正式转型为分布式数据库PolarDB-X（正式成为了PolarDB品牌的一员）。从中间件到分布式数据库，我们在以MySQL为存储构建分布式数据库这条路上走了10余年，这中间积累了大量的技术，也走了一些弯路，未来我们也会坚定的走下去。

PolarDB-X的发展过程主要分成了中间件（DRDS）和数据库（PolarDB-X）两个阶段，这两个阶段存在着巨大的差异。笔者参与PolarDB-X的开发恰好刚满十年，全程经历了整个发展过程。今天就和大家唠一唠PolarDB-X发展与转型过程中的一些有意思的事情。

中间件时代（2012～2019）

值得一提的是，DRDS上云的方式放到现在看，也是非常时髦的。

像阿里云的普通用户一样，它也拥有一个阿里云的账号（只不过这个账号有上万亿的授信额度），使用这个账号的AK/SK，调用阿里云各个产品的Open API来进行各种操作。

例如，创建实例时，会购买ECS来进行部署DRDS节点；会购买SLB搭在前面来做负载均衡；会购买SLS服务用来存储该实例的SQL审计；会打通DRDS节点到用户RDS的网络等等。

这种形式的管控架构目前被广泛的运用，充分的利用了云的优势。DRDS几乎不需要关注资源问题，也不需要自己维护库存；像机器宕机这种问题，ECS也能自动的进行迁移（连IP都不会发生变化），非常的便利。让DRDS的研发团队可以将更多的精力放在提升产品本身的能力上。

DRDS一方面为阿里云上的用户提供服务，另一方面也作为阿里云的一个“普通用户”，享受着云技术带来的好处，还是非常有趣的。

在DRDS时期，我们在内核侧重点积累了以下技术能力：

SQL语义上与MySQL的兼容性

TDDL仅服务于内部用户，而淘宝的研发规范相对是比较严格的，应用使用的SQL都是比较简单的类型，所以对SQL的处理是非常少的，简单说，它甚至不需要理解SQL的语义，仅做转发即可。但云上用户的需求五花八门，又存在大量迁移上云的存量应用，对SQL兼容性要求变高了很多。这就要求我们要提供一个完整的SQL引擎。

DRDS相对于TDDL以及市面上一众的分库分表中间件，多了两个关键组件：具备完整的算子体系的查询优化器与执行器。它的目标是无论SQL有多复杂，都要能够正确理解其语义，并执行出正确的结果。

这里有非常多需要长期积累的工作。举几个例子：

• 任何一个MySQL支持的内建函数，都有可能是基于一个不能下推的结果进行计算的，这就要求DRDS需要支持所有MySQL的内建函数，并且目标与MySQL的行为一致。我们在DRDS内实现了几乎所有的这些函数（https://github.com/ApsaraDB/galaxysql/tree/main/polardbx-optimizer/src/main/java/com/alibaba/polardbx/optimizer/core/function）。早期我们有两位同学花了数年时间来做这件事情，并且打磨至今。
• MySQL中支持大量的charset与collation，不同的组合会带来不同的排序结果。如果我们要使用归并排序的算子对MySQL层已经局部有序的结果进行归并，则需要确保DRDS使用与MySQL一致的排序行为。实际上这里要求DRDS支持与MySQL行为一致的charset与collation系统，例如我们实现的utf8mb4_general_ci：https://github.com/ApsaraDB/galaxysql/blob/main/polardbx-common/src/main/java/com/alibaba/polardbx/common/collation/Utf8mb4GeneralCiCollationHandler.java。

的下推优化

将计算下推到与数据近的地方，这是保证性能的一个朴素的原则。

将MySQL作为一个分布式数据库的存储引擎，它实际上本身也具备很强的计算能力。特别相对于目前很多使用KV来作为存储引擎的分布式数据库，它们大多只能做到Filter、函数的下推执行。但MySQL却支持完整的SQL执行，将分片级的JOIN、子查询、聚合等操作尽可能多的下推到MySQL上，是DRDS保证高性能的一个关键。

下表简单对比业界产品的一些优化选择，信息来自公开文档：

坎坷的分布式事务

分布式事务，是绕不开的一个问题。

对于中间件类型的产品来说，我们有一个很基本的假设：使用标准的MySQL，避免对MySQL做侵入性的修改；即使修改，也应该是插件化的。

不修改MySQL，这导致我们很长一段时间都没有很好的实现分布式事务。

我们前前后后走过的一些弯路：

事务系统是一个与存储层密切相关的事情，从PolarDB-X的探索来看，不对MySQL做深度修改，是不可能做出性能、功能都符合要求的分布式事务的。这是所有中间件类产品都无法解决的问题，也是中间件与数据库根本性的差异。

绕不开的分区键

从DRDS的个用户开始，就一直要回答一个问题，我的表怎么选分区键？

从做“高吞吐”、“高并发”的业务系统角度来看，要求表和SQL带上有业务特征的分区键是非常合理的一件事情。全部下推到存储层，避免产生跨机的查询、事务，做到这些才能保证做到佳的性能，这是性能的天花板。

问题是，虽然这样做上限很高（高到淘宝双十一0点的业务高峰也可以很丝滑），但：

自然，我们想知道，什么样的技术，才能让你“忘掉”分区键这个东西呢。

数据库时代（2019～）

透明分布式之路

广义的“分区键”的概念，其实并不是分布式数据库特有的。

我们在单机数据库中，例如MySQL中，数据存储成了一棵一棵B树。如果一个表只有主键，那它只有一棵B树，例如：

CREATE TABLE t1( id INT, name CHAR(32), addr TEXT, PRIMARY KEY (id) )