开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第13天，点击查看活动详情
论文阅读: Constructing and Analyzing the LSM Compaction Design Space（五）
接下来，我们分析了工作负载对压缩的影响，本篇有大量的图表重新编辑和讨论，作者喜欢所有图片一个大图表非常难看，我们想知道工作负载（也就是读、写、删除请求的比例下，不同的compact策略是否表现不同，这在平时我们也有类似困扰。请注意，本篇论文的测试场景是比较极端的，关闭了wal，blockcache设置的较小，writebuffer也没有精心设置。
5.2.1 变化的ingestion分布
在这个实验中，我们使用了一个交错的工作负载，它改变了ingestion分布（Zipfian，s=1.0，标准偏差为34%的正常分布），以及uniform的点查分布。我们使用Zipfian分布的一个变种，称为PrefixZipfian，其中key前缀遵循Zipfian分布，而后缀是统一生成的。这使我们能够避免在工作负载中出现太多的更新。
ingestion性能与插入分布无关。
图 4(a)、6(a)和6(e)显示，对于分别使用uniform、PrefixZipf和正常分布生成的（唯一的）仅有插入的工作负载，compaction期间的总数据移动几乎是相同的分布。
此外，我们观察到平均和长尾compaction延迟与ingestion分布无关（图4（c）、6（b）和6（f）也几乎相同）。只要数据分布不随时间变化，每个级别的条目是相同的分布，不同level之间的重叠保持不变。 因此，对于一个仅有ingestion量的工作负载，数据分布并不影响压缩策略的选择。
O7：插入分布影响点查询。
图6(c)显示，虽然tiering对于点查询的延迟略高，但对于工作负载中任何一部分非空查询（所有的α值），压缩策略的相对性能都很接近。
这是因为当空查询从键域中统一抽取时，逐级的元数据和索引块有助于完全避免绝大多数不必要的磁盘访问（包括获取索引或过滤块)。
在图6(d)中，我们观察到，在α=0甚至α=0.4的情况下，读取放大率与图4(f)（均匀ingestion）中的放大率保持一致。然而，对于α=0.8，图6(d)中的读取放大率比均匀插入的情况小65%-75%。为获取过滤块所进行的I/O接近于零。
这表明，当在一个预先填充了PrefixZipf插入的数据库上执行空查询重的工作负载时，所有的压缩策略都表现得同样好。相比之下，当在一个预装了正常ingestion的数据库上执行查询时，点查询性能（图6(g)）很大程度上类似于它的等效均衡（resembles its uniform equivalent，不知如何翻译(todo）（图4(h)），因为ingestion-偏度是相当的。
在α值较大的情况下，正态分布的Insert序列比uniform 分布的过滤器和索引块命中率要高10%∼，这解释了图6(h)中显示的相对较低的读放大。
该图还显示了案例1在α=0和α=0.2的情况下，LO+2的行为是不可预测的。我们观察到LO+2的这种不可预测行为的实例较多，这可能解释了为什么它很少被用于新的LSM存储。再次，对于compaction和尾部查找性能，1-Lvl提供高度可预测的性能。
5.2.2 改变点查询分布。
在这个实验中，我们将点查询分布改为Zipfian和正态分布，同时保持ingestion分布为均匀分布。点查询的分布极大地影响了性能。如图7(a)所示，在均匀填充的数据上进行Zipfian点查询会导致所有压缩策略的低延迟点查询，因为在所有情况下，块缓存对填充的 lar块是足够的，图7(b)中的低读放大也表明了这一点。另一方面，当点查遵循正态分布时，部分压缩策略LO+1和LO+2在所有其他方法中占主导地位，而Tier被发现比所有其他方法都要慢，如图7（c）和7（d）所示。
TA 五：* 对于倾斜的ingestion/查询，所有的压缩策略在查询性能方面有类似的表现。* 虽然ingestion分布不影响其性能，但由于块缓存和文件元数据的原因，严重倾斜的ingestion或查询会影响查询性能。
点查询延迟随着水平数的增加而稳定下来。 图8(d)显示，随着更新-插入比率的增加，平均点查询延迟急剧下降，然后稳定下来。延迟的最初急剧下降是由于LSM树的层数减少（从4到3），当更新-插入比率从0.4增加到1时，延迟就稳定下来了，因为非空点查找至少执行一次磁盘I/O，这反过来又支配了整个查找成本。
5.2.3 改变更新的比例。
我们现在改变更新与插入的比例，同时将查询与ingestion交错进行。更新与插入的比例为0意味着所有的插入都是唯一的，而比例为8意味着每个唯一的插入平均收到8个更新。
O8：对于较高的更新率，Tiering compaction延迟下降；LO+2在Leveling策略中占优势。
随着更新比例的增加，tiering的平均compaction延迟显著降低，因为我们在每次compaction中都会丢弃多个已经更新的entries（图[8(a)）。
我们观察到Full和LO+2有类似但不太明显的趋势，而保持策略基本不变。总的来说，较大的compaction粒度有助于利用更新的存在，在同一时间内使更多的条目失效。 在平整策略中，LO+2表现最好，因为它在compaction过程中移动的数据少了20%。
如图8(b)所示，这也会影响写入放大。
随着更新部分的增加，包括Tier在内的所有压缩策略的尾部压缩延迟都比较低。图8(c)显示，Tier的尾部压缩延迟从6倍于在更新-插入比率为8的情况下，完全达到1.2倍，这表明Tier最适合更新密集的工作负载。我们还观察到，在更新繁重的工作负载的查询延迟和读取放大率也在下降。
TA六： tiering在更新密集型工作负载的性能上占主导地位。当受到更新密集型工作负载时，Tier表现出 superior compaction性能，同时具有可比性的查找性能（作为level的LSM），这使得它在整个性能空间中占主导地位。
5.2.4 变化的删除比例 *。*我们现在分析删除的影响，它是特殊标记的为无效的被称为墓碑的特殊条目。
我们保持相同的数据大小，并改变工作负载中点删除的比例。所有的删除都是在现有的键上进行的，并与插入交错进行。
TSD和TSA提供卓越的删除性能。
我们使用工作负载执行结束时的墓碑数量来量化删除的效果。这个数字越低，说明删除的数据从数据库中清除得越快，这反过来又减少了空间、写入和读取的放大。图8(e)显示，TSD和TSA在实验结束时保持较少的墓碑。对于一个有10%删除量的工作负载，TSD比Tier多清除了16%的墓碑，比LO+1多清除了5%的墓碑，它挑选了墓碑密度超过预设阈值的文件进行压缩。
对于TSA，我们试验了两种不同的删除持久性阈值。TSA33和TSA50分别设置为实验运行时间的33%和50%。
由于TSA保证在设定的阈值内持续删除，它更积极地压缩数据，与TSD相比，最终的墓碑减少了7％。Full能够比任何部分压缩程序清除更多的墓碑，因为它周期性地压缩整个层次。Tier保留了最高数量的墓碑，因为它总体上保持了最高数量的sorted run。随着工作负载中删除比例的增加，LSM树中剩余的墓碑数量（实验结束后）也在增加。TSA和TSD以及Full的规模比部分压缩程序和tiering更好。通过压缩更多的墓碑，TSA和TSD也清除了更多的无效数据，减少了空间放大，如图8(f）所示。
O9: 优化删除需要付出（写入）代价。 由TSA和TSD提供的重新 duced空间放大是通过急于压缩墓碑来实现的，这增加了由于压缩而移动的数据总量。图8(g)显示，TSD和TSA50 比写优化的LO+1多压缩了18%的数据（对于TSA33 ，这变成了35%）。因此，当目标是（i）及时坚持删除或（ii）减少删除引起的空间放大时，TSD和TSA是有用的。
TA七：TSD和TSA是为删除而定制的。根据设计，TSA和TSD会选择有墓碑的文件进行压缩，以减少空间放大率。TSA通过急于压缩更多的数据来确保及时的持久性删除，以获得更小的持久性阈值，这增加了写放大的效果。
5.2.5 变化的ingestion量*。
我们现在报告scalability的结果，将数据大小从 227B变化到235B。
O10： Tier与Leveled和Hybrid策略相比，扩展性很差。 如图8(h)所示，除Tier外，所有compaction策略的平均compaction延迟都是亚线性的。leveling和混合compaction策略的相对优势在于
无论数据大小如何，数据布局保持相似。 图8(i)进一步证实了这一观察，该图显示了写放大率是如何扩展的。我们还观察到，当数据大小超过8GB时，RocksDB实现的tiering（即unviersal compaction）的优势会减少。图8(j)显示，随着数据大小的增加，Tier的尾部压缩延迟也在增加，因为来自连续level的文件之间的最坏情况重叠明显增加。这使得Tier不适合于对延迟敏感的应用。当数据大小达到2GB时，Full会触发一个级联压制，将所有的数据写到一个新的级别，造成写放大和压制延迟的峰值。
5.2.6 Entry Size的大小。
*在这里，我们保持键的大小不变（4B），并在4B到1020B之间变化数值以改变入口大小。
O11: 对于较小的Entry大小，leveling压缩的成本更高。 较小的Entry大小增加了每个page的Entry的数量。这反过来又导致(i)在合并过程中需要比较更多的Key，以及(ii)更大的bloomfilter，每个文件需要更多的空间和更多的CPU用于散列。图8(k)显示了这些趋势。在图8(l)中，我们也观察到了类似的写入放大的趋势，以及查询延迟的趋势。它们都随着条目大小的增加而减少。然而，随着整体数据大小的增加，我们观察到Tier的压缩延迟和写入放大率急剧增加（与图8（h）和（i）类似）。
size越小压缩成本越高（有点反直觉，但细想又合理），也就是压缩时间更长，写放大更大，另外Tier若entry size过大，压缩时间急剧增加。（具体原因是？TODO）
