PolarDB-X V2.4 列存引擎开源正式发布
架构简介
PolarDB-X 采用 Shared-nothing 与存储分离计算架构进行设计，系统由5个核心组件组成。
- 计算节点（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），行存表默认有主键索引和二级索引，列存索引是一份额外基于列式结构的二级索引（覆盖行存所有列），一张表可以同时具备行存和列存的数据。
相关语法
索引创建的语法：
列存索引创建的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文件。
列存索引的数据流转：
列存索引，构建流程：
- 数据通过CN写入到DN（正常的行存数据写入）
- CDC事务日志，提供实时提取逻辑binlog（获取事务日志）
- Columnar实时消费snapshot数据和cdc 增量binlog流，构建列存索引（异步实现行转列）
列存索引，查询流程：
- CN节点，基于一套SQL引擎提供了统一入口
- CN 从GMS获取当前最新的TSO(事务时间戳)
- CN基于TSO获取当前列存索引的快照信息（GMS中存储了列存索引的元数据）
- 从DN或者OSS扫描数据，拉到CN做计算（行列混合计算）
tips. 更多列存引擎相关的技术原理文章，后续会逐步发布，欢迎大家持续关注。
性能体验
测试集：TPC-H 100GB 硬件环境：
| 机器用途 | 机型 | 规格 |
| 压力机 | ecs.hfg7.6xlarge | 24c96g |
| 数据库机器 | ecs.i4.8xlarge * 3 | 32c256g + 7TB的存储，单价：7452元/月 |
按照正常导入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 | 2.98 | 105.95 | 35.5 倍 |
| select count(*) from lineitem | 0.52 | 19.85 | 38.1 倍 |
tpch-Q1的行存和列存的效果对比图：
select count的行存和列存的效果对比图：
场景2：TPC-H 22条query
基于列存索引的性能白皮书，开源版本可以参考：TPC-H测试报告
TPC-H 100GB，22条query总计25.76秒
详细数据如下：
| 查询语句 | 耗时（单位秒） |
| Q1 | 2.59 |
| Q2 | 0.80 |
| Q3 | 0.82 |
| Q4 | 0.52 |
| Q5 | 1.40 |
| Q6 | 0.13 |
| Q7 | 1.33 |
| Q8 | 1.15 |
| Q9 | 3.39 |
| Q10 | 1.71 |
| Q11 | 0.53 |
| Q12 | 0.38 |
| Q13 | 1.81 |
| Q14 | 0.41 |
| Q15 | 0.46 |
| Q16 | 0.59 |
| Q17 | 0.32 |
| Q18 | 3.10 |
| Q19 | 0.88 |
| Q20 | 0.81 |
| Q21 | 1.84 |
| Q22 | 0.79 |
| Total | 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执行能力，对接存储层的事务系统来提供数据操作。
性能体验
硬件环境：
| 机器用途 | 机型 | 规格 |
| 压力机 | ecs.hfg7.6xlarge | 24c96g |
| 数据库机器 | ecs.i4.8xlarge * 3 | 32c256g + 7TB的存储，单价：7452元/月 |
TPCC场景：对比开源MySQL（采用相同的主机硬件部署）
| 场景 | 并发数 | MySQL 8.0.34 主备异步复制 |
PolarDB-X 标准版 8.0.32 Paxos多数派 |
性能提升 |
| TPCC 1000仓 | 300并发 | 170882.38 tpmC | 236036.8 tpmC | ↑38% |
03 全球数据库 GDN
数据库容灾架构设计是确保企业关键数据安全和业务连续性的核心。随着数据成为企业运营的命脉，任何数据丢失或服务中断都可能导致重大的财务损失。在规划容灾架构时，企业需要考虑数据的恢复时间目标（RTO）和数据恢复点目标（RPO），以及相关的成本和技术实现的复杂性。
常见容灾架构
异地多活，主要指跨地域的容灾能力，可以同时在多地域提供读写能力。金融行业下典型的两地三中心架构，更多的是提供异地容灾，日常情况下异地并不会直接提供写流量。但随着数字化形式的发展，越来越多的行业都面临着容灾需求。比如，运营商、互联网、游戏等行业，都对异地多活的容灾架构有比较强的诉求。 目前数据库业界常见的容灾架构：
- 同城3机房，一般是单地域多机房，无法满足多地域多活的诉求
- 两地三中心，分为主地域和异地灾备地域，流量主要在主地域，异地主要承担灾备容灾，异地机房日常不提供多活服务。
- 三地五中心，基于Paxos/Raft的多地域复制的架构
- Geo-Partitioning，基于地域属性的partition分区架构，提供按用户地域属性的就近读写能力
- Global Database，构建全球多活的架构，写发生在中心，各自地域提供就近读的能力
总结一下容灾架构的优劣势：
| 容灾架构 | 容灾范围 | 最少机房要求 | 数据复制 | 优缺点 |
| 同城3机房 | 单机房级别 | 3机房 | 同步 | 比较通用，业务平均RT增加1ms左右 |
| 两地三中心 | 机房、地域 | 3机房 + 2地域 | 同步 | 比较通用，业务平均RT增加1ms左右 |
| 三地五中心 | 机房、地域 | 5机房 + 3地域 | 同步 | 机房建设成本比较高，业务平均RT会增加5~10ms左右（地域之间的物理距离） |
| Geo-Partitioning | 机房、地域 | 3机房 + 3地域 | 同步 | 业务有适配成本（表分区增加地域属性），业务平均RT增加1ms左右 |
| Global Database | 机房、地域 | 2机房 + 2地域 | 异步 | 比较通用，业务就近读+ 远程转发写，适合异地读多写少的容灾场景 |
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跨地域的容灾（比如，两个地域的数据库采用单向复制、双向复制 ， 或者多个地域组成一个中心+单元的双向复制等）。
常见的业务场景：
- 基于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 channel3. 可以使用兼容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 channel4. 可以使用兼容MySQL的START SLAVE 和 STOP SLAVE命令，启动和停止GDN复制链路
START SLAVE [ channel_option ]
channel_option:
FOR CHANNEL channel
STOP SLAVE [ channel_option ]
channel_option:
FOR CHANNEL channel5.可以使用兼容MySQL的RESET SLAVE，删除GDN复制链路
RESET SLAVE ALL [ channel_option ]
channel_option:
FOR CHANNEL channel拥抱生态，提供兼容MySQL的使用方式，可以大大降低使用门槛，但PolarDB-X也需要做最好的自己，我们在兼容MySQL的基础上，还提供了很多定制化的功能特性。
| 功能特性 | 功能描述 |
| 一键创建多条GDN复制链路 | 在 CHANGE MASTER 语句中，指定 STREAM_GROUP 选项，即PolarDB-X多流binlog集群的流组名称，可以一键创建多条复制链路(具体取决于binlog流的数量)，带来极简的使用体验。什么是多流binlog？参见binlog日志服务 |
| 基于时间戳的复制链路搭建 | 在 CHANGE MASTER 语句中，指定 MASTER_LOG_TIME_SECOND 选项，可以基于指定的时间点，来构建复制链路，相比通过指定file name和file positiion的方式，更加灵活。 比如在搭建GDN时，一般的流程为先通过全量复制或备份恢复的方式准备好从实例，然后启动增量复制链路，通过指定 MASTER_LOG_TIME_SECOND 显然更加简便。尤其是当对接的是PolarDB-X多流binlog时，为每条链路分别指定file name和file position，相当繁琐，而结合STREAM_GROUP和MASTER_LOG_TIME_SECOND，则相当简便。 |
| 多种模式的 DML 复制策略 | 在 CHANGE MASTER 语句中，指定 WRITE_TYPE 选项，可以指定DML的复制策略，可选策略如下 - TRANSACTION：严格按照binlog中的事务单元，进行原样回放，适用于对数据一致性、事务完整性有高要求的场景 - SERIAL：打破binlog中的事务单元，重新组织事务单元，进行串行回放，适用于对事务完整性要求不高，但仍需要串行复制的场景 - SPLIT：打破binlog中的事务单元，依赖内置的数据冲突检测算法，进行全并行回放，适用于高吞吐、高并发的场景 |
| 全量增量一体化复制搭建 | 谁说 CHANGE MASTER 只能创建增量同步？在 CHANGE MASTER 语句中，指定 MODE 选项，可以指定链路的搭建模式 - INCREMENTAL: 直接创建增量复制链路 - IMAGE: 先完成全量复制，再基于全量复制开始的时间点，启动增量复制链路 |
| 原生的轻量级双向复制能力 | 在 CHANGE MASTER 语句中，组合使用 WRITE_SERVER_ID 和 IGNORE_SERVER_IDS 选项，可配置基于server_id的防流量回环双向复制链路，相比需要额外引入事务表的方案，不仅使用简单，而且性能无损。 |
原生的轻量级双向复制能力，举例来说：
- PolarDB-X实例 R1 的server_id为100
- PolarDB-X实例 R2 的server_id为200
- 构建 R1 到 R2的复制链路时，在R2上执行CHANGE MASTER并指定WRITE_SERVER_ID = 300、IGNORE_SERVER_IDS = 400
- 构建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支持多种形态的快速部署能力，可以结合各自需求尽心选择
| 部署方式 | 说明 | 安装工具的快速安装 | 依赖项 |
| RPM包 | 零组件依赖，手工快速部署 | RPM下载、RPM安装 | rpm |
| PXD | 自研快速部署工具，通过yaml文件配置快速部署 | PXD安装 | python3、docker |
| K8S | 基于k8s operator的快速部署工具 | K8S安装 | k8s、docker |
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标准版高可用路由服务
本文为阿里云原创内容，未经允许不得转载。
