重磅更新｜PolarDB分布式版V2.4 列存引擎正式开源

导读1：架构简介

阿里云瑶池旗下的云原生数据库PolarDB分布式版（PolarDB for Xscale，简称PolarDB-X）采用Shared-nothing与存储分离计算架构进行设计，系统由5个核心组件组成。

PolarDB分布式架构图

1. 计算节点（CN，Compute Node）

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

2. 存储节点（DN，Dat‍a Node）

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

3. 元数据服务（GMS，Global Meta Service） 

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

4. 日志节点（CDC，Change Data Capture） 

日志节点提供完全兼容MySQL Binlog格式和协议的增量订阅能力，提供兼容MySQL Replication协议的主从复制能力。

5. 列存节点（Columnar）

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

🔗 开源地址

https://github.com/polardb/polardbx-sql

导读2：版本说明

梳理下PolarDB分布式版开源脉络：

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

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

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

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

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

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

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

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

01、列存索引

随着云原生技术的不断普及，以Snowflake为代表的新一代云原生数仓、以及数据库HTAP架构不断创新，可见在未来一段时间后行列混存HTAP会成为一个数据库的标配能力，需要在当前数据库列存设计中面相未来的低成本、易用性、高性能上有更多的思考PolarDB分布式版在V2.4版本正式发布列存引擎，提供列存索引的形态（Clustered Columnar Index，CCI），行存表默认有主键索引和二级索引，列存索引是一份额外基于列式结构的二级索引（覆盖行存所有列），一张表可以同时具备行存和列存的数据。

PolarDB分布式版列存索引

1.1 相关语法

索引创建的语法：

列存索引创建的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。

1.2 原理简介

▶︎ 列存索引的数据结构：

列存数据结构列存索引是由列存引擎（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做计算（行列混合计算）。

1.3 性能体验

测试集：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测试报告[2]

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

详细数据如下：

02、兼容MySQL 8.0.32

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

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

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

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

2.1 标准版架构

PolarDB分布式版标准版，采用分层架构：

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

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

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

2.2 性能体验

硬件环境：

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

03、全球数据库GDN

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

3.1 常见容灾架构

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

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

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

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

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

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

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

3.2 PolarDB分布式版的容灾能力

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

PolarDB分布式版V2.4版本以前，主要提供的容灾形态：

• 单机房（3副本），能够防范少数派1个节点的故障；
• 同城3机房（3副本），能够防范单机房故障；
• 两地三中心（5副本），能够防范城市级的故障。

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

常见的业务场景：

1. 基于GDN的异地容灾

异地容灾业务默认的流量，读写都集中在中心的主实例，异地的从实例作为灾备节点，提供就近读的服务能力PolarDB分布式版主实例和从实例，采用双向复制的能力，复制延迟小于2秒，通过备份集的异地备份可以快速创建一个异地从实例。当PolarDB分布式版中心的主实例出现地域级别的故障时，可以手动进行容灾切换，将读写流量切换到从实例。2. 基于GDN的异地多活异地多活业务适配单元化分片，按照数据分片的粒度的就近读和写，此时主实例和从实例，均承担读写流量PolarDB分布式版主实例和从实例，采用双向复制的能力，复制延迟小于2秒当PolarDB分布式版中心的主实例出现地域级别的故障时，可以手动进行容灾切换，将读写流量切换到从实例。

3.3 使用体验

PolarDB分布式版V2.4版本，暂时仅提供基于GDN的异地容灾，支持跨地域的主备复制能力（异地多活形态会在后续版本中发布)。GDN是一个产品形态，其基础和本质是数据复制，PolarDB分布式版提供了高度兼容MySQL Replica的SQL命令来管理GDN，简单来说，会配置MySQL主从同步，就能快速的配置PolarDB分布式版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分布式版也需要做最好的自己，我们在兼容MySQL的基础上，还提供了很多定制化的功能特性。

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

1. PolarDB分布式版实例R1的server_id 为 100；

2. PolarDB分布式版实例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分布式版GDN支持各种类型的DDL复制，基本覆盖了其所支持的全部DDL类型，尤其是针对PolarDB分布式版特有schema的DDL操作，更是实现了充分的支持，典型的例子如：sequenc、tablegroup等DDL的同步。除了数据一致性，考量GDN能力的另外两个核心指标为RPO和RTO，复制延迟越低则RPO越小，同时也间接影响了RTO，本次V2.4版本提供了RPO