查看原文
其他

内附原文|论文解读:PolarDB计算存储分离架构性能优化之路

陈宗志(暴跳) 阿里云瑶池数据库 2023-04-17

分享人:陈宗志(暴跳)

摘要:本篇论文收录在 VLDB 2022,介绍了云原生数据库PolarDB在计算存储分离架构下遇到的性能挑战,分析了云存储相对于传统本地存储的工作特性差异及其根因,讨论了将各类存储引擎部署至云存储上时所会遇到的问题挑战,并提出了统一的优化框架 CloudJump。最后通过实验证明优化框架CloudJump适用于PolarDB,也适用于 RocksDB。

01. 背景

1.计算存储分离架构云数据库存在的问题

下图左边是本地集中式数据库,右边是计算存储分离架构数据库。本地数据库通过本机 Cache 到 Local I/O再到 Local SSDs;计算存储分离架构数据库:在计算存储分离架构下会带来网络开销,同时也会产生其他存储副本。

计算存储分离架构带来的网络延迟、I/O 延迟、Pattern 改变等问题,在 PolarDB 上也同样存在,并且还未被研究和解决。

2.项目目标

a. 计算存储分离云数据库的优势:

  • 海量存储能力;

  • 快速弹性能力;

  • 服务高可用,数据安全可靠;

  • 极致性能;

  • Serverless、pay-as-you-go;

b. 云端成熟的云存储服务的优势:

  • 海量存储能力;

  • 数据持久化、服务高可用;

  • 聚合 I/O 吞吐性能高;

  • 用量可选,弹性计费;
因此,本次项目的目标,是在通用云存储服务上构建云/云原生数据库能力,避免云存储特性差异化(于本地存储) ,高延迟、低隔离限制等。
  • 充分运用规模化云存储能力;

  • 存储侧不暴露容错等复杂细节;

  • 减少维护成本、加速数据库开发周期。

3.早期实验发现

云存储和本地 SSD 存储在带宽、延迟、弹性、容量等方面存在巨大差异。

下图对比了在稳态条件下,本地 SSD 与云存储在 I/O 延时、吞吐量与工作线程的关系,其中紫色线是本地 SSD,橙色线是云存储,灰色线是云存储打撒 I/O。

左图是 I/O 延迟与工作线程的关系,可以看到,本地 SSD 的 I/O 延迟远优于云存储;

右图是吞吐量和工作线程的关系,可以看到,云存储的吞吐量比本地 SSD 要高。

通过线上经验和系统实验发现以下挑战:
  • 由于远端访问的高时延,采用云存储后出现慢 SQL;

  • I/O 时延大、聚合带宽高;

  • 多节点一致性造成数据库网络带宽利用率低;

  • I/O 隔离性问题导致刷脏时 WAL 写入性能下降。

4.云存储差异化特性带来的挑战

下图中的表格总结了上述挑战对数据库设计的影响。对比基于 B-tree 结构(Update-in-place)和基于LSM-tree 结构(Append-only),其中有共性问题,如 WAL 路径写入变慢、共享存储(分布式文件系统)cache 一致性代价等;也有个性问题,如 B-tree 结构在独占资源情况下做远程 I/O、远程加剧 I/O LSM-tree 读放大影响等。

02. 设计思考

前面论述了本地盘和云盘在延迟、带宽、防护模式、隔离等方面的区别,我们希望设计一个优化框架CloudJump,可以将本地盘 InnoDB 存储引擎优化成面向云盘设计的存储引擎,并同时适用于 B-tree 和LSM-tree。

基于上述挑战以及云盘的特征,CloudJump提出7条优化准则:

1.Thread-level Parallelism

依据 I/O 特性实验,采用(更)多线程的日志、数据 I/O 线程及多队列异步 I/O 模型,将数据打散到多个存储节点上,充分利用多个存储节点的 I/O 能力;

2. Task-level Parallelism
对原集中 Log buffer 按 Page Partition 分片,多任务并行写入;
基于分片进行并发 Recovery,从而规避云盘 I/O 延迟高的问题;
3. Reduce remote read and Prefetching
通过收集并聚合原分散 meta 至统一的 superblock,实现 fast validating(fast startup);
通过预读利用聚合读带宽,减少读任务延时;
通过压缩、filter 过滤,减少读取数据量;

与本地 SSD 上相比,这些技术在云存储上更能获得收益;

4. Fine-grained Locking and Lock-free Data Structures

云存储中较长的 I/O 延迟放大了同步开销,主要针对 B-tree,实现无锁刷脏、无锁 SMO 等;

5. Scattering among Distributed Nodes

在云存储中,多个节点之间的分散访问可以利用更多的硬件资源,例如将单个大 I/O 并发分散至不同存储节点 ,充分利用聚合带宽的能力;

6. Bypassing Caches

通过 Bypassing Caches 来避免分布式文件系统的 cache coherence,并在 DB 层面优化 I/O 格式,匹配存储最佳 request 格式;

7. Scheduling Prioritized I/O Tasks

由于访问链路更长(如路径中存在更多的排队情况),不同 I/O 请求间的隔离性相对本地存储更低,因此需要在 DB 层面对不同 I/O 进行打标、调度优先级,例:优先 WAL、预读分级。

03. 案例实践:PolarDB

优化后的 PolarDB 架构如下图所示,左上是读写节点(RW node),右上是只读节点(RO node),下面是共享存储(云存储)。

基于 PolarDB 框架,我们做了许多适配分布式存储特性、同时符合上述优化准则的性能优化,大幅提升了云原生数据库 PolarDB 的性能。

1.WAL写入优化

下图左边的架构是针对本地盘的 WAL I/O设计,将多个 mlog 集中拷贝到 redo 的日志缓冲区(Buffer)中,然后顺序向下写入文件(File),这种单线程顺序的写入的方式在本地盘表现良好,但是对于云存储,这种方式的问题在于:
  • WAL 写入性能优于 I/O 延迟高而降低;

  • I/O 串行化,带宽利用率低;

优化内容:

▶︎日志缓冲区(Log buffer)分片,写入并行化;

将 redo 的日志缓冲区按其修改的 page 进行分片(partition),分别写入不同的文件中,支持并发写 log,从而在适合并发写入的分布式文件系统上的获得写入性能优势;

▶︎异步多任务线程,带宽利用率高;

写入不同的文件就会映射到不同的存储节点,利用存储多节点的 I/O 能力可以提升带宽利用率;

▶︎打散 I/O,利用分布式存储分布写性能。

下图左将redo日志缓冲区分片:Log Buffer1&2&3,其中绿色的小方块代表已经写满的连续的 redo 日志,旁边的小方块是有缓冲区的日志,橙色方块是 pending 日志,需要将绿色和橙色块之间的部分填满,形成连续的 redo 日志后,再继续往下写。

下图右是对于单个大 log I/O任务(如 group commit、BLOB record 等),log writer 会将I/O切片,并且并发的分发 I/O 请求至不同 split。

2.快速恢复

在创建、修改文件时,将必要的元信息集中记录在一个 superblock 中,在启动时仅扫描元数据块文件。因此,减少了启动扫描过程中远程 I/O 的访问开销。

3.预读取

有效的预读取,能够充分利用聚合读带宽,减少读任务延时。
如下图所示,如果连续访问 4 个 page 就会触发异步并发预读,这 4 个 page 属于逻辑上连续但物理上非连续的,将它们提前读取到BP,以减少读任务延迟。
另外,对于具有二级索引和非覆盖列的回表操作,采用 Batched Key 预读。

4.并行恢复

基于 Page Partition 分片,多任务并发恢复/日志解析和申请。

5.锁优化

在 InnoDB 里面, 全局的 index latch 存在,会导致同一时刻在 B-tree 中只有一个 SMO 能够发生;另外,锁同步期间 index 上其他可能 I/O 操作无法并行,存储带宽利用率较低。
锁优化将去除 SMO 等操作时的冗余锁,提升内存、I/O 操作的并发度。
Shadow Page

首先对当前 page 构建内存副本,构建好内存副本后原有 page 的 sx 锁被释放,然后用这个 shadow page内容去做刷脏及相关刷写信息更新。

优化 page I/O 的长时间锁占用,将长占有锁(remote I/O时长)转换为短占有锁(内存复制时长),提升操作并发度。

6. I/O对齐和调度

a. 针对分布文件 BypassCache 导致的直接 I/O

  • 对齐最优化的 I/O offset&length,加速 directI/O;

  • 去除无效 I/O 合并,发挥随机写特性;

  • 多异步 I/O 任务队列,充分并行化,发挥带宽优势。
b. 针对 Remoteaccess 路径长、不同 I/O 隔离性低
  • I/O 优先级调度,优先关键 I/O,消除低隔离影响。

7.数据测试结果

将 MySQL 分别运行在 PolarStore 和本地盘,以及优化后的 PolarDB 进行性能对比,从下面 Figure 10图中可以看到,优化后的 PolarDB 在 CPU-bound, I/O-bound sysbench, TPC-C 等各个场景下,都表现出明显的性能优势。

图11是不同的优化策略在 CPU-bound(只写、读写), I/O-bound(只写、读写), TPC-C 场景下的性能提升的力度和大小,可以看到优化策略在 CPU-bound场景下,性能普遍提升比较明显。

图12是不同优化策略在 WAL 加速方面的表现。

另外,还测试了云存储优化的 PolarDB 运行在 StorageX,、ESSD 等其他云存储上的性能, 发现均能获得非常好的性能提升。如下表所示,对比这个云存储,在延迟性能上,PolarStore 的延迟最低。

04. 实践案例:RocksDB

我们还将设计框架及部分优化策略拓展到基于云存储的 RocksDB 上,以验证其通用性。

1.优化后的RocksDB框架

下图是优化后的 RocksDB 架构图,最上层是 WAL 日志、Compaction 和 Flush,到 I/O 对齐、打标和调度,通过多 I/O 队列将 I/O 任务并行打散到云存储的 Log 和 Data 上。

2.数据测试结果

我们将以下优化方法移植到 RocksDB 上,获得与设计框架分析一致的性能收益:
  • Scattered & Partitioned Global Log;

  • Multi-queue Scatter I/O with Schedule;

  • Direct I/O Alignment;

下图是 RocksDB 在优化前后各种性能的对比,柱状图最左边的是 Baseline,可以看到在不同场景下,RocksDB 的优化性能有不同的表现。

05. 总结

在这项论文工作中,主要分析了云存储的性能特征,将它们与本地 SSD 存储进行了比较,总结了它们对B-tree 和 LSM-tree 类数据库存储引擎设计的影响,并推导出了一个框架 CloudJump 来指导本地存储引擎迁移到云存储的适配和优化。并通过 PolarDB, RocksDB 两个具体 Case 展示优化带来的收益。

详细内容请参阅论文《CloudJump: Optimizing Cloud Database For Cloud Storage》(点击文末「阅读原文」即可查阅论文原文)
👆👆👆

 点击观看「论文解读」直播回放 

推荐阅读


点击「阅读原文」查阅 论文原文

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存