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

[论文阅读] Lethe A Tunable Delete-Aware LSM Engine(三)

第34篇，从本章讨论了Lethe的设计目标和FADE的概述。看起来Lethe希望改进LSM对隐私保护的无法准确应答的风险。例如承诺多少天Dth必然会删掉。

FADE(快速删除)策略是比较简单的，可以移植的，实际我看到只是改了rocksdb一个文件的代码。Lethe复用了很多现有的元数据信息。FADE支持TTL，这是对Dth的一个分摊到Levle上的扩展，对于更大级别的树，TTL 和每级别的容量都呈指数增长。它并不是固定的。论文来自cs-people.bu.edu/dstara/pdfs…

4 持续删除：LETHE

设计目标。 Lethe 旨在 (i) 为点和范围删除提供持久性保证，以及 (ii) 实现实用的二级范围删除。 我们通过引入 FADE 来实现第一个设计目标，FADE 是一系列删除感知压缩策略。 我们通过引入 Key Weaving Storage Layout 来实现第二个目标，这是一种新的物理数据布局连续体，它根据排序和删除键以交织的方式在磁盘上排列条目。

4.1 FADE

我们首先介绍 FADE 系列压缩策略，确保所有墓碑都在删除持久性阈值 (Dth) 内持久化。 Dth 通常由应用程序或用户 [26, 60] 指定为涉及数据保留策略的服务级别协议 (SLA) 的一部分。 受同一数据保留 SLA 约束的所有数据流具有相同的删除持久性延迟。

概述。 LSM-trees 中的压缩通过决定它们的空间放大、写入放大、点和范围读取性能以及删除持久性延迟来影响它们的行为。 FADE 使用有关文件墓碑年龄的附加信息和每个墓碑的估计无效条目，通过为每个文件分配生存时间 (TTL) 来确保每个墓碑都遵守用户/应用程序提供的 Dth。 只要 Dth 得到尊重，FADE 就会为二级优化目标提供不同的策略，包括最小化写入放大、最小化空间放大或最大化系统吞吐量。

生存时间。 为了确保在 LSM-tree 上发出的所有删除操作在 Dth 之前持久化，FADE 通过所有中间级别将每个墓碑传播到该阈值内的最后一个级别，从其插入开始。FADE 通过为每个级别 di 中的每个文件分配一个较小的 TTL 来实现这一点，例如 \sum_{i=0}^{L-1}d_i=D_{th}。一个简单的 TTL 分配是使用 d_i=D_{th}/L。虽然这可以保证Dth内墓碑达到的最后一个级别，但它也会导致压缩时间增加和资源匮乏，因为更高级别的文件呈指数级增长，因此，大量文件可能同时耗尽它们的 TTL。 相反，我们为每个级别分配指数增加的 TTL，以保证文件在每个时间单位以恒定速率过期。

计算d_i。 对于一个大小比为T的树，我们设置i层的TTL为d_i=T\cdot d_{i-1}，\forall i \in {1, L-1}且d_0=D_{th} \cdot \frac{T-1}{T^{L-1}-1}。请注意，对于更大级别的树，TTL 和每级别的容量都呈指数增长。

更新d_i。对于给定的树高度，每个文件都被分配了一个 TTL，具体取决于它被压缩到的级别。 随着更多数据条目的插入，树的高度可能会增加。 那时，必须更新整个树中的 TTL。 计算 d_i的成本很低，因此，FADE 在每次缓冲区刷新后重新计算 d_i。 图 4 (A) 中的步骤 1 显示了如何在添加新级别时更新 d_i。

4.1.3 FADE 元数据. 用于点删除的墓碑与有效的键值对一起存储，范围墓碑存储在单独的块中。 除了墓碑之外，FADE 还需要每个文件的两个指标值：(i) 包含的最旧墓碑的年龄 (a^{max}) 和 (ii) 文件墓碑的估计失效计数 (b)。 每次刷新后，一个文件被分配其当前的a^{max}和 b。

实际上，LSM 引擎存储文件元数据，包括 (i) 文件创建时间戳，以及 (ii) 每个文件的条目以直方图的形式分布。 例如，RocksDB 为所有条目分配一个单调递增的插入驱动序列号（seqnum），并存储每个文件的条目数（num_entries）和点逻辑删除数（num_deletes）。 FADE 利用了这个现有的元数据。 它使用 seqnum 计算 a max 并使用 num_entries 和 num_deletes 计算 b。 因此，实际上 FADE 不会留下元数据足迹。

计算a^{max}。 一个文件f的a^{max}，表示为a_f^{max}，是文件中包含的最旧（点或范围）墓碑的年龄，使用当前系统时间与该文件的最旧墓碑插入内存缓冲区的时间之间的差值计算。没有墓碑的文件有a_f^{max}=0。存储a_f^{max}要求每个文件一个时间戳(8 bytes)，这是一个不可省略的开销。

计算b。 文件 f 的墓碑的无效条目的估计数量，称为 bf ，是使用（i）文件中点墓碑的确切计数（pf ）和（ii）对整个数据库无效的条目的估计来计算的 文件 (rdf) 的范围墓碑，如 bf = pf +rdf。 在不访问整个数据库的情况下不可能准确计算 rdf，因此，我们使用数据存储已经维护的系统范围直方图来估计这个值。 bf 的值是即时计算的，不需要任何额外的元数据。

更新a^{max}和b。与所有文件元数据类似，amax 和 b 在缓冲区刷新后创建文件时首先计算。 此后，对于新压缩的文件，amax 和 b 在写回磁盘之前重新计算。 当压缩只是将文件从一个磁盘级别移动到下一个磁盘级别而不进行物理排序合并时（即，当没有重叠键时），b 保持不变，并且根据最近一次压缩的时间重新计算 max。 请注意，由于所有元数据都在内存中，因此这不会导致 I/O。

4.1.4 压缩策略。 压缩确保插入和读取成本均摊销。 对于每个压缩，有两个策略需要决定：压缩触发策略和文件选择策略。 最先进的 LSM 引擎在级别饱和（即大于标称大小阈值）时启动压缩，并随机选择一个文件，或者与后续级别重叠最小的文件以最小化 合并成本。

压缩触发器。FADE 通过触发压缩来增强最先进的技术，不仅在级别饱和时，而且在文件具有过期的 TTL 时。 FADE 在至少有一个 TTL 过期的文件的级别中触发压缩，无论其饱和度如何。 如果没有 TTL 过期，但某个级别已饱和，则会触发该级别的压缩。

文件选择。 FADE 根据调用它的触发器决定压缩哪些文件。 它具有三种模式：(i) 饱和驱动触发和重叠驱动文件选择 (SO)，这与现有技术相似并针对写入放大进行了优化，(ii) 饱和驱动触发和删除驱动文件选择 (SD)，它选择具有最高 b 的文件，以确保压缩尽可能多的墓碑并优化空间放大，以及 (iii) 删除驱动的触发器和删除驱动的文件选择 (DD)，它选择 具有过期墓碑的文件以遵守 Dth。 通过选择包含最旧墓碑的文件打破 SD 和 DD 中的平局，通过选择具有最多墓碑的文件打破 SO 中的平局。 如果级别之间存在联系，则选择最小级别进行压缩以避免压缩期间的写入停顿。 对于同一级别的文件之间的平局，FADE 选择具有最多墓碑的文件。

4.1.5 对性能的影响

FADE 保证所有点和范围墓碑在其生命周期达到 Dth(\forall f, a_f^{max} < D_{th}) 时都被持久化。我们将树的大小称为 N，将所有条目都保存在 Dth 中的树的大小称为 Nδ。

空间放大。 FADE 通过以时间限制的方式压缩它们，以滚动方式从树中删除墓碑和逻辑上无效的条目。 通过这样做，它减少了由异地删除引起的空间放大，将 samp 限制为 O(1/T ) 用于调平和 O(T ) 用于分层，即使对于具有删除的工作负载也是如此。

写入放大。 确保 Dth 中的删除持久性，强制压缩具有过期 TTL 的文件。 因此，在工作负载执行期间，最初 FADE 会导致写入放大的瞬间峰值。 然而，初始的高写放大会随着时间的推移而被摊销。 通过急切地压缩墓碑，FADE 清除了大多数无效的条目。 因此，未来的压缩涉及更少的无效条目，导致更小的写入放大，这与现有技术相当，正如我们在第 5 节中展示的那样。

读取性能。 FADE对读取性能有轻微的积极影响。通过压缩无效的条目和点墓碑，FADE减少了在BFs中散列的条目数量，导致在给定的可用内存数量下，总体FPR更小，因此，在现有和不存在的键上进行点查询的成本会逐步提高（表2）。在N**δ 条目可以存储在磁盘上的L**δ < L级的情况下，查询成本将通过访问更少的级别而获益。长距离查询的成本是由查询的选择性驱动的，这个成本对于FADE来说是比较低的，因为及时的持续删除导致查询迭代器扫描较少的无效条目。

持久性保证。 FADE确保所有插入LSM树并刷新到磁盘的墓碑总是在用户定义的Dth 阈值内被压缩到最后一级。如果WAL的清除周期短于Dth ，则保留在写前日志（WAL）中的任何墓碑都会被持续清除，这在实践中是很常见的。否则，我们使用一个专门的例程来检查所有比D**th 更早的实时WAL，将所有实时记录复制到一个新的WAL，并丢弃旧WAL中的记录，使其进入磁盘。

Dth 的实用值 :不同应用的删除持久性阈值差别很大。在商业系统中，LSM-引擎被强制根据SLA要求每7天、30天或60天执行一次完整的树状压缩[39]

也即是为了可以把数据彻底删掉，需要7、30、60天执行一次完整的compact。这可能就是Rocksdb ttl compaction的由来？

盲目删除。 针对不存在或已经失效的密钥的墓碑会导致盲目删除。 盲目删除针对树中不存在的键ingestion墓碑，这些多余的墓碑会影响点和范围查询的性能 [39]。 为了避免盲目删除，FADE 探测相应的 BF 并仅在过滤器探测返回正值时插入墓碑。 这样，FADE 大大减少了盲删除的次数。