开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第14天，点击查看活动详情

论文阅读: Constructing and Analyzing the LSM Compaction Design Space（六）

这是最后一章论文阅读，感谢作者做了大量实验（1200+），并对结论做了有效的分析，有些结果令人吃惊，它指导我们：

别把LSM系统的compaction策略当成黑盒的

有些明显较差的选择不要用(例如lv-2)

workload和compaction表现息息相关，例如Tiering in rocksdb，在数据集过大（超过8G）时，效果变差。

5.3 LSM调谐(即调整LSM option配置）的影响

在我们分析的最后部分，我们讨论了compactions与标准LSM调谐options的相互作用，如内存缓冲区大小、页面大小和大小比例。

我一直觉得前面的测试与实际场景不符，也就是内存缓冲区、blockCache大小与生产环境不一样，那么改变这些配置，前面的结论仍然有效吗？

O12：Tiering压缩随着写缓冲区大小的增加而Scale。 图8(m)显示，随着缓冲区大小的增加，所有compaction策略的平均compaction latency都会增加。缓冲区的大小决定了磁盘上文件的大小，更大的文件大小导致每次compaction都要移动更多的数据。另外，对于较大的文件大小，每个文件的过滤器大小随着散列时间的增加而增加，这就增加了compaction的延迟。此外，随着缓冲区大小的增加，Tier的平均compaction延迟比其他策略更好。图8(n)显示，随着缓冲区大小的增加，Tier的高尾部压缩延迟迅速趋于平稳，当缓冲区大小为64MB时，最终与eagerer compaction策略的延迟相交。

意思是Tiering Scaling较为平缓。但是请注意，在我实际测试中，发现rocksdb的自带Tiering compaction表现没有leveling好，具体原因是有时候flush->l0时，可能会遇到较大的sorted run需要合并，这导致了flush较慢，而进一步背压导致写延迟大。这里我在想，如何我们能将LSM分更多的层，flush->l0是否会遇到更小的sorted run？进而遭遇更少的write stall。我将进一步测试，感兴趣的朋友也可以去测测然后告诉我。

我们还在图8(o)中观察到，在部分压缩例程中，Old通过，经历了增加的写放大，而LO+1和LO+2始终提供较低的写放大 cation并保证可预测的ingestion性能。图8(p)显示，随着内存缓冲区大小的增加，平均点查询延迟超线性地增加。这是因为，对于较大的内存缓冲区，磁盘上的文件容纳了更多的页，因此，也就有更多的条目。因此，每个文件的索引块（每页一个索引）和过滤块（一般来说，每个条目10位）的综合大小与内存缓冲区的大小成比例增长。获取索引和过滤块的时间导致点查询的平均延迟大大增加。

所有压缩策略对改变页面大小的反应相似。 在这个实验中，我们改变了逻辑页的大小，这反过来又改变了每页的条目数量。页面大小越小，每个文件的页数就越大，这意味着需要更多的I/O来访问磁盘上的文件。例如，当页面大小从210B缩减到29B时，每个文件的页数doubles。随着页面大小的减少，每个文件的索引块大小也会增加，因为更多的页面需要被索引，这也是导致I/O增加的原因。因此，逻辑页大小的增加减少了平均压缩延迟，如图8（q）所示。在图8(r)中，我们观察到，随着页面大小的增加，每个文件的索引块的大小也在减少，平均来说，在每个点的查找中，为获取元数据块而进行的I/O次数较少。

杂项观察。 我们还改变了LSM的调整参数，如大小比、分配给Bloom过滤器的内存和块缓存的大小。我们观察到，改变这些旋钮的值会对不同的压缩策略产生类似的影响，因此，不会影响对任何特定设置的适当compaction策略的选择。

6 讨论

第3节详述的设计空间和第5节介绍的实验分析旨在为数据库研究人员和从业人员提供必要的洞察力，以便在为基于LSM的数据存储选择压缩策略时做出明智的决定。

了解你的LSM compaction。 LSM树被认为是 "写优化 "的，然而，在实践中，它们的性能在很大程度上取决于何时以及如何进行压缩。我们偏离了将compaction作为一个黑箱的概念，相反，我们将LSM压实形式化为四个基本compaction原语的集合。这使我们能够推理这些原语中的每一个，并浏览LSM压实设计空间，为工作负载或定制性能目标寻找合适的compaction策略。此外，提议的compaction设计空间提供了必要的直觉，即对现有引擎（如RocksDB）的简单修改（如数据移动策略或compaction粒度）如何成为实现重要的性能改进或成本效益。例如，RocksDB可以通过解耦每个原语的代码逻辑来模块化其压缩实现。这不仅会将原语为可调整的旋钮，而且会促进综合和测试为开发者的要求定制的新的压缩算法。

避免最坏的选择。 我们讨论了如何避免common的陷阱。例如，tiering通常被认为是写优化的变体，然而，我们表明它有很高的尾部延迟，使得它不适合于需要最坏情况下的性能保证的应用。另外，由于LO+2的性能不可预测，需要稳定性能的应用，应该避免使用它。另一方面，带有leveling的局部压缩策略，特别是混合Leveling（如1-Lvl）提供了最稳定的性能。

随着工作负载的变化进行调整。 在之前的工作中，tiering被用于写密集型的使用场景，而leveling则提供了更好的读取性能。然而，在实践中，在混合的HTAP风格的工作负载中，查找具有很强的时间定位性，并且基本上是在最近的热数据上执行。在这种情况下，块缓存经常被证明足以容纳工作集，并消除对读取查询的其他昂贵的优化需求。

探索新的compaction策略。 最终，这项工作为探索LSM压缩的巨大设计空间奠定了基础。我们在分析过程中形成的一个关键直觉是，与现有的设计相反，基于LSM的系统可以通过在不同层次上采用不同的压缩原语而获益，这取决于具体的工作负载和性能目标。我们实验过的压缩策略已经支持他们优化的各种指标，包括系统吞吐量、最坏情况下的延迟、读取、空间和写入放大，以及删除效率。利用所提出的设计空间，新的压缩策略可以被设计为新的或组合的优化目标。我们还设想，系统可以根据当前的环境和工作负载，自动选择压缩策略。

7 结论

基于LSM的引擎提供高效的ingestion性能和有竞争力的读取性能，同时能够管理各种优化目标，如写入和空间放大。一个关键的内部操作是LSM树工作的核心，即定期重新组织磁盘上的数据的compaction过程。

我们提出了LSM压实设计空间，使用四个主要的原语来定义compaction：（i）compaction触发器，（ii）数据布局，（iii）compaction颗粒度，以及（iv）数据移动策略。我们在这个设计空间中映射出现有的方法，我们选择了几个有代表性的政策来研究和分析它们对性能和其他指标的影响，包括写/空间放大和删除延迟。我们提出了大量的观察结果，并为LSM系统奠定了基础，该系统可以更灵活地浏览压缩的设计空间。