分享人：陈宗志（暴跳）
摘要：本篇论文收录在 VLDB 2022，介绍了云原生数据库PolarDB在计算存储分离架构下遇到的性能挑战，分析了云存储相对于传统本地存储的工作特性差异及其根因，讨论了将各类存储引擎部署至云存储上时所会遇到的问题挑战，并提出了统一的优化框架 CloudJump。最后通过实验证明优化框架CloudJump适用于PolarDB，也适用于 RocksDB。
一. 背景
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 读放大影响等。
二. 设计思考
前面论述了本地盘和云盘在延迟、带宽、防护模式、隔离等方面的区别，我们希望设计一个优化框架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、预读分级。
三. 案例实践：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 的延迟最低。
四. 实践案例：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 的优化性能有不同的表现。
五. 总结
在这项论文工作中，主要分析了云存储的性能特征，将它们与本地 SSD 存储进行了比较，总结了它们对B-tree 和 LSM-tree 类数据库存储引擎设计的影响，并推导出了一个框架 CloudJump 来指导本地存储引擎迁移到云存储的适配和优化。并通过 PolarDB, RocksDB 两个具体 Case 展示优化带来的收益。
详细内容请参阅论文《CloudJump: Optimizing Cloud Database For Cloud Storage》（https://www.vldb.org/pvldb/vol15/p3432-chen.pdf）