ADOC: Automatically Harmonizing Dataflow Between Components in Log-Structured Key-Value Sto...——论文泛读

FAST 2023 Paper 论文阅读笔记整理

问题

基于Log-Structure Merge-tree（LSM-tree）的键值（KV）系统被广泛部署。LSM-KV系统普遍存在的问题是写入停顿，指的是在大量写入压力下突然性能下降。先前的研究将写入停顿归因于资源短缺或调度问题。

图1显示了RocksDB在各种存储设备上运行写密集型工作负载的结果。写停顿是普遍的，发生在所有类型的设备上，但触发条件不同；写停顿强烈依赖于设备，其持续时间和性能下降率受到各种因素的影响，如设备类型和写强度。

现有方法局限性

现有方法任务写停顿的原因有三种：

• Memtable（MT）停顿：当内存组件变满时发生此停顿。例如，RocksDB将Memtables的数量设置为2，当两者都填满时，系统输入将被简单地停止，导致停顿。这被认为是写入停顿最常见的情况[17,41,45]。

• Level 0-Level 1 Compaction（L0）停顿：当L0文件的数量达到设置的阈值时，LSM-KVs将减缓或甚至停止输入流，导致停顿。在RocksDB中，默认的减速阈值为20，在36时输入流会停止。这种控制首次出现在LevelDB中[17]，但已被大多数随后使用相似压实策略的实现所采用[4, 25, 49]。

• Pending Input Size（PS）停顿：当压缩作业的待处理输入大小超过一定阈值时，LSM-KVs也会减缓或停止系统。请注意，待处理输入大小不仅指SSTable中重复和过时的条目，还包括所有处于待处理状态的SSTable中的条目。在RocksDB中，用于减速和停止系统的默认待处理压缩输入大小阈值分别为64GB和128GB。先前的研究将这个值称为“压缩待处理字节数”[25, 58]，而在本研究中，我们使用术语“冗余数据”代替。这种控制的目的是减少总冗余数据[15, 26, 28]，或在深层次进行压实作业时避免磁盘带宽突发[45, 50]。

本文根据实验发现现有结论并不普遍适用

本文方法

在本文中，我们通过评估RocksDB，并使用各种存储设备对写入停顿的原因进行了系统研究，展示了侧重于个别方面的结论虽然有效，但并不普遍适用。通过对RocksDB的深入审查和进一步实验证明，数据溢出是LSM-KV系统中一个或多个组件迅速扩展的原因，这是由于数据流突然涌入其中一个组件而导致的。我们认为通过平衡和协调组件之间的数据流，我们将能够减少数据溢出，从而减少写入停顿。

我们提出了一个名为ADOC（Automatic Data Overflow Control）的调整框架，该框架自动调整系统配置：线程数和批处理大小，以最小化RocksDB中的数据溢出。ADOC具有以下四个关键特性：1）通过平衡使用资源来减少写暂停，从而提高性能；2） 它是一种设备透明的解决方案，可以提高各种设备的性能；3） 它是一个不需要人工干预的自动协调系统，4）它是高度可移植的，因为它可以通过LSM-KV系统的本地接口实现。

开源代码：https://github.com/supermt/FEAT_7.11

我们对RocksDB进行的广泛实验证明，与自动调整的RocksDB相比，ADOC将写入停顿的持续时间减少了高达87.9％，性能提高了高达322.8％。与手动优化的最先进的SILK相比，ADOC在我们使用的合成写入密集型工作负载中实现了高达66％的吞吐量提高，同时对于真实的YCSB工作负载实现了可比较的性能。然而，SILK必须使用平均20％以上的DRAM。

总结

对LSM-KV中写停顿现象进行分析，发现之前的分析原因是有效的，但并不普遍适用。通过实验分析写停顿的原因是数据溢出，指由于数据流入其中一个组件而导致LSM-KV系统中一个或多个组件迅速扩展。提出了ADOC（自动数据溢出控制）的调整框架，在组件之间平衡和协调数据流，以调整系统配置：线程数和批处理大小，而不是简单地等待溢出的数据按默认方式消耗。从而缓解写停顿的问题。