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

分享人：陈宗志（暴跳）

摘要：本篇论文收录在 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》（点击文末「阅读原文」即可查阅论文原文）

👆👆👆

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

推荐阅读

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