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

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日志，基于对象存储介质构建列存索引，能满足实时更新的需求、以及结合计算节点可提供列存的快照一致性查询能力。

梳理下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、列存索引

索引创建的语法：

实际例子：

# 先创建表
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;

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

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

▶︎ 列存索引的数据流转：

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

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

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

列存索引，查询流程：

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

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的行存和列存的效果对比图：

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

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

详细数据如下：

02、兼容MySQL 8.0.32

回顾下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（并行索引创建）。

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执行能力，对接存储层的事务系统来提供数据操作。

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

03、全球数据库GDN

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

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

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

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

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

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

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

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

常见的业务场景：

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

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

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。

#开启校验
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;

04、开源生态完善

🔗 https://doc.polardbx.com/zh/deployment/topics/deploy-by-rpm-std.html

【PolarDB分布式版开源】基于Paxos的MySQL三副本：

🔗 https://zhuanlan.zhihu.com/p/669301230

‍‍

点击了解 PolarDB分布式版开源版本 详情