云数据库实现计算存储分离，支持计算与存储的独立扩展，其用户还可以享受按量付费等特性。这使得基于云数据库的系统更加高效、灵活。因此，构建并使用云原生数据库的势头愈演愈烈。另一方面，云化存储服务已经是云的标准能力，存储侧提供兼容通用的文件接口，并且不对外暴露持久化、容错处理等复杂细节，其易用性和规模化带来的高性价比使得云存储成为了云上系统的第一选择。在通用云存储服务上构建云数据库，无疑是一种既能够享受规模化云存储红利，又能够通过可靠云存储服务实现降低维护成本、加速数据库开发周期的方案。然而，考虑到云存储和本地存储之间的特性差异，在将本地数据库迁移到云上构建云数据库时，如何有效使用云存储面临了许多挑战。对此，我们在论文里分析了基于B-tree和LSM-tree的存储引擎在云存储上部署时面临的挑战，并提出了一个优化框架CloudJump，以希望能够帮助数据库开发人员在基于云存储构建数据库时使系统更为高效。我们以云原生数据库PolarDB为案例，展示了一系列针对性优化，并将部分工作扩展应用到基于云存储的RocksDB上，以此来演示CloudJump的可用性。
更详细的内容请参阅论文《PolarDB-CloudJump:OptimizingCloudDatabaseForCloudStorage》。
背景
我们讨论的云存储主要基于弹性分布式块存储，云中其他类型的存储服务，例如基于对象的存储，不在本文的讨论范围内。共享云存储（如分布式块存储服务加分布式文件系统）可以作为多个计算节点的共享存储层，提供QoS（服务质量）保证、大容量、弹性和按量付费定价模型。对于大多数云厂商和云用户来说，拥有云存储服务比构建和维护裸机SSD集群更有吸引力。因此，与其为云本机数据库构建和优化专用存储服务，不如利用现有云存储服务构建云本机数据库，这是一种非常可行的选择。此外，随着云存储服务几乎实现了标准化，相应的开发、迁移变得更加快速。
图1展示了本地数据库（不含备份）与shared-storage云原生数据库的系统结构，AWSAurora首先引导了这种从本地数据库向shared-storage云原生数据库的迁移。它将数据库分为存储层和计算层，并可以独立扩展每一层。为了消除了传输数据页中产生的沉重的网络开销，它进一步定制了存储层，在数据页上应用重做日志，从而不再需要在两层之间传输数据页。无疑这种设计在云中提供了一种非标准存储服务，只能由Aurora的计算层使用。另一种方案是依赖标准化接口的云存储服务迁移或构建获得云数据库，这也是本文的研究目标。前面已经提到过，这样做的优势主要在于的可以实现系统的快速开发、平滑迁移、收纳标准化规模化存储服务的原有优势等。此外，特别是在我们项目（PolarDB）的硬件环境、已有背景下，兼顾服务可靠性和开发迭代需求，针对进行云存储服务特性进行性能优化是最迫切的第一步。
挑战与分析
云存储和本地SSD存储在带宽、延迟、弹性、容量等方面存在巨大差异，例如图2展示了在稳态条件下本地SSD与云存储I/O延时、带宽与工作线程关系，它们对数据库等设计有着巨大影响。此外，共享存储的架构特性也会对云存储带来影响，如多个节点之间的数据一致性增加了维护cache一致性开销。
通过系统实验、总结分析等，我们发现CloudJump面临以下技术挑战：
远程分布式存储集群的访问导致云存储服务的I/O延迟高；通常聚合I/O带宽未被充分利用；在具有本地存储的单机上运行良好但需要适应云存储而导致特性改变的传统设计，例如文件cache缓存；长链路导致各种数据库I/O操作之间的隔离度较低（例如，日志刷写与大量数据I/O的竞争）；云用户允许且可能使用非常大的单表文件（例如数十TB）而不进行数据切分，这加剧了I/O问题的影响。
针对不同的数据存储引擎，如基于B-tree和LSM-tree的存储引擎，这些特性差异会带来不同的性能差异，表1归纳总结了这些挑战及其对数据库设计的影响。其中有共性问题，如WAL路径写入变慢、共享存储（分布式文件系统）cache一致性代价等；也有个性问题，如B-tree结构在独占资源情况下做远程I/O、远程加剧I/OLSM-tree读放大影响等。
优化原则
CloudJump针对上述挑战，提出7条优化准则：
Thread-levelParallelism：例如依据I/O特性实验，采用（更）多线程的日志、数据I/O线程及异步I/O模型，将数据充分打散到多个存储节点上。Task-levelParallelism：例如对集中Logbuffer按PagePartition分片，实现并行写入并基于分片进行并行Recovery。ReduceremotereadandPrefetching：例如通过收集并聚合原分散meta至统一的superblock，将多个I/O合一实现fastvalidating；通过预读利用聚合读带宽、减少读任务延时；通过压缩、filter过滤减少读取数据量。与本地SSD上相比，这些技术在云存储上更能获得收益。Fine-grainedLockingandLock-freeDataStructures：云存储中较长的I/O延迟放大了同步开销，主要针对Update-in-place系统，实现无锁刷脏、无锁SMO等。ScatteringamongDistributedNodes：在云存储中，多个节点之间的分散访问可以利用更多的硬件资源，例如将单个大I/O并发分散至不同存储节点，充分利用聚合带宽。BypassingCaches：通过BypassingCaches来避免分布式文件系统的cachecoherence，并在DB层面优化I/O格式匹配存储最佳request格式。SchedulingPrioritizedI/OTasks：由于访问链路更长（如路径中存在更多的排队情况），不填I/O请求间的隔离性相对本地存储更低，因此需要在DB层面对不同I/O进行打标、调度优先级，例：优先WAL、预读分级。
实践案例
实践案例：PolarDB
PolarDB构建基于具有兼容Posix接口的分布式文件系统PolarFS，与Aurora一样采用计算存储分离架构，借助高速RDMA网络以及最新的块存储技术实现超低延迟和高可用能力能力。在PolarDB上，我们做了许多适配于分布式存储特性、符合CloudJump准则的性能优化，大幅提升了云原生数据库PolarDB的性能。
1.WAL写入优化
WAL（Writeaheadlog）写入是用于一致性和持久性的关键路径，事务的写入性能对logI/O的延迟非常敏感。原生InnoDB以MTR（Mini-Transaction）的粒度组织日志，并保有一个全局redo日志缓冲区。当一个MTR被提交时，它缓存的所有日志记录被追加到全局日志缓冲区，然后集中的顺序刷盘以保证持久化特性。这一传统集中日志模式在本地盘上工作良好，但使用云存储时，集中式日志的写入性能随着远程I/O时延变高而下降，进而影响事务写入性能。基于云存储的特性，我们提出了两个优化来提升WAL的写入性能：日志分片和（大）I/O任务并行打散。图片
Redo日志分片：InnoDB的redo采用的是PhysiologicalLogging的方式，大部分MTR针对单个的数据页（除部分特殊），页之间基本相互独立。如图5（左），我们将redo日志、redo缓冲区等按其修改的page进行分片（partition），分别写入不同的文件中，来支持并发写log（以及并发Recovery，并发物理复制等），从而在并发写友好的分布式文件系统上的获得写入性能优势。I/O任务并行打散：在云存储中，一个文件由多个chunk组成，根据chunk的分配策略，不同chunk很可能位于不同的存储节点中。我们将每个redo分片（partition）的文件进一步拆分为多个物理分片（split），如图5（右）所示，对于单个大logI/O任务（如group