[版本更新] PolarDB-X V2.4 列存引擎开源正式发布

架构简介

PolarDB-X 采用 Shared-nothing 与存储分离计算架构进行设计，系统由 5 个核心组件组成。

PolarDB 分布式架构图

• 计算节点（CN, Compute Node） 计算节点是系统的入口，采用无状态设计，包括 SQL 解析器、优化器、执行器等模块。负责数据分布式路由、计算及动态调度，负责分布式事务 2PC 协调、全局二级索引维护等，同时提供 SQL 限流、三权分立等企业级特性。

• 存储节点（DN, Data Node） 存储节点负责数据的持久化，基于多数派 Paxos 协议提供数据高可靠、强一致保障，同时通过 MVCC 维护分布式事务可见性。

• 元数据服务（GMS, Global Meta Service） 元数据服务负责维护全局强一致的 Table/Schema, Statistics 等系统 Meta 信息，维护账号、权限等安全信息，同时提供全局授时服务（即 TSO）。

• 日志节点（CDC, Change Data Capture） 日志节点提供完全兼容 MySQL Binlog 格式和协议的增量订阅能力，提供兼容 MySQL Replication 协议的主从复制能力。

• 列存节点 (Columnar) 列存节点提供持久化列存索引，实时消费分布式事务的 binlog 日志，基于对象存储介质构建列存索引，能满足实时更新的需求、以及结合计算节点可提供列存的快照一致性查询能力

开源地址：[https://github.com/polardb/polardbx-sql]

版本说明

梳理下 PolarDB-X 开源脉络：

• 2021 年 10 月，在云栖大会上，阿里云正式对外开源了云原生分布式数据库 PolarDB-X，采用全内核开源的模式，开源内容包含计算引擎、存储引擎、日志引擎、Kube 等。

• 2022 年 1 月，PolarDB-X 正式发布 2.0.0 版本，继 2021 年 10 月 20 号云栖大会正式开源后的第一次版本更新，更新内容包括新增集群扩缩容、以及 binlog 生态兼容等特性，兼容 maxwell 和 debezium 增量日志订阅，以及新增其他众多新特性和修复若干问题。

• 2022 年 3 月，PolarDB-X 正式发布 2.1.0 版本，包含了四大核心特性，全面提升 PolarDB-X 稳定性和生态兼容性，其中包含基于 Paxos 的三副本共识协议。

• 2022 年 5 月，PolarDB-X 正式发布 2.1.1 版本，重点推出冷热数据新特性，可以支持业务表的数据按照数据特性分别存储在不同的存储介质上，比如将冷数据存储到 Aliyun OSS 对象存储上。

• 2022 年 10 月，PolarDB-X 正式发布 2.2.0 版本，这是一个重要的里程碑版本，重点推出符合分布式数据库金融标准下的企业级和国产 ARM 适配，共包括八大核心特性，全面提升 PolarDB-X 分布式数据库在金融、通讯、政务等行业的普适性。

• 2023 年 3 月，PolarDB-X 正式发布 2.2.1 版本，在分布式数据库金融标准能力基础上，重点加强了生产级关键能力，全面提升 PolarDB-X 面向数据库生产环境的易用性和安全性，比如：提供数据快速导入、性能测试验证、生产部署建议等。

• 2023 年 10 月份，PolarDB-X 正式发布 2.3.0 版本，重点推出 PolarDB-X 标准版（集中式形态），将 PolarDB-X 分布式中的 DN 节点提供单独服务，支持 paxos 协议的多副本模式、lizard 分布式事务引擎，同时可以 100%兼容 MySQL，对应 PolarDB-X 公有云的标准版。

2024 年 4 月份，PolarDB-X 正式发布 2.4.0 版本，重点推出列存节点 Columnar，可以提供持久化列存索引（Clustered Columnar Index，CCI）。PolarDB-X 的行存表默认有主键索引和二级索引，列存索引是一份额外基于列式结构的二级索引（默认覆盖行存所有列），一张表可以同时具备行存和列存的数据，结合计算节点 CN 的向量化计算，可以满足分布式下的查询加速的诉求，实现 HTAP 一体化的体验和效果。

01 列存索引

随着云原生技术的不断普及，以 Snowflake 为代表的新一代云原生数仓、以及数据库 HTAP 架构不断创新，可见在未来一段时间后行列混存 HTAP 会成为一个数据库的标配能力，需要在当前数据库列存设计中面相未来的低成本、易用性、高性能上有更多的思考

PolarDB-X 在 V2.4 版本正式发布列存引擎，提供列存索引的形态（Clustered Columnar Index，CCI），行存表默认有主键索引和二级索引，列存索引是一份额外基于列式结构的二级索引（覆盖行存所有列），一张表可以同时具备行存和列存的数据。

PolarDB-X 列存索引

相关语法

索引创建的语法：

列存索引创建的 DDL 语法

• CLUSTERED COLUMNAR：关键字，用于指定添加的索引类型为 CCI。

• 索引名：索引表的名称，用于在 SQL 语句中指定该索引。

• 排序键：索引的排序键，即数据在索引文件中按照该列有序存储。

• 索引分区子句：索引的分区算法，与 CREATE TABLE 中分区子句的语法一致。

实际例子：

先创建表

CREATE TABLE t_order (id bigint(11) NOT NULL AUTO_INCREMENT,order_id varchar(20) DEFAULT NULL,buyer_id varchar(20) DEFAULT NULL,seller_id varchar(20) DEFAULT NULL,order_snapshot longtext DEFAULT NULL,order_detail longtext DEFAULT NULL,PRIMARY KEY (id),KEY l_i_order (order_id)) ENGINE=InnoDB DEFAULT CHARSET=utf8 partition by hash(order_id) partitions 16;

再创建列存索引

CREATE CLUSTERED COLUMNAR INDEX cc_i_seller ON t_order (seller_id) partition by hash(order_id) partitions 16;

• 主表："t_order" 是分区表，分区的拆分方式为按照 "order_id" 列进行哈希。

• 列存索引："cc_i_seller" 按照 "seller_id" 列进行排序，按照 "order_id" 列进行哈希。

• 索引定义子句：CLUSTERED COLUMNAR INDEX cc_i_seller ON t_order (seller_id) partition by hash(order_id) partitions 16。

原理简介

列存索引的数据结构：

列存数据结构

列存索引是由列存引擎（Columnar）节点来构造的，数据结构基于 Delta+Main(类 LSM 结构)二层模型，实时更新采用了标记删除的技术(update 转化为 delete 标记 + insert)，确保了行存和列存之间实现低延时的数据同步，可以保证秒级的实时更新。数据实时写入到 MemTable，在一个 group commit 的周期内，会将数据存储到一个本地 csv 文件，并追加到 OSS 上对应 csv 文件的尾部，这个文件称为 delta 文件。OSS 对象存储上的.csv 文件不会长期存在，而是由 compaction 线程不定期地转换成.orc 文件。

列存索引的数据流转：

数据流转

列存索引，构建流程：

1. 数据通过 CN 写入到 DN（正常的行存数据写入）

2. CDC 事务日志，提供实时提取逻辑 binlog（获取事务日志）

3. Columnar 实时消费 snapshot 数据和 cdc 增量 binlog 流，构建列存索引（异步实现行转列）

列存索引，查询流程：

1. CN 节点，基于一套 SQL 引擎提供了统一入口

2. CN 从 GMS 获取当前最新的 TSO(事务时间戳)

3. CN 基于 TSO 获取当前列存索引的快照信息（GMS 中存储了列存索引的元数据）

4. 从 DN 或者 OSS 扫描数据，拉到 CN 做计算（行列混合计算）

tips. 更多列存引擎相关的技术原理文章，后续会逐步发布，欢迎大家持续关注。

性能体验

测试集：

TPC-H 100GB 硬件环境：

按照正常导入 TPC-H 100GB 数据后，执行 SQL 创建列存索引：

create clustered columnar index nation_col_index on nation(n_nationkey) partition by hash(n_nationkey) partitions 1;

create clustered columnar index region_col_index on region(r_regionkey) partition by hash(r_regionkey) partitions 1;

create clustered columnar index customer_col_index on customer(c_custkey) partition by hash(c_custkey) partitions 96;

create clustered columnar index part_col_index on part(p_size) partition by hash(p_partkey) partitions 96;

create clustered columnar index partsupp_col_index on partsupp(ps_partkey) partition by hash(ps_partkey) partitions 96;

create clustered columnar index supplier_col_index on supplier(s_suppkey) partition by hash(s_suppkey) partitions 96;

create clustered columnar index orders_col_index on orders(o_orderdate,o_orderkey) partition by hash(o_orderkey) partitions 96;

create clustered columnar index lineitem_col_index on lineitem(l_shipdate,l_orderkey) partition by hash(l_orderkey) partitions 96;

场景 1：单表聚合场景( count 、 groupby)

tpch-Q1 的行存和列存的效果对比图：

tpch-Q1

select count 的行存和列存的效果对比图：

count

查询场景 2：TPC-H 22 条 query

基于列存索引的性能白皮书，开源版本可以参考：TPC-H 测试报告

TPC-H 100GB，22 条 query 总计 25.76 秒

详细数据如下：

02 兼容 MySQL 8.0.32

PolarDB-X V2.3 版本，推出了集中式和分布式一体化架构（简称集分一体），在 2023 年 10 月公共云和开源同时新增集中式形态，将分布式中的 DN 多副本单独提供服务，支持 Paxos 多副本、lizard 分布式事务引擎，可以 100%兼容 MySQL。 所谓集分一体化，就是兼具分布式数据库的扩展性和集中式数据库的功能和单机性能，两种形态可以无缝切换。在集分一体化数据库中，数据节点被独立出来作为集中式形态，完全兼容单机数据库形态。当业务增长到需要分布式扩展的时候，架构会原地升级成分布式形态，分布式组件无缝对接到原有的数据节点上进行扩展，不需要数据迁移，也不需要应用侧做改造。

回顾下 MySQL 8.0 的官方开源，8.0.11 版本在 2018 年正式 GA，历经 5 年左右的不断演进，修复和优化了众多稳定性和安全相关的问题，2023 年后的 8.0.3x 版本后逐步进入稳态。 PolarDB-X 在 V2.4 版本，跟进 MySQL 8.0 的官方演进，分布式的 DN 多副本中全面兼容 MySQL 8.0.32，快速继承了官方 MySQL 的众多代码优化：

• 更好用的 DDL 能力，比如：Instant DDL（加列、减列）、Parallel DDL（并行索引创建）

• 更完整的 SQL 执行能力，比如：Hash Join、窗口函数等

标准版架构

PolarDB-X 标准版，采用分层架构：

• 日志层：采用 Paxos 的多数派复制协议，基于 Paxos consensus 协议日志完全兼容 MySQL binlog 格式。相比于开源 MySQL 主备复制协议（基于 binlog 的异步或半同步），PolarDB-X 标准版可以金融级容灾能力，满足机房级故障时，不丢任何数据，简称 RPO=0。

• 存储层：自研 Lizard 事务系统，对接日志层，可以替换传统 MySQL InnoDB 的单机事务系统，分别设计了 SCN 单机事务系统和 GCN 分布式事务系统来解决这些弊端，可以满足集中式和分布式一体化的事务优化，同时 PolarDB-X 标准版基于 SCN 单机事务系统可以提供完全兼容 MySQL 的事务隔离级别。

• 执行层：类似于 MySQL 的 Server 层，自研 xRPC Server 可以对接 PolarDB-X 企业版的分布式查询。同时为完全兼容 MySQL，也提供兼容 MySQL Server 的 SQL 执行能力，对接存储层的事务系统来提供数据操作。

性能体验

硬件环境：

TPCC 场景：对比开源 MySQL（采用相同的主机硬件部署）

03 全球数据库 GDN

数据库容灾架构设计是确保企业关键数据安全和业务连续性的核心。随着数据成为企业运营的命脉，任何数据丢失或服务中断都可能导致重大的财务损失。在规划容灾架构时，企业需要考虑数据的恢复时间目标（RTO）和数据恢复点目标（RPO），以及相关的成本和技术实现的复杂性。

常见容灾架构

异地多活，主要指跨地域的容灾能力，可以同时在多地域提供读写能力。金融行业下典型的两地三中心架构，更多的是提供异地容灾，日常情况下异地并不会直接提供写流量。但随着数字化形式的发展，越来越多的行业都面临着容灾需求。比如，运营商、互联网、游戏等行业，都对异地多活的容灾架构有比较强的诉求。 目前数据库业界常见的容灾架构：

• 同城 3 机房，一般是单地域多机房，无法满足多地域多活的诉求

• 两地三中心，分为主地域和异地灾备地域，流量主要在主地域，异地主要承担灾备容灾，异地机房日常不提供多活服务。

• 三地五中心，基于 Paxos/Raft 的多地域复制的架构

• Geo-Partitioning，基于地域属性的 partition 分区架构，提供按用户地域属性的就近读写能力

• Global Database，构建全球多活的架构，写发生在中心，各自地域提供就近读的能力

总结一下容灾架构的优劣势：

PolarDB-X 的容灾能力

PolarDB-X 采用数据多副本架构（比如 3 副本、5 副本），为了保证副本间的强一致性（RPO=0），采用 Paxos 的多数派复制协议，每次写入都要获得超过半数节点的确认，即便其中 1 个节点宕机，集群也仍然能正常提供服务。Paxos 算法能够保证副本间的强一致性，彻底解决副本不一致问题。

PolarDB-X V2.4 版本以前，主要提供的容灾形态：

• 单机房（3 副本），能够防范少数派 1 个节点的故障

• 同城 3 机房（3 副本），能够防范单机房故障

• 两地三中心（5 副本），能够防范城市级的故障

阿里集团的淘宝电商业务，在 2017 年左右开始建设异地多活的架构，构建了三地多中心的多活能力，因此在 PolarDB-X V2.4 我们推出了异地多活的容灾架构，我们称之为全球数据库（Global Database Network，简称 GDN）。 PolarDB-X GDN 是由分布在同一个国家内多个地域的多个 PolarDB-X 集群组成的网络，类似于传统 MySQL 跨地域的容灾（比如，两个地域的数据库采用单向复制、双向复制 ， 或者多个地域组成一个中心+单元的双向复制等）。

常见的业务场景：

1. 基于 GDN 的异地容灾

异地容灾

业务默认的流量，读写都集中在中心的主实例，异地的从实例作为灾备节点，提供就近读的服务能力 PolarDB-X 主实例 和 从实例，采用双向复制的能力，复制延迟小于 2 秒，通过备份集的异地备份可以快速创建一个异地从实例。 当 PolarDB-X 中心的主实例出现地域级别的故障时，可以手动进行容灾切换，将读写流量切换到从实例

2. 基于 GDN 的异地多活

异地多活

业务适配单元化分片，按照数据分片的粒度的就近读和写，此时主实例和从实例，均承担读写流量 PolarDB-X 主实例 和 从实例，采用双向复制的能力，复制延迟小于 2 秒 当 PolarDB-X 中心的主实例出现地域级别的故障时，可以手动进行容灾切换，将读写流量切换到从实例

使用体验

PolarDB-X V2.4 版本，暂时仅提供基于 GDN 的异地容灾，支持跨地域的主备复制能力（异地多活形态会在后续版本中发布)。GDN 是一个产品形态，其基础和本质是数据复制，PolarDB-X 提供了高度兼容 MySQL Replica 的 SQL 命令来管理 GDN，简单来说，会配置 MySQL 主从同步，就能快速的配置 PolarDB-X GDN。

1. 可以使用兼容 MySQL 的 CHANGE MASTER 命令，搭建 GDN 复制链路

CHANGE MASTER TO option [, option] ... [ channel_option ] option: { MASTER_HOST = 'host_name' | MASTER_USER = 'user_name' | MASTER_PASSWORD = 'password' | MASTER_PORT = port_num | MASTER_LOG_FILE = 'source_log_name' | MASTER_LOG_POS = source_log_pos | MASTER_LOG_TIME_SECOND = source_log_time | SOURCE_HOST_TYPE = {RDS|POLARDBX|MYSQL} | STREAM_GROUP = 'stream_group_name' | WRITE_SERVER_ID = write_server_id | TRIGGER_AUTO_POSITION = {FALSE|TRUE} | WRITE_TYPE = {SPLIT|SERIAL|TRANSACTION} | MODE = {INCREMENTAL|IMAGE} | CONFLICT_STRATEGY = {OVERWRITE|INTERRUPT|IGNORE|DIRECT_OVERWRITE} | IGNORE_SERVER_IDS = (server_id_list) } channel_option: FOR CHANNEL channel server_id_list: [server_id [, server_id] ... ]

2. 可以使用兼容 MySQL 的 SHOW SLAVE STATUS 命令，监控 GDN 复制链路

SHOW SLAVE STATUS [ channel_option ] channel_option: FOR CHANNEL channel

3. 可以使用兼容 MySQL 的 CHANGE REPLICATION FILTER 命令，配置数据复制策略

CHANGE REPLICATION FILTER option [, option] ... [ channel_option ] option: { REPLICATE_DO_DB = (do_db_list) | REPLICATE_IGNORE_DB = (ignore_db_list) | REPLICATE_DO_TABLE = (do_table_list) | REPLICATE_IGNORE_TABLE = (ignore_table_list) | REPLICATE_WILD_DO_TABLE = (wild_do_table_list) | REPLICATE_WILD_IGNORE_TABLE = (wile_ignore_table_list) | REPLICATE_SKIP_TSO = 'tso_num' | REPLICATE_SKIP_UNTIL_TSO = 'tso_num' | REPLICATE_ENABLE_DDL = {TRUE|FALSE} } channel_option: FOR CHANNEL channel

4. 可以使用兼容 MySQL 的 START SLAVE 和 STOP SLAVE 命令，启动和停止 GDN 复制链路

START SLAVE [ channel_option ] channel_option: FOR CHANNEL channel STOP SLAVE [ channel_option ] channel_option: FOR CHANNEL channel

5. 可以使用兼容 MySQL 的 RESET SLAVE，删除 GDN 复制链路

RESET SLAVE ALL [ channel_option ]

channel_option:

FOR CHANNEL channel

拥抱生态，提供兼容 MySQL 的使用方式，可以大大降低使用门槛，但 PolarDB-X 也需要做最好的自己，我们在兼容 MySQL 的基础上，还提供了很多定制化的功能特性。

原生的轻量级双向复制能力，举例来说：

1. PolarDB-X 实例 R1 的 server_id 为 100

2. PolarDB-X 实例 R2 的 server_id 为 200

3. 构建 R1 到 R2 的复制链路时，在 R2 上执行 CHANGE MASTER 并指定 WRITE_SERVER_ID = 300、IGNORE_SERVER_IDS = 400

4. 构建 R2 到 R1 的复制链路时，在 R1 上执行 CHANGE MASTER 并指定 WRITE_SERVER_ID = 400、IGNORE_SERVER_IDS = 300

GDN 场景下，保证主从实例之间的数据一致性是最为关键的因素，提供便捷的数据校验能力则显得尤为关键，V2.4 版本不仅提供了完善的主从复制能力，还提供了原生的数据校验能力，在从实例上执行相关 SQL 命令，即可实现在线数据校验。V2.4 版本暂时只支持直接校验模式(校验结果存在误报的可能)，基于 sync point 的快照校验能力(校验结果不会出现误报)，会在下个版本进行开源。

#开启校验

CHECK REPLICA TABLE {`test_db`.`test_tb`} | {`test_db`}

[MODE='direct' | 'tso']

FOR CHANNEL xxx;

#查看校验进度

CHECK REPLICA TABLE [`test_db`.`test_tb`] | [`test_db`] SHOW PROGRESS;

#查看差异数据

CHECK REPLICA TABLE {`test_db`.`test_tb`} | {`test_db`} SHOW DIFFERENCE;

此外，数据的一致性不仅体现在数据内容的一致性上，还体现在 schema 的一致性上，只有二者都保证一致，才是真正的一致，比如即使丢失一个索引，当发生主从切换后，也可能引发严重的性能问题。PolarDB-X GDN 支持各种类型的 DDL 复制，基本覆盖了其所支持的全部 DDL 类型，尤其是针对 PolarDB-X 特有 schema 的 DDL 操作，更是实现了充分的支持，典型的例子如：sequenc、tablegroup 等 DDL 的同步。

除了数据一致性，考量 GDN 能力的另外两个核心指标为 RPO 和 RTO，复制延迟越低则 RPO 越小，同时也间接影响了 RTO，本次 V2.4 版本提供了 RPO <= 2s、RTO 分钟级的恢复能力，以 Sysbench 和 TPCC 场景为例，GDN 单条复制链路在不同网络延迟条件(0.1ms ~ 20ms 之间)下可以达到的最大 RPS 分布在 2w/s 到 5w/s 之间。当业务流量未触达单条复制链路的 RPS 瓶颈时，用单流 binlog + GDN 的组合来实现容灾即可，而当触达瓶颈后，则可以选择多流 binlog + GDN 的组合来提升扩展性，理论上只要网络带宽没有瓶颈，不管多大的业务流量，都可实现线性扩展，PolarDB-X GDN 具备高度的灵活性和扩展性，以及在此基础之上的高性能表现。

04 开源生态完善

快速运维部署能力

PolarDB-X 支持多种形态的快速部署能力，可以结合各自需求尽心选择

polardbx-operator 是基于 k8s operator 架构，正式发布 1.6.0 版本，提供了 polardb-x 数据库的部署和运维能力，生产环境优先推荐，可参考 polardbx-operator 运维指南。

polardbx-operator 运维指南：

https://doc.polardbx.com/zh/operator/

polardbx-operator 1.6.0 新版本，围绕数据安全、HTAP、可观测性等方面完善集中式与分布式形态的运维能力，支持标准版的备份恢复，透明加密（TDE），列存只读（HTAP）、一键诊断工具、CPU 绑核等功能。同时兼容了 8.0.32 新版本内核，优化了备份恢复功能的稳定性。详见：Release Note。

Release Note：

https://github.com/polardb/polardbx-operator/releases/tag/v1.6.0

pxd 是基于开源用户物理机裸机部署的需求，提供快速部署和运维的能力, 可参考 pxd 运维。

pxd 运维：

https://doc.polardbx.com/zh/maintance/topics/pxd-maintance/

发布 pxd 0.7 新版本，围绕版本升级、备库重搭，以及兼容 8.0.32 新版本内核。

标准版生态

V2.3 版本开始，为方便用户进行快速体验，提供 rpm 包的下载和部署能力，可以一键完成标准版的安装，参考链接：

• 基于 rpm 包部署 polardbx-标准版 （https://doc.polardbx.com/zh/deployment/topics/deploy-by-rpm-std.html）

• 【PolarDB-X 开源】基于 Paxos 的 MySQL 三副本（https://zhuanlan.zhihu.com/p/669301230）

PolarDB-X 标准版，基于 Paxos 协议实现多副本，基于 Paxos 的选举心跳机制，MySQL 自动完成节点探活和 HA 切换，可以替换传统 MySQL 的 HA 机制。如果 PolarDB-X 替换 MySQL，作为生产部署使用，需要解决生产链路的 HA 切换适配问题，开发者们也有自己的一些尝试（比如 HAProxy 或 自定义 proxy）。 在 V2.4 版本，我们正式适配了一款开源 Proxy 组件。

ProxySQL 作为一款成熟的 MySQL 中间件，能够无缝对接 MySQL 协议支持 PolarDB-X，并且支持故障切换，动态路由等高可用保障，为我们提供了一个既可用又好用的代理选项，更多信息可参考文档：使用开源 ProxySQL 构建 PolarDB-X 标准版高可用路由服务。

使用开源 ProxySQL 构建 PolarDB-X 标准版高可用路由服务

https://zhuanlan.zhihu.com/p/697117089