开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第12天，点击查看活动详情
论文阅读: Constructing and Analyzing the LSM Compaction Design Space（四）
本章继续看实验部分，有一些非常有趣的发现，观察作者的实验和分析，给我们提供了很好的直觉，这一章节有非常多的结论和小结论，需要放在大脑中反复揣摩，我的习惯是放在’暗时间’里慢慢磨合、消化、思考这些结论，这帮助我在未来为不同工作负载，不同查询需求挑选合适的compaction策略时具备足够的洞察力。以及未来修改rocksdb源码创建新的压缩策略时，有着足够的知识储备。
O5：读放大受块缓存大小和文件结构的影响，并且在tiering中最高。 图4(f)显示，对于非空的查询（α=0），不同的压缩策略的读放大在3.5和4.4之间。这是由于过滤器和索引块的大小分别是一个数据块的大小5×和1×。
O，这里的意思是，filter block和index block（SST的这两个block是为整个SST所有datablock服务的，他们当然比一个data block大。
每个非空点的查找根据目标键在树中的位置，获取1到L个filter block，以及多达LxFPR个index block和data block。
这里暗示了查找一个key时的行为是这样的。Tier的sort run多，要加载更多的因为FPR 引起的data block。α的增加意味着空查询多了，需要因FPR去加载更多的数据，所以读延迟更大（O4)，读放大更大（O5）。
此外，读放大倍数随着α的增加而呈指数级增长，对于leveling和tiering，读取放大倍数分别达到14.4和21.3（对于α = 0.8）。图4(f)还显示，Tier的点查询的估计读取放大倍数比leveling的策略高1.2倍到1.8倍之间。Tier的这种较高的读取放大率是由于树上的sorted run数量较大，与O4一致。
压缩对范围扫描的影响是微不足道的。 为了响应一个范围查询，LSM树实例化了多个运行迭代器扫描所有包含合格数据的sorted run。因此，其性能取决于（i）迭代器扫描时间（与选择性有关）和（ii）合并数据的时间。leveling LSM树中的sorted run数量保持不变，这导致所有leveling的变种压缩模式有着相似性的范围扫描延迟 ，特别是对于较大的选择性来说，范围查询延迟是相似的（图4g）。请注意，在没有更新或删除的情况下，对于不同的数据布局，符合范围查询条件的数据量基本上是相同的，尽管运行的数量不同。Tier的平均范围查询延迟高出5%，是由于需要额外的I/O来处理部分合格的数据，在最坏的情况下是O(L - T )。
5.1.3 执行混合工作负载 *。我们现在讨论的是ingestion和查询混合在一起时的性能影响。我们将1000万个独特的键值条目的ingestion与100万个点的查询交错进行。空与非空查找的比例在不同的实验中是不同的。所有的查询都是在L-1级饱和之后进行的。图5并列比较了串行和交错的结果。
请注意，ingestion进行时，有大量的compaction进行着，同时此时的读查询将较大影响的，O6却与这一直觉相反，为什么？此外前面的所有实验，都是各种不同的compaction策略的结果集的静态集表现讨论。
L-1层级满的意思是？
O6：混合工作负载的尾部写入延迟较高。 图 5(a)和(b)显示，对于所有的压缩策略，与点查询交错进行的压缩的平均延迟只有很小的影响。
如图5(c)所示，写放大仍然不受混合读和写的影响，这也证实了这一点。另一方面，图5(d)显示了尾部写的情况延迟增加了2至15倍。这种增加是由于
(1)点查询需要访问过滤和索引块，而这些过滤和索引块需要磁盘I/O与写入竞争并使设备饱和，以及
(2）在查找过程中内存缓冲区flush的延迟。
交错压缩和点查询有助于保持缓存的温度。 因为在这个实验中，我们在树的L-1层满的时候开始点查询，我们预计在交错的读查询的执行会比串行查询快1/L（在我们的配置中是25%），这相当于在树木的高度。然而，图[5（e）显示了这种差异对于非空的查询，速度在26%到63%之间，对于空的查询，速度在69%到81%之间。交错点查询执行速度比预期快的原因是：（1）大约10%的查询在内存缓冲区内终止，不需要任何磁盘I/O，以及（2）块缓存在compaction过程中预热了过滤器、索引和数据块的缓存。图5(d)和5(e)显示了1-Lvl是如何将两个世界的优点结合在一起，并同时提供相当好的ingestion和查询性能。
