FAST 2021 Paper 论文阅读笔记整理

问题

键值（KV）存储支持许多关键的应用和服务。它们在内存中执行快速处理，但通常受到I/O性能的限制。最近出现的高速NVMe SSD推动了新KV系统设计，以利用其低延迟和高带宽。

挑战

当前基于LSM树的KV存储未能充分发挥NVMe SSD的全部潜力。例如，在Optane P4800X上部署RocksDB，相对于SATA SSD，对于50%写入的工作负载，吞吐量仅提高了23.58%。

• 常见KV存储设计的I/O路径，未充分利用超低延迟的NVMe SSD，特别是对于小写入。例如，通过ext4进行操作的延迟比通过Intel SPDK接口[37]高6.8-12.4倍。这特别影响预写式日志（WAL）[52]，WAL对数据耐久性和事务的原子性至关重要，它位于写入的关键路径上，容易成为瓶颈[31]。

• 现有的KV请求处理假定设备速度较慢，工作流设计嵌入了高软件开销，如果切换到基于轮询的快速I/O，则浪费CPU周期。

• 新的NVMe接口带有访问限制（例如需要将整个设备绑定为SPDK访问，或者将线程绑定在核心上）。这使得KV设计在利用高端SSD进行不同类型的KV I/O时变得更加复杂，并使同步请求处理变得低效。

• 像Optane这样的顶级SSD对于大规模部署来说成本较高。由于大规模、写入密集型的KV存储不可避免地包含大量的冷数据，将所有数据托管在这些相对较小且昂贵的设备上，可能超出预算。

本文方法

我们提出了SpanDB，一种基于LSM树的KV存储，将流行的RocksDB系统调整为利用高速SSD的选择性部署。

• 通过整合一个相对较小但速度较快的磁盘（SD），扩展了对最新数据的写入和读取的处理，同时在一个或多个更大更便宜的容量磁盘（CD）上扩展数据存储。将大部分数据托管在更便宜且更大的SSD上，将LSM树的顶层移到更小更快的NVMe SSD上。

• 通过SPDK实现快速且并行的访问，以更好地利用SD，绕过Linux I/O堆栈，优化高速的WAL写入。将预写式日志（WAL）移到更小更快的NVMe SSD上。

• 设计了基于轮询I/O的异步请求处理流水线，去除了不必要的同步，将I/O等待与内存处理重叠，并自适应地协调前台/后台的I/O。

• 根据实际的KV工作负载战略性地和自适应地对数据进行分区，积极地利用CD的I/O资源，特别是带宽，以缓解写放大。

开源代码：https://github.com/SpanDB/SpanDB

评估显示，SpanDB同时提高了RocksDB的吞吐量高达8.8倍，并将其延迟降低了9.5-58.3%。与为高端SSD设计的KVell相比，SpanDB在更便宜的存储配置下实现了96-140%的吞吐量，延迟降低了2.3-21.6倍。

实验

实验环境：2个20核Xeon Gold 6248处理器，256GB DRAM，CentOS 7.7

数据集：YCSB[16]、LinkBench[6]

实验对比：吞吐量、平均延迟、尾延迟、CPU利用率

总结

针对NVMe SSD和SATA SSD结合的异构存储系统，优化基于LSM-tree的KV存储。作者提出将大部分数据存储在SATA SSD上，将LSM树的顶层和预写式日志（WAL）存储在NVMe SSD上；通过SPDK实现快速且并行的访问，绕过Linux I/O堆栈，优化WAL写入；设计基于轮询I/O的异步请求处理流水线，去除了不必要的同步，将I/O等待与内存处理重叠，并自适应地协调前台/后台的I/O；根据KV工作负载自适应地对数据分区，利用SATA SSD的带宽缓解写放大。