架构简介

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 中心的主实例出现地域级别的故障时，可以手动进行容灾切换，将读写流量切换到从实例

1. 基于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] ... ]

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

SHOW SLAVE STATUS [ channel_option ]
channel_option:
    FOR CHANNEL channel

1. 可以使用兼容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

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

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

发布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标准版高可用路由服务