关于数据库:十年磨一剑云原生分布式数据库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 期间的倒退思路其实很简略，满足用户的几个次要诉求：

1. 阿里云上提供的 RDS MySQL 单实例最大存储空间有限度（例如晚期只有 2T）
2. Share Storage 的数据库能够解决磁盘容量问题，但仍然受到单机 CPU\ 内存的限度，无奈解决写扩展性的问题
3. 应用开源中间件能解决上述问题，但做扩容等运维操作非常的麻烦简单

在这样的背景下，咱们在中间件 TDDL 之上减少了一个 MySQL Proxy（实际上是 Cobar 的网络层），部署在了阿里云上，便成为了最早的 DRDS。

上云的开始 – 应用云也服务云

值得一提的是，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/g…）。晚期咱们有两位同学花了数年工夫来做这件事件，并且打磨至今。
• MySQL 中反对大量的 charset 与 collation，不同的组合会带来不同的排序后果。如果咱们要应用归并排序的算子对 MySQL 层曾经部分有序的后果进行归并，则须要确保 DRDS 应用与 MySQL 统一的排序行为。实际上这里要求 DRDS 反对与 MySQL 行为统一的 charset 与 collation 零碎，例如咱们实现的 utf8mb4_general_ci：https://github.com/ApsaraDB/g…。

相似这样的工作还有很多，例如类型零碎（https://zhuanlan.zhihu.com/p/…）、sql_mode、时区零碎、默认值等等，繁琐但必要。这些工作都很好的连续到了 PolarDB- X 中。

极致的下推优化

将计算下推到与数据最近的中央，这是保障性能的一个最奢侈的准则。

将 MySQL 作为一个分布式数据库的存储引擎，它实际上自身也具备很强的计算能力。特地绝对于目前很多应用 KV 来作为存储引擎的分布式数据库，它们大多只能做到 Filter、函数的下推执行。但 MySQL 却反对残缺的 SQL 执行，将分片级的 JOIN、子查问、聚合等操作尽可能多的下推到 MySQL 上，是 DRDS 保障高性能的一个要害。

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

推多了会导致后果谬误，推少了会达不到最佳性能。DRDS 的优化器积攒了大量下推优化策略。这些优化策略大多是没有方法凭空想象进去的，只有通过理论的场景案例，能力失去积攒。详见：https://zhuanlan.zhihu.com/p/…。

物理算子的丰盛与 MPP 的执行引擎

物理算子也就是指执行器的各种算法，例如对于 Join，咱们反对 HybridHashJoin、LookupJoin、NestedLoopJoin、SortMergeJoin、MaterializedSemiJoin 等等算法。

DRDS 最后仅反对单线程去执行 SQL，但这种执行对简单的 SQL 是不够用的。咱们先做了单机并行引擎（SMP），又倒退到了当初的 MPP 引擎，详见：https://zhuanlan.zhihu.com/p/346320114。

同时，执行引擎还反对 spill out（两头后果落盘的能力），即便只有 15M 内存，也能跑通 TPCH 1G 的测试，详见：https://zhuanlan.zhihu.com/p/363435372。

这些能力的积攒与冲破，极大的晋升了 PolarDB- X 在面对简单的 SQL 的计算能力。

崎岖的分布式事务

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

对于中间件类型的产品来说，咱们有一个很根本的假如：应用规范的 MySQL，防止对 MySQL 做侵入性的批改；即便批改，也应该是插件化的。

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

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

1. 像传统中间件一样，禁止分布式事务。但这个对利用的革新老本太高了。
2. 应用柔性事务，很长一段时间咱们应用 GTS（原名 TXC）这样的第三方组件来实现分布式事务。这种计划须要对不同的 SQL 依据语义来实现回滚语句，SQL 兼容性很差。
3. 应用 GTM 的计划。GTM 实质是一个单点，并且 GTM 与 Coordinator 之间要做大量的数据交互，性能太差，不可能作为一个默认应用的事务策略。所以咱们看应用 GTM 计划的“数据库”，它肯定有很严苛的应用条件（例如要求利用尽量避免分布式事务、默认敞开强统一等）。
4. XA 事务，晚期的 MySQL 对 XA 反对的很弱，BUG 很多（实际上当初的 MySQL 对于 XA 的 BUG 仍然很多），例如宕机复原流程很容易因为 XA 挂掉。并且 XA 事务无奈解决读的可见性问题，与单机事务的行为不兼容。

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

绕不开的分区键

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

从做“高吞吐”、“高并发”的业务零碎角度来看，要求表和 SQL 带上有业务特色的分区键是十分正当的一件事件。全副下推到存储层，防止产生跨机的查问、事务，做到这些能力保障做到最佳的性能，这是性能的天花板。

问题是，尽管这样做下限很高（高到淘宝双十一 0 点的业务顶峰也能够很丝滑），但：

1. 这种革新老本是十分高的，很多时候分区键是很难选的。例如很多电商零碎的订单表会有两个查问维度，卖家和买家，选哪个当分区键。
2. 不是所有的业务零碎（或者说不是所有的表和 SQL）都值得花这么大的代价去革新的，只有外围零碎中的外围逻辑才须要做这种粗疏的革新。
3. 拆分键选错了，会导致上限极低。对于数据库来说，提供比拟高的下限和提供不太低的上限同样重要。

天然，咱们想晓得，什么样的技术，能力让你“忘掉”分区键这个货色呢。

数据库时代（2019～）

通明分布式之路

是否须要强制利用在意分区键的概念，是中间件与数据库的关键性区别之一。

分区键与全局索引

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

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

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

这个表惟一的 B 树是依照主键（id）进行排序的。如果咱们的查问条件中带了 id 的等值条件例如 where id=14，那么就能够在这棵树上疾速的定位到这个 id 对应的记录在哪里；反之，则要进行全表扫描。

B 树用于排序的 Key，通过二分查找能够定位到一个叶子节点；分区键通过哈希或者 Range 上的二分查找，能够定位到一个分片。能够看出它们都是为了能疾速的定位到数据。

如果咱们要对下面的表做 where name=’Megan’ 来查问，在 MySQL 中，咱们并不需要将 name 设为主键。更加天然的形式是，在 name 上创立一个二级索引：

CREATE INDEX idx ON t1(name)

每个二级索引在 MySQL 中都是一棵独立的 B Tree，其用于排序的 Key 就是二级索引的列。也就是说，以后 t1 这张表，有两颗 B Tree 了，主键一棵，idx 一棵，别离是：

id->name,addrname->id

当应用 where name=’Megan’ 进行查问是，会先拜访 idx 这颗 B 树，依据 name=’Megan’ 定位到叶子节点，获取到 id 的值，再应用 id 的值到主键那颗 B 树上，找到残缺的记录。

二级索引实际上是通过冗余数据，应用空间与晋升写入的老本，换取了查问的性能。

同时，二级索引的保护代价并不是十分的高，个别状况下能够释怀的在一个表上创立若干个二级索引。

同理，在分布式数据库中，想让你“忘掉”分区键这个货色，惟一的办法就是应用分布式二级索引，也称为全局索引（Global Index）。并且这个全局索引须要做到高效、便宜、与传统二级索引的兼容度高。

全局二级索引同样也是一种数据冗余。例如，当执行一条 SQL：INSERT INTO t1 (id,name,addr) VALUES (1,”meng”,”hz”);

如果 orders 表上有 seller_id 这个全局二级索引，能够简略了解为，咱们会别离往主键与 seller_id 两个全局索引中执行这个 insert，一共写入两条记录：

INSERT INTO t1 (id,name,addr) VALUES (1,”meng”,”hz”);INSERT INTO idx (id,name) VALUES (1,”meng”);

其中 t1 主键索引的分区键是 id，idx 的分区键是 name。

同时，因为这两条记录大概率不会在一个 DN 上，为了保障这两条记录的一致性，咱们须要把这两次写入封装到一个分布式事务内（这与单机数据库中，二级索引通过单机事务来写入是相似的）。

当咱们所有的 DML 操作都通过分布式事务来对全局索引进行保护，二级索引和主键索引就可能始终保持一致的状态了。

如同全局索引听起来也很简略？实则不然。

全局索引与分布式事务

索引肯定要是强统一的，例如：

• 不能写索引表失败了，然而写主表胜利了，导致索引表中缺数据
• 同一时刻去读索引表与主表，看到的记录应该是一样的，不能读到一边已提交，一边未提交的后果
• …

这里对索引的一致性要求，实际上就是对分布式事务的要求。

因为全局索引的引入，100% 的事务都会是分布式事务，对分布式事务的要求和“强依赖分区键类型的分布式数据库”齐全不同了，要求变得更高：

• 至多须要做到 SNAPSHOT ISOLATION 以上的隔离级别，不然行为和单机 MySQL 差别会很大，会有十分大的数据一致性危险。目前常见的计划是 HLC、TrueTime、TSO、GTM 计划，如果某数据库没有应用这些技术，则须要认真甄别。
• 100% 的分布式事务相比 TPCC 模型 10% 的分布式事务，对性能的要求更高，HLC、TSO、TrueTime 计划都能做到比拟大的事务容量，相对而言，GTM 因为更重，其下限要远远低于同为单点计划的 TSO（TSO 尽管是单点，但因为有 Grouping 的优化，容量能够做的很大）。
• 即应用了 TSO/HLC 等计划，优化也要到位，例如典型的 1PC、Async Commit 等优化。不然保护索引减少的响应工夫会很难承受。

与单机索引的兼容性

此外，单机数据库中，索引有一些看起来十分天然的行为，也是须要去兼容的。

例如：

• 能通过 DDL 语句间接创立索引，而不是须要各种各样的周边工具来实现。
• 前缀查问，单机数据库中，索引是能够很好的反对前缀查问的，全局索引应该如何去解这类问题？
• 热点问题（Big Key 问题），单机数据库中，如果一个索引抉择度不高（例如在性别上创立了索引），除了略微有些浪费资源外，不会有什么太重大的问题；然而对于分布式数据库，这个抉择度低的索引会变成一个热点，导致整个集群的局部热点节点成为整个零碎的瓶颈。全局索引须要有相应的办法去解决此类问题。

索引的创立速度，索引回表的性能，索引的性能上的限度，聚簇索引，索引的存储老本等等，其实也都极大的影响了全局索引的应用体验，这里鉴于篇幅起因，就不持续开展了。

索引的数量

对全局索引的这些要求，实质来源于全局索引的数量。

透明性做的好的数据库，所有索引都会是全局索引，其全局索引的数量会十分的多（正如单机数据库中一个表一个库的二级索引数量一样）。数量多了，要求才会变高。

而，这些没有全做好的分布式数据库，即便有全局索引，你会发现它们给出的用法仍然会是强依赖分区键的用法。

它们会让创立全局索引这件事，变成一个可选的、特地的事件。这样业务在应用全局索引的时候会变的十分谨慎。天然，全局索引的数量会变成的十分无限。

当全局索引的数量与应用场景被严格限度之后，上述做的不好的毛病也就变得没那么重要了。

面向索引抉择的查问优化器

咱们晓得，数据库的优化器外围工作机制在于：

1. 枚举可能的执行打算
2. 找到这些执行打算中代价最低的

例如一个 SQL 中波及三张表，在只思考左深树的状况下：

• 在没有全局索引的时候，能够简略了解为，执行打算的空间次要体现在这三张表的 JOIN 的程序，其空间大小大抵为 3x2x1=6。执行打算的空间绝对是较小的，优化器判断这 6 个执行打算的代价也会容易很多。（当然优化器还有很多工作，例如分区裁剪等等，这些优化有没有索引都要做，就不多说了）。
• 在有全局索引的时候，状况就简单多了。假如每个表都有 3 个全局索引，那执行打算空间的大小大抵会变成 (3×3)x(2×3)x(1×3)=162，这个复杂度会急剧的回升。相应的，对优化器的要求就会高的多。优化器须要思考更多的统计信息，能力抉择出更优的执行打算；须要做更多的剪枝，能力在更短的工夫内实现查问优化。

所以咱们能够看到，在没有全局索引的“分布式数据库”或者一些中间件产品中，其优化器是很羸弱的，大多是 RBO 的，它们基本就不须要一个弱小的优化器，更多的优化内容实际上被单机优化器给代替了。

PolarDB- X 提供了应用代价模型的优化器：https://zhuanlan.zhihu.com/p/370372242。

在 MySQL 上实现强统一、高性能的分布式事务

为了做一个通明的分布式数据库，最要害的就是全局索引以及全局索引依赖的分布式事务了。中间件时代的摸索曾经通知咱们，要做强统一、高性能的分布式事务，肯定要对存储（MySQL）做深度的批改。

咱们抉择的是应用全局 MVCC（TSO）+2PC（XA）的计划。

MySQL 的单机 MVCC 中蕴含了 start_timestamp（也就是 MySQL 中的 trx_id），为了实现全局 MVCC，须要做几件外围的事件：

• 提供一个全局的工夫戳生成器 TSO，https://zhuanlan.zhihu.com/p/360160666。
• 应用 TSO 生成的全局工夫戳替换掉单机生成的 trx_id。
• 引入 commit_timestamp（同样由 TSO 生成），应用 strat_timestamp 与 commit_timestamp 来进行可见性的判断，十分的高效。

https://zhuanlan.zhihu.com/p/355413022。不应用在节点之间替换沉闷事物链表或者 GTM 这种代价十分大的计划。

PolarDB- X 中的事务流程：

InnoDB 中的记录格局的批改，咱们称之为 Lizard 事务零碎，详见：https://developer.aliyun.com/article/795058

咱们还有其余一些文章来介绍 PolarDB- X 分布式事务的实现：

• PolarDB-X 强统一分布式事务原理（https://zhuanlan.zhihu.com/p/329978215）
• PolarDB-X 分布式事务的实现（一）（https://zhuanlan.zhihu.com/p/338535541）

有了分布式事务与全局索引后，PolarDB- X 正式从中间件转型成了一个分布式数据库。

PolarDB- X 的通明分布式

PolarDB- X 实现了十分优良的分布式事务与全局索引，满足上文提到了对全局索引的要求，做到了通明分布式。

在通明分布式模式下（CREATE DATABASE 中指定 mode=’auto’），所有的索引都是全局索引，利用无需关怀分区键的概念。

例如，咱们的建表语句，与单机 MySQL 完全一致，并不需要指定分区键：

create table orders (id bigint, buyer_id varchar(128) comment ‘ 买家 ’, seller_id varchar(128) comment ‘ 卖家 ’, primary key(id),index sdx(seller_id),index bdx(buyer_id))

创立全局索引也与单机 MySQL 创立二级索引的体验统一，全程是 Online 的：

CREATE INDEX idx_seller_id ON orders (seller_id);

PolarDB- X 的全局索引是强统一的，其数据一致性体验与单机 MySQL 没有显著差别，提供了合乎 MySQL 语义的 RC 与 RR 的隔离级别。

同时，PolarDB- X 在索引的保护、优化器上也做了大量的工作，确保索引能高效的创立、保护，优化器能正确的生成应用索引的执行打算。

PolarDB- X 的分区算法，也能很好的解决索引中产生的热点、数据歪斜等问题，参考：https://zhuanlan.zhihu.com/p/424174858

主动（通明）决定上限，手动决定下限

按通明与手动来划分市面上常见的分布式数据库：

• 通明的分布式数据库的典型代表：TiDB、CockroachDB。
• 手动的分布式数据库典型代表：OceanBase、YugabyteDB。

是否通明的分布式数据肯定比手动的要好呢？

对于只提供通明用法的数据库，迁徙老本会比拟低，初步体验会比拟好。但进入深水区后，因为不可避免的会大量的应用分布式事务，在外围场景中，性能往往是达不到要求的（或者同样的性能须要更高的老本），并且短少打消分布式事务、更充沛的计算下推等优化伎俩。

对于只提供手动用法的数据库，尽管设计良好的分区键使得实践上可能做到性能最优，但应用门槛会大幅减少（10% 外围表设计分区键也就算了，剩下的 90% 非核心表也要设计分区键）。

咱们认为，无论是纯通明还是纯手动的分布式数据库，都无奈很好的满足业务对是用老本和性能兼顾的要求。

PolarDB- X 除了提供了通明模式，也残缺的反对了分区表的语法，并提供了 Join Group/Table Group、分区在线变更等工具，让利用在须要极致性能的状况下，能将事务、计算更多的下推到存储节点。

PolarDB- X 是市面上惟一可能做到同时提供通明与手动两种模式的分布式数据库，咱们举荐大多场景应用通明模式，之后对外围业务场景进行压测，并应用分区表语法对这些场景做手动的优化，以达到最高的性能。

应用 Paxos 协定做到 RPO=0

中间件对接的 MySQL 广泛应用主备架构，这种形式最大的问题就是会丢数据，甚至工夫长了是一个必然的事件（常在河边走，哪能不湿鞋呢）。

通过数据库圈子这几年的科普，根本大家都晓得了须要应用一些一致性协定，例如 Paxos 和 Raft 能力做到不丢数据。这些协定实际上并不是什么机密了，甚至数据库圈子都有一个段子“当初校招的学生都要能手撸 Paxos 了”。

门槛并不在协定自身上，而在于如何与 MySQL 联合后的稳定性与性能。稳定性，只有通过大规模的验证，踩过足够多的坑，能力取得。

PolarDB- X 所应用的的 Paxos 协定是源于阿里外部的 X -Paxos，能够这样说，阿里外部的 MySQL 数据库，曾经不存在主备模式了，100% 的应用 X -Paxos。这代表它经验了上万个 MySQL 集群以及各种大促的验证，具备极高的可靠性。

咱们有几篇文章想写介绍 X -Paxos：

• PolarDB-X 一致性共识协定 —— X-Paxos：https://zhuanlan.zhihu.com/p/302845832
• PolarDB-X 存储架构之“基于 Paxos 的最佳生产实践”：https://zhuanlan.zhihu.com/p/315596644

齐全兼容 MySQL 的 Binlog 协定

要利用 MySQL 生态的资源，十分重要的一点是可能应用 MySQL 生态的工具，将数据流向上游。业内常见的计划里：

• 中间件类产品，须要用户去订阅每个 MySQL 的 Binlog，由用户自行解决这两头的各种运维问题（例如 DDL 问题，不同的分表名要做合并等），十分的繁琐。
• 分布式数据库类产品，这些大多提供本人的 CDC 能力，例如 OceanBase、TiDB，但他们的格局并非 MySQL 的 Binlog 格局，无奈间接应用 MySQL 生态。

PolarDB- X 是市面上惟一一个提供齐全兼容 MySQL Binlog 协定的分布式数据库，用户能够应用任何开源的 MySQL Binlog 订阅、解析工具（例如 Canal）来对接 PolarDB- X 的 Binlog。

这极大的晋升了 PolarDB- X 的易用性。详见：

• PolarDB-X 如何兼容 MySQL Binlog 协定和参数：https://zhuanlan.zhihu.com/p/512114589
• PolarDB-X 全局 Binlog 解读：https://zhuanlan.zhihu.com/p/369115822

下一个五年

咱们对将来的 PolarDB- X 充斥设想，心愿她能变成一个更好的数据库。尽管有很多的不确定性，不过有一些事件是咱们会继续去做的。

最重要的，咱们会保持在 MySQL 生态上，并且保持在基于 MySQL 作为存储节点构建分布式数据库这条技术路线上。咱们认为这是咱们绝对于其余分布式数据库的一个十分要害的差别。与 MySQL 的兼容其实分为性能兼容与性能兼容，应用分布式 KV 等技术计划，兴许能在性能上兼容 MySQL，然而很难做到与 MySQL 性能上的兼容。MySQL 是一个具备全功能的存储，将大量的事务与计算下推到存储节点，是分布式数据库做到高性能的要害。

业内提供全局索引的分布式数据库，全局索引的性能（写入和查问）与单机数据库中索引的性能和行为广泛都有肯定的差距，放大这个差距，便能晋升分布式数据库的上限。对于 PolarDB- X 来说，这个差距次要来自于 CN 与 DN（MySQL）之间的交互链路过长，有很多冗余的操作（MySQL Server 层的线程连贯模型、MySQL 优化器、Parser 等）。咱们会通过应用 RPC 协定与 MySQL 进行交互、做薄 MySQL Server 层等形式来进一步晋升 PolarDB- X 全局索引的性能。

主动的负载平衡可能极大的升高分布式数据库的应用门槛，PolarDB- X 的一些个性（手动与主动兼顾、Join 可能下推等），使得这件事件绝对于不反对这些个性的数据库有一些额定的难度（一把泪，但咱们能够解决），这块还须要一些工夫进行打磨。

降本增效是这两年比拟火的一个话题，PolarDB- X 行将 OSS 归档的能力，可能主动的将历史数据转储到 OSS 上，并能通过和在线数据一样的 SQL 接口进行拜访，也反对应用 Spark 等开源大数据工具对转储的 OSS 文件间接进行剖析等操作。详见：https://zhuanlan.zhihu.com/p/477664175。

HTAP 是分布式数据库畛域比拟热门的主题，各数据库厂商提出了各种各样的计划。但从现有的 HTAP 实现来看，性能、隔离性、老本三者处于一种比拟矛盾的状态（有些数据库会应用列存正本，性能 OK，但很贵；有些数据库在 HA 应用的备节点来做剖析，性能和隔离性就会差一些），离现实中的 HTAP 差距甚远。咱们也会在这个畛域做持续性的投入，心愿能摸索出一种能满足大多数业务场景的 HTAP 的状态进去。提供异地多活（全球化等概念）在数据库层面更原生的反对。反对淘宝的异地多活使咱们团队在这个畛域积攒了大量的教训（置信没有人比咱们懂的更多）。实际上 PolarDB- X 是国内少有的落地大型异地多活我的项目的数据库（其中一个还是民生级的零碎），咱们心愿能把这些教训变成数据库的原生能力，缩小异地多活零碎对外部组件的依赖，将它变得更为普世。

最初，咱们也会动摇的做好开源，放弃商业版与开源版在内核层面代码的一致性。同时也会持续倒退轻量化的开源管控零碎。

原文链接

本文为阿里云原创内容，未经容许不得转载。