2022年云栖大会上，PolarDB-X 发布2.2.0版本，这是一个重要的里程碑版本，重点推出符合分布式数据库金融标准下的企业级和国产化适配，共包括八大核心特性，全面提升 PolarDB-X 分布式数据库在金融、通讯、政务等行业的普适性。
架构简介
PolarDB-X 采用 Shared-nothing 与存储分离计算架构进行设计，系统由4个核心组件组成。
- 计算节点（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 协议的主从复制能力。
开源地址：[https://github.com/ApsaraDB/galaxysql]
版本说明
梳理下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年9月份，PolarDB-X 数据库高分通过分布式数据库金融标准验证，共进行了 337 个检测项的验证工作，涉及：架构、运维、安全、容灾、性能等。经专家评审后，PolarDB-X 判定符合的检测项为323项，整体测试结果表现优异。
- 2022年10月份，PolarDB-X 正式发布2.2.0版本，这是一个重要的里程碑版本，重点推出符合分布式数据库金融标准下的企业级和国产化适配，共包括八大核心特性，全面提升 PolarDB-X 分布式数据库在金融、通讯、政务等行业的普适性。
01 国产ARM适配
目前市场上对于国产服务器的适配有比较强的需求，常见的需求就是兼容CPU ARM架构，除了数据库能正常运行在ARM架构上，还需要结合国产ARM架构优化数据库的性能。
参考文档：主流CPU性能摸底(Intel/AMD/鲲鹏/海光/飞腾)
PolarDB-X V2.2.0版本开始，同时发布兼容X86/ARM架构的二进制版本，另外配套的数据库部署工具，也会支持ARM架构下的numa绑核能力，提升数据库的性能。
执行docker mainfest inspect(查看对应的二进制版本)
02 全新读写分离架构
MySQL生态里读写分离是一种比较常见的技术，除了用于解决写少读多场景的优化，也经常用于OLTP/OLAP业务隔离的典型场景，比如考虑在线数据库的稳定性，通过读写分离将个别复杂查询发送给MySQL的备库。
传统MySQL的读写分离：
存在的问题：
- 需要有额外的Proxy组件 或者 业务代码路由，实现可控的读写分离路由
- 备库读存在数据一致性问题，比如请求A在主库完成写入，然后立马到备库读数据因为复制延迟，可能读不到刚写入的数据
- 需要额外的OLAP的列存数据 + 外置的复制同步(比如类canal的视线)，支持更复杂的报表查询
PolarDB-X的读写分离架构：
- 计算节点(CN)承当读写分离的路由组件，无需引入额外组件，多个CN节点需配置一个负载均衡设备(比如LVS)
- 提供全局一致性读，在读写分离路由到备库上的请求，保证业务写后读的数据一致性，提供更易用的读写分离能力
- 提供HTAP行列混存架构，多份数据+一套SQL引擎，提供HTAP混合负载能力
强一致读写分离
分布式数据库，天然具备多副本的能力，PolarDB-X采用了Paxos多数派共识协议，借助于Paxos协议的日志流LogIndex(全局递增的唯一序列，记录Paxos日志下标)，PolarDB-X可以基于LogIndex实现多副本的全局一致性读，达到读写分离的效果。
PolarDB-X在传统的MySQL读写分离架构基础上，引入了Paxos Learner节点作为只读RO节点(不参与Paxos三副本投票，仅异步复制数据，RO节点CPU跑满不会影响三副本多数派的写入)。在读写分离模式下，路由到只读RO节点的流量，PolarDB-X会优先获取主库的LogIndex，确保RO副本的LogIndex超过该值，同时利用分布式事务MVCC的TSO时间戳版本，可以实现满足RC/RR隔离级别下的强一致读写分离。
1、 强一致读写分离测试：模拟业务先写后读的场景，写发生在RW库、读发生在RO库
| 写后读间隔（ms） |
传统读写分离 (弱一致性) |
PolarDB-X读写分离 (强一致性) |
| 0ms |
313 |
0 |
| 1ms |
316 |
0 |
| 4ms |
157 |
0 |
| 8ms |
33 |
0 |
从这个测试来看，模拟业务的先写后读的模式，会出现读不到数据的情况。
2、sysbench压测，验证强一致读写分离模式下的性能扩展
CN节点规格：2*16C128G，DN节点规格：RW主实例 2*4C32G、RO只读实例2*4C32G
sysbench oltp_read_only场景：
sysbench --config-file='sysb.conf' --db-ps-mode='disable' --skip-trx='on' --mysql-ignore-errors='all' --tables='16' --table-size='10000000' --range-size=5 --threads=512 oltp_read_only run
| 只读实例查询占比 |
主实例+一个只读实例(强一致) |
主实例+一个只读实例(弱一致) |
主实例+两个只读实例（强一致） |
主实例+两个只读实例（弱一致） |
| 0% |
29145.43 |
29145.43 |
29145.43 |
29145.43 |
| 50% |
44084.40 |
55399.80 |
61698.85 |
73161.11 |
| 100% |
23115.23 |
29235.73 |
42160.54 |
56393.54 |
从测试结果看：
1. 在强一致性读下，在OLTP读场景下流量从主实例切换到只读实例上吞吐的性能衰减20～30%，但是通过添加只读实例个数，性能可以做到一定的线性增加；
2.在弱一致性读下，在TP读场景下流量从主实例切换到只读实例上吞吐的性能未衰减，且通过添加只读实例的个数，性能可以做到线性增加；
HTAP混合负载
HTAP架构的核心目标是帮助用户降低成本：运维成本、使用成本。比如：传统的OLTP + ETL + OLAP的解决方案，最大的挑战在于运维成本的复杂性和稳定性，HTAP数据库的一体化架构可以有效降低外置的运维成本。
目前，市面上的HTAP架构形态多种多样，总结一下核心技术三要素：
- MPP并行计算，基于并行能力提升数据分析场景的线性扩展性，这是基本架构要求
- 资源隔离，确保数据分析查询不影响在线业务，常见的单进程逻辑隔离有局限性，推荐物理多副本的隔离
- 列存副本，降低数据分析查询的资源使用成本，利用列存的紧凑型编码非常适合AP查询，更好的性价比
PolarDB-X在开源V2.2.0版本里，提供了如下能力：
- 资源隔离，基于Paxos多副本 + 读写分离，实现在线业务和数据分析业务的物理隔离
- MPP并行计算，结合读写分离架构，针对路由到只读节点的请求，默认采用MPP并行查询计划，提升查询性能
- 列存能力，当前PolarDB-X在SQL引擎中引入了chunk-at-a-time的内存列式结构，有效提升单核查询效率，但存在物理数据的行结构动态转为列存的开销，有一定的优化空间。未来，PolarDB-X正在开发列式存储引擎，预计在2023年的中旬会正式开源，形成行列混存的统一架构。
HTAP架构即使存在资源隔离，但如果业务在使用中将数据分析查询如果跑到了主库上，也会影响了在线业务的性能，因此对于业务请求如何正确使用多副本也非常重要。
从易用性和稳定性的角度，PolarDB-X提供了基于优化器cost代价的智能读写分离。 PolarDB-X优化器会基于代价分析出查询物理扫描行数、CPU、内存、IO、网络等核心资源消耗量，将请求区分为TP与AP负载，如果在集群地址上开启了智能路由，会主动识别SQL的工作负载类型来做路由，比如将识别为AP负载的流量路由给只读RO副本。可以通过explain cost指令查看SQL工作负载类型的识别情况。例如以下查询，该查询涉及到物理扫描行数rowcount很小，计算资源（CPU&Memory）也消耗比较少，所以这个查询被识别为TP负载。
以TPCH Q13为例来演示下执行器在不同场景下的加速效果，为了方便截图在Q13后面都加了limit
对应CN/DN节点规格：2*16C64G
单机单线程下运行，耗时3min31s
使用Parallel Query加速，既单机多线程执行，耗时23.3s
使用MPP加速，既同时利用两个CN节点的资源计算，耗时11.4s
03 MySQL生态兼容性
MySQL数据库除了基本的SQL DML/DDL/DAL以外，还有许多高级特性，比如锁系统、binlog协议、主备replication、存储过程、触发器、外键、视图等。
传统的分布式中间件或分布式数据库，标榜的高度MySQL兼容性，更多是在SQL的功能语法上，比如DML/DDL/DAL，但在性能兼容、生态兼容上还是有蛮多的差异性，带来了使用上的复杂性。
举几个例子：
- MySQL的事务隔离级别，普遍采用的是RC/RR，在事务模型上有其独特的地方，比如MySQL update v=v+1是一个典型的悲观事务模型，区别于Google Percolator的乐观事务模型。另外，MySQL常用的select for update用法，是一个典型的B+Ttree下GAP锁场景，目前市面上NewSQL基于LSM-Tree架构的几乎没有兼容该特性。
- MySQL binlog组件作为数据库CDC(change data capture)架构的典型设计，也是解决下游生态兼容的重要能力，很多NewSQL更多还是从外置的数据同步组件提供了一定的CDC能力，但并没有兼容binlog协议。
PolarDB-X在22年3月份开源的版本中，已经很好的支持MySQL隔离级别、以及MySQL binlog生态兼容的能力，本次V2.2.0的开源版本，重点加强了几项新的兼容能力：
存储过程
存储过程（Stored Procedure）是一组为了完成特定功能的SQL语句集，业务在实现某些需求时，需要编写一组复杂的SQL语句才能实现的时候，很多资深数据库用户习惯使用存储过程。
使用存储过程能带来如下好处：
- 复用性高。存储过程可以重复使用，从而减少数据库开发人员的工作量，同时降低业务出错概率。
- 效率高。存储过程编译一次后，就会存到数据库，每次调用时都直接执行。
- 降低网络流量。存储过程编译好会放在数据库，我们在远程调用时，不会传输大量的字符串类型的SQL语句。
- 安全性高。完成某个特定功能的存储过程一般只有特定的用户可以使用，具有使用身份限制，更安全。
当然存储过程也存在一些缺点：
- 跨平台可移植性差
- 复杂ETL带来更多资源开销，比如内存/CPU等
- 容易产生大事务和长事务
PolarDB-X 基于GMS存储，全面兼容了MySQL 存储过程语法，支持存储过程的创建、修改、删除等管理操作。同时引入了PL Engine引擎支持存储过程的运行、以及运行的内存管理，支持GB级别的大事务和2小时的长事务等。
CREATE PROCEDURE pro_test() BEGIN DECLARE a CHAR(16); DECLARE b, c int; DECLARE cur1 CURSOR FOR SELECT data, id FROM t1 order by id; DECLARE cur2 CURSOR FOR SELECT id FROM t2 order by id; DECLARE CONTINUE HANDLER FOR NOT FOUND begin LEAVE read_loop; end; OPEN cur1; OPEN cur2; read_loop: LOOP FETCH cur1 INTO a, b; FETCH cur2 INTO c; IF b < c THEN INSERT INTO t3 VALUES (b, a); ELSE INSERT INTO t3 VALUES (c, a); END IF; END LOOP; CLOSE cur1; CLOSE cur2; END;|
具体详情可以参见：https://help.aliyun.com/document_detail/452384.html
Auto Increment 自增约束
分布式数据库提供全局唯一数字序列的主要目的是为了生成全局唯一和有序递增的数字序列，常用于主键列、唯一索引列等列值的生成。
相比于目前绝大部分的NewSQL仅提供了全局唯一但不连续的自增ID，PolarDB-X v2.2提供了全局唯一、连续、单调递增的Auto Increment兼容能力，简称：New Sequence，产生的值是默认从1开始的自然数序列。在AUTO模式库中建表时，指定AUTO_INCREMENT自增列，将默认自动为该表创建并关联一个New Sequence对象，用于在INSERT时自动填充自增列的值。
# 兼容MySQL的建表 create table test ( id bigint not null AUTO_INCREMENT, number INT NOT NULL, primary key(id) ) # 兼容MySQL的SQL操作 INSERT INTO test (number) VALUES (1); INSERT INTO test (number) VALUES (null, 2); INSERT INTO test (number) VALUES (0, 3); INSERT INTO test (number) VALUES (null, 4),(null,5)… ; SELECT LAST_INSERT_ID(); # 兼容Oracle Sequence语法 CREATE NEW SEQUENCE newseq START WITH 1000; SELECT SEQ.NEXTVAL ; SELECT SEQ.CURRVAL ; SELECT SEQ.NEXTVAL FROM DUAL WHERE COUNT = 100; ALTER TABLE test_pxc AUTO_INCREMENT = 200;
Demo视频：
https://link.zhihu.com/?target=https%3A//www.zhihu.com/video/1527649701381365760
具体详情可以参见：PolarDB-X 与 MySQL AUTO_INCREMENT 完全兼容
04 数据库安全
在 IT 圈内，“删库跑路”已经成为程序员经常提及的一句玩笑话。虽然是玩笑话，却反映了数据库对企业的重要性，在提升数据库安全性上，除了做好网络隔离、权限管理外，还需要再全链路中做好审计，确保有查比有果。同时在面向数据丢失的情况下，做好应急恢复的能力。
全量SQL审计
传统的数据库审计，一般采用网络旁路的方式，通过外置组件集中收集所有网络流量，从中采集到对应的SQL审计，另外提供一个审计查询的入口进行快速检索。
PolarDB-X V2.2.0版本，通过数据库内置的SQL审计能力，可以快速且完整的记录所有SQL日志，PolarDB-X通过Logstash组件作为日志的解析和上报组件，默认准实时采集全量SQL的文本，通过logstash的投递组件的扩展，比如可以对接ElasticSearch组件 或者 自定义扩展组件，实现SQL审计持久化存储和白屏化SQL审计查询。
具体详情可参见：https://doc.polardbx.com/operator/ops/logcollector/1-logcollector.html
SQL日志格式：https://doc.polardbx.com/operator/ops/logcollector/2-logfield.html
Flashback Query
删库跑路事件不常有，但因粗心导致的误删数据却屡见不鲜，比如手误执行了一个错误的DML，导致数据被误删。首先，我们以一个实际误删数据的事故开场。
我们来梳理下事故的时间线：
- T1：小明维护了一张员工表，里面记录着公司的员工信息。
- T2：小明需要删除Mary的记录，因此他到数据库里面执行了一条 DELETE 语句，本意是想删除用户 Mary 的记录，但是因为手贱，漏了一个and语句， 导致员工 Ralph 的数据也被意外删除
- T3：此时业务仍在继续，John 被删除， Tim 和 Jose 被插入到表中。而此时粗心的小明发现了数据被误删，迫切希望恢复数据。
围绕这一次的数据误删事故，看看是 PolarDB-X 是如何拯救粗心的小明的？
PolarDB-X 在新版本提供Flashback Query功能，针对行级误删场景，提供短时间内误操作的快速回退能力。
通过Flashback Query的AS OF TIMESTAMP 'xx'可以快速查询数据误删前的数据版本记录
# SQL例子 select title from employee where id in (2,3) AS OF TIMESTAMP '2022-11-11 00:00:00'
原理解读：错误SQL发生时，变更都会记录在版本为 Vn+1 的 undo log 中；T2 时，发现了误改问题并确定误操作时间和影响的数据范围；通过 Flashback Query 能力直接查到了被影响的两行记录在 T1 时刻正确的值；根据 Flashback Query 返回的正确值对数据进行了订正。
05 分布式数据管理
分布式数据库中，数据需要按照一定的策略分布到多个节点中，对数据的可管理性是数据库的一个重要能力维度，在保证数据库线性水平扩展下，基于数据管理来达到业务的诉求。
数据管理的典型业务场景：
- 交易和日志类业务，有按照时间维度的归档属性，期望数据一级分区按照用户做hash分布，二级分区按照range做时间滚动
- 多租户的业务场景，比如政务系统的省地市业务，期望一张表的数据按照list做分布，同时指定分区互相隔离，每个分区单独分配一个存储节点
- 冷热数据分离的场景，比如近期写入的属于热数据，优先放置在SSD盘的节点中，将历史数据动态调度到HDD盘的节点中，历史数据可以做一定的压缩，从而降低存储成本
PolarDB-X 在V2.2.0版本中，进一步增强了分区表的管理能力以及基于Locality的调度。
分区表管理
传统的数据分区策略，一般仅在数据表第一次创建时定义了分布规则，事后的分区新增、修改、删除一般不支持数据搬迁。PolarDB-X在分区表的变更能力上，在满足分布式数据不均衡性上做了更多灵活的变更管理。
- hash/key分区分裂
比如一张表orders
CREATE TABLE orders(a int) PARTITIONBY key(a) partitions 3;
默认的这三个分区的名字依次是p1，p2，p3，可以通过以下语法，将p1分裂成两个分区，这两个新分区是在原p1的hash空间范围内将其按hash空间范围一分为二：
ALTERTABLE tb1 SPLIT PARTITION p1; // p2/p3的数据分区不需要移动
- hash/key分区的热点提取
在orders表的基础上，做一个变更：
ALTER TABLE orders (a int, b int) PARTITION BY key(a, b) PARTITIONS BY 3;
执行以下SQL，将拆分键值为(a=88,b=10)的数据，提取到一个单独的新分区：
ALTER TABLE tb1 EXTRACT TO PARTITION p_hot88 BY HOT VALUE(88,10);
- 分区迁移
继续沿用orders表，拆分键值为(a=88,b=10)的数据分区，单独迁移到一个独立的DN节点上，对应的DN名字为DN_VIP88。
ALTER TABLE orders MOVE PARTITIONS p_hot88 to 'DN_VIP88';
除了例子中的hash分区外，range/list等分区均支持类似的分裂、合并、迁移、重命名等管理。
更多内容可以参考文档：
- 表级分区变更语法
- PolarDB-X 热点优化系列 （二）：如何支持淘宝大卖家分区热点
Locality调度
PolarDB-X在V2.2.0版本中，提供一种更灵活的Locality定义能力，可以针对数据库的不同对象进行定义，从而去实现数据存储的有效管理。
- database对象，指定locality可以限制库下对应的表只分布在dn=polardbx-dn-0000
CREATE DATABASE db1 LOCALITY='dn=polardbx-dn-0000' MODE = 'auto';
- table对象，指定loality可以将不同的单表分布到不同的DN节点中
# 0号DN CREATE TABLE tableA(a int) single locality = 'dn=polardbx-dn-0000'; # 1号DN CREATE TABLE tableB(a int) single locality = 'dn=polardbx-dn-0001';
- partition对象，可以在分区级别进行精细化分区管理，实现细粒度的管理。
比如针对一张表，北京数据可以分布在3个DN节点、上海分布在2个DN节点，新疆和西藏共用一个DN节点
CREATE TABLE orders_region(
order_id int AUTO_INCREMENT primary key,
city varchar(64))
PARTITION BY LIST(city)
(
PARTITION p1 VALUES IN ('北京') LOCALITY = 'dn=polardbx-dn-beijin01,polardbx-dn-beijin02,polardbx-dn-beijin03',
PARTITION p2 VALUES IN ('上海') LOCALITY = 'dn=polardbx-dn-shanghai01,polardbx-dn-shanghai02',
PARTITION p3 VALUES IN ('新疆'、'西藏') LOCALITY = 'dn=polardbx-dn-west',
) ;
冷热数据分离
降本增效目前是数据库的一个主要技术方向，结合PolarDB-X V2.1.1提供的OSS提供冷热数据分离存储，以及分区和Locality调度，可以有如下的想象空间：
- DBA部署了PolarDB-X，对应服务器有SSD或者HDD的硬盘，通过定义分区locality，可以将不同的数据分区进行有效的成本化管理。比如按照range分区，将历史数据定期设置locality。
- DBA在阿里云环境上部署了PolarDB-X，并且开启了OSS对象存储，可以通过PolarDB-X自带的数据归档能力，通过TTL(Time-To-Live)分区能力，自动将数据归档到OSS存储中。
更多内容可以参考文档：
- 通过LOCALITY指定存储位置
- PolarDB-X On OSS QuickStart
- PolarDB-X on OSS: 冷热数据分离存储
06 开源相关配套工具
数据库的生态建设，除了MySQL内核和协议的兼容性外，最重要的就是配套的生态工具，比如常见的就是面向数据库的导入导出工具。
PolarDB-X 在V2.2.0版本中，开源了在分布式数据库金融标准中所使用的几款生态工具，帮助大家更好的使用PolarDB-X。
polardbx-backup
PolarDB-X Operator中提供了强一致的备份恢复，内部最重要的就是backup工具。我们选择基于Pecona XtraBuckup源码基础上，扩展了分布式数据库的部分特性：
- 兼容自研存储引擎Lizard，扩展了InnoDB的数据格式，增加了SCN/GCN的扩展槽位
- 兼容分布式事务日志，比如XA的prepare/commit事件、以及timestamp事件等
- 分布式一致性日志裁剪，多个物理文件因备份完成时间有差异，需要拉齐多个物理文件之间的事务一致性
更多详情，可以参考开源代码：https://github.com/ApsaraDB/polardbx-backup
benchmark-boot
PolarDB-X 提供了一款白屏化的数据库压测工具，融合了常见的sysbench、TPC-C、TPC-H的压测脚本，可以帮助大家快速完成数据库的性能测试。
工具特性：
- 提供内置benchmark压测脚本，并调整bechmark的最佳参数，比如sysbench/TPC-C/TPC-H
- 提供白屏化能力，支持一键安装、压测、日志、监控展示等
- 提供数据库的常见调优能力，比如参数管理、执行计划hint等
更多详情，可以参考文档：使用Benchmark Boot进行压测
batch-tool
Batch Tool工具是专为 PolarDB-X数据库提供数据导入导出服务的工具。 其结合分布式数据库特点实现一站式且高效地从文件导入、导出到文件以及跨库的离线数据迁移(MySQL / PolarDB-X)等功能， 在此基础上，还支持基于文本文件批量更新、删除等功能 (实验特性)。
导出方法对比
测试方法以PolarDB-X导出1000w行数据为例，数据量大概2GB左右。
| 方式 |
数据格式 |
文件大小 |
耗时 |
性能（行/每秒） |
性能（MB/S） |
| mysql -e命令 导出原始数据 |
原始数据格式 |
1998MB |
33.417s |
299248 |
59.8 |
| mysql -e命令导出csv格式 |
csv格式 |
1998MB |
34.126s |
293031 |
58.5 |
| mysqldump工具（net-buffer-length=10KB） |
sql语句格式 |
2064MB |
30.223s |
330873 |
68.3 |
| mysqldump工具（net-buffer-length=200KB） |
sql语句格式 |
2059MB |
32.783s |
305036 |
62.8 |
| batch tool工具文件数=32（分片数） |
csv格式 |
1998MB |
4.715s |
2120890 |
423.7 |
| batch tool工具文件数=1 |
csv格式 |
1998MB |
5.568s |
1795977 |
358.8 |
导入方法对比
测试方法以PolarDB-X导入1000w行数据为例，源数据是上一个测试中导出的数据，数据量大概2GB左右。
| 方式 |
数据格式 |
耗时 |
性能（行/每秒） |
性能（MB/S） |
| source语句（net-buffer-length=10KB） |
sql语句格式 |
10m24s |
16025 |
3.2 |
| source语句（net-buffer-length=200KB） |
sql语句格式 |
5m37s |
29673 |
5.9 |
| mysql命令导入（net-buffer-length=10KB） |
sql语句格式 |
10m27s |
15948 |
3.2 |
| mysql命令导入（net-buffer-length=200KB） |
sql语句格式 |
5m38s |
29585 |
5.9 |
| load data语句导入 |
原始数据格式 |
4m0s |
41666 |
8.3 |
| 程序导入batch-1000 thread-1 |
csv格式 |
5m40s |
29411 |
5.9 |
| 程序导入batch-1000 thread-32 |
csv格式 |
19s |
526315 |
105.3 |
| batch tool工具文件数=32（分片数） |
csv格式 |
19.836s |
504133 |
100.8 |
| batch tool工具文件数=1 |
csv格式 |
10.806s |
925411 |
185.1 |
数据导入导出工具小结：
- mysql -e/source/mysqldump，这类原生工具的原理上主要是单线程操作，性能差距不明显。比如，数据导入实际上是发送了Batch Insert语句，Batch size大小会影响导入性能，可以通过设置"net-buffer-length"参数进行调优，一般建议该参数不超过256K。
- load data语句虽然是单线程操作，但优化了数据文本的编码格式，性能优于mysql命令和source语句
- PolarDB-X原生的batch-tool工具支持多线程导入，且贴合PolarDB-X分布式多分片的操作方式，性能打到了最优
更多详情，可以参考文档：
- 使用Batch Tool工具导入导出数据
- 如何优化数据导入导出
07 轻量化部署和运维
PolarDB-X Operator 是一个基于 Kubernetes 的 PolarDB-X 集群管控系统，希望能在原生 Kubernetes 上提供完整的生命周期管理能力，满足用户的轻量化部署。
在PolarDB-X V2.2.0版本，我们进一步完善了众多面向生产运维的企业级功能。
强一致备份恢复
数据库通过备份恢复来保障数据安全，用户在运维误操作、或删库跑路等重大故障的情况下，可以采用备份集恢复的方式来快速恢复业务数据，减少业务损失。
分布式数据库在面向备份恢复场景中，有几方面的挑战：
- 数据存储普遍比较大，传统的单机备份模式受限于单机IO，备份速度是一个重大挑战。比如一个100TB的数据库，传统单机MySQL是300MB/s备份速度，差不多需要100个小时，需要通过分布式多机备份提升性能
- 数据备份的一致性，分布式数据库天然物理多节点分布，基于分布式的一致性快照做备份是基本诉求。传统基于分布式事务的SELECT查询获取一致性快照，采用逻辑数据导出的方式性能瓶颈比较明显，差不多是百MB/s，需要通过物理备份提升性能
PolarDB-X V2.2.0中采用了分布式多机+物理备份的方式，提供了强一致备份恢复的能力。 PolarDB-X是基于MySQL的原生分布式数据库，底下数据存储格式和MySQL接近，因此我们选择基于Pecona XtraBuckup定制实现PolarDB-X的物理备份，多个DN节点并行进行物理备份恢复，结合备份一致性算法处理分布式事务在物理备份过程中的差异数据。
详情可以参考文档：
- PolarDB-X Buckup工具 (基于XtraBuckup改造而来)
- PolarDB-X 是如何拯救误删数据的你（二）：备份恢复
参数模板
PolarDB-X 参考公有云数据库的最佳实践，提供了参数模板的管理能力，包括参数模板的创建、变更、批量应用等，可以有效帮助大家更好的管理在线数据库。
常见的参数模板，一般分为高安全模式和高性能模式，可以方便大家在数据库POC和生产参数之间做好差异化管理。
详情可以参考文档：
- 参数模版
容灾部署
PolarDB-X Operator结合K8S POD的调度能力，推出基于k8s selectors的集群部署规则。
首先，定义机房selector
selectors: - name: zone-a nodeSelector: nodeSelectorTerms: - matchExpressions: - key: topology.kubernetes.io/zone operator: In values: - cn-hangzhou-a - name: zone-b nodeSelector: nodeSelectorTerms: - matchExpressions: - key: topology.kubernetes.io/zone operator: In values: - cn-hangzhou-b - name: zone-c nodeSelector: nodeSelectorTerms: - matchExpressions: - key: topology.kubernetes.io/zone operator: In values: - cn-hangzhou-c
最后，定义集群部署规则 (每个机房均匀部署)
// 计算节点在A/B/C机房内均匀分布 cn: - name: zone-a replicas: 1 / 3 selector: reference: zone-a - name: zone-b replicas: 1 / 3 selector: reference: zone-b - name: zone-c replicas: 1 / 3 selector: reference: zone-c // 存储节点的三副本分别部署在A/B/C机房 dn: nodeSets: - name: cand-zone-a role: Candidate replicas: 1 selector: reference: zone-a - name: cand-zone-b role: Candidate replicas: 1 selector: reference: zone-b - name: log-zone-c role: Voter replicas: 1 selector: reference: zone-c
基于k8s灵活的yaml配置，大家可以发挥下想象空间：
- 同城3机房下，如何定义部署为5副本
- 两地三中心，如何定义部署，3副本 or 5副本
- 三地五中心，如何定义部署
详情可以参考文档：
- 集群拓扑规则-容灾部署
- 配置参数定义
更多更详细的文档，可以参考：PolarDB-X Operator运维指南
08 全面的性能优化和提升
PolarDB-X作为一款分布式数据库，除了企业级特性外，数据库的整体性能也一直是重要的演进方向，常规的benchmark场景优化，比如：RPC协议优化、分布式事务1PC优化等。
更小的起步规格
分布式数据库因为天生分布式多组件，导致起步的规格配置要求比较高，业务在发展初期并不需要16core64GB以上的大规格，更多还是在公有云主流的2core/4core/8core规格，在降本增效的大环境下，分布式数据库也需要贴合业务诉求，支持可小可大，实现更极致的线性扩展性。
目前PolarDB-X的最小起步规格情况：
- 支持在一个2c8g的ECS节点中部署单机版的PolarDB-X，包含完整的GMS/CN/DN/CDC组件，通过quick start的方式，方便大家快速体验分布式数据库的特性。
- 支持单节点2c8g的起步规格，目前PolarDB-X在公有云上支持的最小规格，提供高可用能力，2c8g的最小规格可以有效支撑sysbench read_write为1万+QPS、以及TPC-C 2万+的tpmC的，满足基本业务的诉求。
全方位的性能优化
分布式关系型数据库中，常见的benchmark主要是sysbench和TPC-C，用来评价OLTP场景的基本能力，这类benchmark的典型特征是偏TP类的小查询为主，重点关注吞吐量，核心的优化思路是从代码简化、网络传输、以及事务优化等方向。
PolarDB-X V2.2.0版本，在OLTP场景有3个核心优化：
- RPC协议优化，提升CN和DN之间的请求效率。主要在DN端实现基于原生epoll的网络执行框架，抛弃MySQL官方的x-protocol网络框架，在1000+的高并发下，新版RPC在查询性能提升60%以上
- 分布式事务1PC优化，重点优化单分片读写场景下的事务优化。比如，sysbench、TPC-C场景里有90%的比例都是单分片的读写操作，写入事务可以利用XA ONE PHASE COMMIT的1PC写入进行分布式事务优化，可以将传统2PC的3次RTT，优化为1次RTT。同时，针对简单主键的点查场景，可以利用HLC混合逻辑时钟的思路，在单个DN节点维护一个本地化时间戳，查询仅读取一个DN分片时可以不主动获取全局时间戳TSO，减少1次网络交互
- 存储引擎GCN缓存优化，分布式事务获取TSO后会写入存储引擎的GCN(Global Commit Number)，GCN的写入和读取是一个高频操作，在新版本中增加GCN系统缓存最近提交(或访问)的 GCN 事务信息，可大大降低通过UBA访问持久化事务信息带来的时间和空间开销，提升系统性能。
初步测试的高并发情况：3 * 16C64G (CN)、3 * 16c128g (DN)
| 场景 |
800并发 |
2000并发 |
| point_select |
357033.85 |
383850.57 |
| read_only |
132726.85 |
139712.47 |
| read_write |
77727.57 |
82000.08 |
| write_only |
39171.12 |
46697.96 |
除此之外，也在面向业务场景上做了更多能力上的提升，比如：冷数据归档的数据分析、以及数据跑批的并行DML、大事务优化等，因为篇幅的关系不再详述，欢迎大家交流。
更实时的CDC能力
PolarDB-X CDC组件，主要提供全局binlog的相关能力，基于CDC可以实现PolarDB-X与MySQL之间构建MySQl replication复制协议，同时兼容市面上流行的binlog解析工具，比如canal/flink cdc/maxwell等。
CDC的增量日志，比较重要的指标就是增量延迟 (数据写入数据库到下游拿到该记录的变更，对应的时间差称之增量延迟)，分布式数据库下需要考虑高并发下的增量延迟数据。
PolarDB-X V2.2.0中，在CDC同步性能实现翻倍，最大EPS能力从100w/s提升至200w/s，最大写入吞吐能力从250M/s提升至500M/s，核心性能指标如下（参考：PolarDB-X 全局Binlog解读之性能篇）：
| 测试场景 |
参考指标 |
增量延迟 (DelayTime) |
EPS (每秒binlog event数) |
BPS (每秒binlog字节数) |
| TPCC数据导入 |
8000仓/1200并发 |
700ms |
15w/s |
450M/s-500M/s |
| Sysbench数据导入 |
48Tables/48并发 |
1s |
210w/s |
170M/s |
| TPCC交易测试 |
100w tpmC |
500ms |
120w/s |
250M/s |
| TPCC交易测试 |
150w tpmC |
1s-4s |
170w/s |
350M/s |
| Sysbench oltp_write_only |
30w QPS |
600ms |
180w/s |
170M/s |
| 大事务 |
500M |
2s |
24w/s |
500M/s |
| 大事务 |
1G |
4.8s |
24w/s |
500M/s |
| 大事务 |
5G |
25s |
22w/s |
350M/s |
| 大事务 |
10G |
55s |
22w/s |
350M/s |
| 大事务 |
20G |
115s |
22w/s |
350M/s |
总结，CDC在16核的规格下，可以支持100万tpmC、sysbench oltp_write_only场景qps 30万、以及GB级大事务，满足增量延迟<1秒，可以满足绝大部分的业务诉求。未来，PolarDB-X也会支持binlog多流，实现更大千万级别规模的线性扩展。
结尾
PolarDB-X 是由阿里自主研发的原生MySQL分布式数据库，坚持以全内核开源的方式，保持开源的持续迭代。本次重磅发布V2.2.0版本，是一个重要的里程碑，重点推出符合分布式数据库金融标准下的企业级和国产化适配的产品能力，期望PolarDB-X未来能作为国内原生MySQL分布式数据库的开源领导者，持续做好开源！