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架构形态多种多样,总结一下核心技术三要素&#x