云原生分布式数据库PolarDB技术深度解密

一、基础设施和数据库的演化趋势

一 数据库演化趋势

数据库可以分为三个时代 第一个时代是IT时代的商业数据库时代 经典产品有Oracle和DB2 计算的基础设施是IOE 主要客户是大中型企业。

第二个时代是互联网时代的开源数据库 当时许多公司的数据库主要是LAMP 目前行业的许多数据库技术也是从这个时代积累而来。

第三个时代是万物互联时代的云原生数据库 有了共享云存储 做了存储计算分离 以前高端的硬件慢慢在普适化。

无论是部署量还是规模上 开源生态正在超越商业数据库的生态。目前不断涌现的数据库 通常都会兼容开源生态或者自己开源。

数据库的发展演进从最初在云下 后来慢慢到了云上 如今又有走向云下的趋势。我们发现 原来商业数据库的一些东西又回来了 如很多大客户喜欢的特性 是开源数据库不具备 而商业数据库所擅长的。如何在开源数据库上做好企业级特性 我们在这上面做了大量的工作。

二 基础设施演化趋势

上图为阿里云数据库基础设施演化趋势 从最初的On-Premises机房 到如今的公共云。为了更好地服务客户 阿里云在公共云的基础上 衍生出了四种形态。

本地云

1 公共云控制台

2 网络互通

3 新购 利旧

4 弹性极强

从本质上看 公共云像一个大机房 本地云是一个小的机房 小机房和大机房体验基本一致。

专有云

1 独立控制台(飞天标准底座)

2 网络可隔离 可控性更强

3 官方 伙伴托管

4 100~1000台 弹性强

专有云规模较大一些 和公共云网络是弱连接 通常情况下选择这种形式的客户对安全性保密性要求比较高。

敏捷专有云

1 DBStack(飞天敏捷底座)

2 网络可隔离 产品可选配

3 官方 伙伴托管

4 10~100台 弹性适中

阿里云有一款产品叫DBStack 飞天敏捷底座 可以脱离硬件存在。

比如客户要做去O 去完之后剩下的硬件可以直接部署DBStack(飞天敏捷底座) 上面运行RDS ADB ADS等 是一套完整的数据解决方案。

被集成

1 第三方集成(无底座)

2 嵌入客户解决方案

3 软件/软硬一体

4 官方 伙伴托管

通过线下集成商的分发渠道 我们可以将数据库技术包装在他们的产品中 直接对外分发。比如像超图 其内核能力就是阿里云的产品PolarDB。

二、PolarDB企业级特性解读

一 PolarDB-X 2.0整体架构

PolarDB-X是PolarDB的分布式版 我们在2021年3月份对PolarDB-X进行架构升级到2.0版本 升级后的架构如下所示。

PolarDB-X 2.0整体架构图

PolarDB-X 2.0主要有以下特性

1. 元数据服务 Global Meta Service GMS

提供全局授时服务(TSO)
维护Table/Schema、Statistic等Meta信息
维护账号、权限等安全信息

2. 存储节点 Date Node DN

基于多数派Paxos共识协议的高可靠存储
处理分布式MVCC事务的可见性判断

3. 计算节点 Compute Node CN

基于无状态的SQL引擎提供分布式路由和计算
处理分布式事务的2PC协调、全局索引维护等

4. 日志节点 Change Data Capture CDC

提供兼容MySQL生态的binlog协议和数据格式
提供兼容MySQL Replication主从复制的交互

要特别强调的是 在一个分布式数据库里面Binlog分为许多份 日志节点可以和全局授时服务相结合 把分布式的多份Binlog合成一份 这对MySQL用户非常友好。

二 PolarDB-X 2.0强一致MVCC事务

有了全局授时时钟之后可以做全局强一致MVCC事务。虽然它是一个分布式的数据库 但是无论从性能、产品体验还是生态工具上 使用体验接近于一个单机MySQL 而且可以无限线性扩展。

三 PolarDB-X 2.0 CDC

在2.0架构之前 很多客户抱怨在云上用PolarDB时 如果要把日志同步到线下机房做数据分析 无法搭起链路。

2.0架构上线之后这个问题可以通过CDC特性解决。只要一条网络链路 就能把数据全部同步 并且我们做了一个聚合 保证全局事务的顺序。

CDC特性如下

1. 全局 binlog

兼容事务 (分布式事务全局排序)

例 基于TraceId、TSO信息对Binlog全局排序

兼容分布式DDL

例 可支持DDL同步到下游 比如ADB

兼容分布式扩缩容

例 屏蔽内部分片迁移、广播表、索引等数据干扰

2. 主备 Replication

兼容MySQL生态的主备复制

例 MySQL作为PolarDB-X的备库 支持数据回流能力

兼容DTS的上下游生态

例 打通Oracle/DB2/PolarDB/ADB等数据库生态

如上图所示 PolarDB-X的两个集群可以互相做主备 MySQL和PolarDB-X也可以做主备切换 具备很好的生态兼容性。

四 PolarDB HTAP

在过去的这段时间 PolarDB在分析能力上也做了很大的提升 下方是PolarDB单机并行的架构图。

并行查询特性如下

通过分割B Tree来分配任务 每个线程(Worker)关注一部分分区。
通常上层Server层计算的线程数远远小于分区数 使得每个线程可以得到的数据计算分区很多。
“Fast”的worker线程可以处理更多的较小数据分区 “slow”的线程处理较少的但是比较大的数据分区 从而达到整体计算无差别。
每个工作线程可以自动去获取下一个要处理的数据分区 Round Robin模式 。

上方讲的是单机的SMP 我们还在多机上并行执行 如下图所示。

目前单机的加速效果将近15倍 如果上方的MTP这个架构出来 整体还会有一个更大的提升。

TPCH 加速效果显著

TPCH 100G 32core/512G (BP 170 GB) (32 并发 vs 不开并发)
TPCH 100% SQL 可被加速 73%加速比超过8倍 总加速近15倍。

五 PolarDB Global Database

如上图所示 PolarDB Global Database分为三个地方 张北、香港和美国硅谷。

PolarDB Global Database四大特性

全球部署 Global Deployment

数据跨地域同步 提供全球跨地域的容灾能力。RPO 0? SLA为99.99%

就近读加速 Accelerate by Reading the Nearest Node

读操作就近读取数据 适合不同地域读多写少的场景。

多通道物理复制 Multi-Channel Physical Replication

提供数据跨地域的高速同步 大压力场景下全球同步延迟确保在2秒以内。

多点跨地域写 Write to Multi Zones and Regions

提供多点跨地域写功能 提供业务的多地部署能力。

传统的MySQL部署三地模式一般用Binlog同步 Binlong存在的问题是遇到大事务容易卡住。PolarDB用Redo做物理复制 而且它是多通道的 可以做并行复制与延迟同步。延迟同步的好处是存在更改余地 比如和美国硅谷做近实时同步 和香港做半天延迟同步 防止删库等误操作 安全系数非常高。

六 PolarDB 热备

PolarDB还有一个非常好的特性 那就是PolarDB热备。

HRO特性

1 内存和Redo实时同步

2 主备切换秒级

3 升降级切换不可用时间控制在5秒以下

4 通过voting disk 进行主动故障切换。

Oracle的Rock主要是做高可用 一般超过两个节点的用户很少 四个节点更是凤毛麟角。通常情况下 用户的两个节点一个做写的负载均衡 还有一个做高可用 这在电信场景里面非常常见。

PolarDB的为写节点提供热备 这个热备会同步Buffer Pool 然后会把内存和Redo实时同步 在发生切换时 可以在极短的时间完成 保证业务稳定运行。

七 PolarDB 多租户

PolarDB还有一个特性是多租户多写。

多写的意思是每个写节点负责不同的表 比如在某个SaaS场景中 一个数据库服务100个用户 这100个用户的数据互相隔离 每个用户可读可写 每个写节点之间的数据互不干扰 这种场景用一个PolarDB就可以支撑。

多租户特性

1 多租户多写 multi-tenant multi-master 2 支持128个RW 3 支持non-conflict multi-master write 4 Partition/table/schema binds to RW 5 库表写入点秒级切换。

八 PolarDB 混合云-DBStack

阿里云有个混合云叫DBStack 如上图所示 它既支持X86也支持ARM 能做国产化全加密一体机。

上图是运行在国产化全加密一体机上的管控平台 它和公有云的体验几乎是一致的 但是更小更清亮。

三、Roadmap

存储计算分离是这几年数据库发展中最重要的一个变化。近年来成功的商业数据库 如Snowflake、Oracle、RDS等 全部是存储计算分离的。

未来的PolarDB会做Share Nothing Everything 一体化 架构图如下所示。

PolarDB Share Nothing Everything 一体化架构优势

Leverage PolarDB已有基础设施 存储、管控、监控、审计等功能共享
Share Nothing基于存储计算分离架构 无限扩展 并且无需数据迁移 并可彻底消除传统分布式Data Skew问题
Share Everything场景写瓶颈大幅缓解 多节点可写
无缝升级 可由单表直接转化成分布式表 一键操作即可完成分布式改造(alter table to partition_table by hash_range ***)
两种场景都有极强高可用性
兼容性和扩展性都能完美支持 在兼顾legacy业务的同时帮助客户完成数字化转型升级。

本文转自网络，原文链接：https://developer.aliyun.com/article/785098
本站部分内容转载于网络，版权归原作者所有，转载之目的在于传播更多优秀技术内容，如有侵权请联系QQ/微信：153890879删除，谢谢！