开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第32天，点击查看活动详情
Lethe被不断提及，他有这么厉害吗？本章首先描述LSM系统的现状和困难之处，以及Lethe的最重要的诉求，可预期的持久化删除，所谓持久化删除，是因为当前LSM是使用标记删除的策略，称之为out-of-place delete，用户的调用delete接口，将会插入一个墓碑，而后会有compaction来完成物理删除， 本文称之为删除持久化，那么当前LSM是无法对删除时间做保证的，这就是本文的背景和idea，看来，写论文是需要关注时事，找出重要的诉求。 论文来自cs-people.bu.edu/dstara/pdfs…
Lethe A Tunable Delete-Aware LSM Engine
摘要
数据密集型应用推动了LSM键值引擎的发展，该引擎采用out-of-place模式，以低读/写干扰支持高摄入率。这些好处产生的代价是将删除作为二等公民对待。删除会插入一个tombstone，使已删除key的旧实例失效。最先进的 LSM 引擎不保证逻辑删除将以多快的速度传播以持久删除。 此外，LSM 引擎仅支持对排序键进行删除。 要删除另一个属性（例如，时间戳），将读取并重写整个树。 我们强调，在不影响读取性能的情况下快速持久删除关键应该支持支持：
(i) 在数据窗口上运行的流式系统
(ii) 具有延迟保证的隐私被遗忘的权利（是一个法案.）
(iii) 大规模数据系统的云部署，使存储成为宝贵的资源。
为了应对这些挑战，在本文中，我们建立了一个新的键值存储引擎Lethe， 它使用了非常少量的额外元数据、一套新的删除感知compaction策略和一个新的物理数据布局，它将排序和删除键的顺序结合起来。我们表明，Lethe支持任何用户定义的删除延迟阈值，提供更高的读取吞吐量（1.17-1.4x）和更低的空间放大率（2.1-9.8x），并适度增加写入放大率（4%到25%之间）。此外，Lethe支持在二级删除键上进行有效的范围删除，即放弃整个数据页而不牺牲读取性能，也不采用昂贵的全树merge compaction。
1. 简介
系统被优化为快速数据ingestion。 现代数据系统处理由各种应用程序生成的空前数量的数据，包括数据分析、流处理、物联网和 5G [18、30]。基于云计算的延迟敏感应用，如实时视频流[40]、实时健康监测[55]、电子商务交易[39]、社交网络分析[59]和在线游戏[49]，以高速度产生大量的数据，需要混合事务/分析处理（HTAP）[7, 51, 54]。因此，在过去的十年中，数据管理研究的主要挑战之一是设计能够维持快速数据ingestion率并以低延迟处理查询的数据系统[3, 9, 54]。为了实现这一目标，现代数据存储通过采用out-of-place ingestion来减少读/写干扰[11, 12, 21, 38, 44, 46, 56, [63]。](#_bookmark77)
基于LSM的键值存储。 经典的out-of-place设计是日志结构的合并（LSM）树。LSM树在主内存中缓冲传入的数据条目，并周期性地将这个缓冲区刷新为持久存储中不可改变的sorted run（immutable sorted run） [21, 50, 53, 57, 64]。反过来，随着越来越多的排序运行的累积，它们被迭代排序合并以形成更少但更大的排序运行。这个过程被称为 "compaction"（compaction） ，它减少了在读取查询过程中被访问的排序运行的数量，并分摊了合并成本。每一次compaction都会将现有的来自连续层次的排序运行进行排序合并，并丢弃任何无效的条目。LSM树被一些现代系统所采用，包括谷歌的LevelDB[36]和BigTable[17]，Facebook的RocksDB[29]，阿里巴巴的X-Engine[39]，LinkedIn的Voldemort[48]，亚马逊的Dynamo[25]，Apache的Cassandra[5]、HBase[6]和Accumulo[4]，以及雅虎的bLSM[61]和cLSM[35]。关系型数据系统已经越来越多地采用LSM风格的更新。My- Rocks[28]使用RocksDB作为存储引擎，SQLite4[62]在其存储层中尝试使用LSM-树，而列式系统则使用LSM式更新[20, 44, 63, [70]。](#_bookmark84)
挑战。就地删除。 LSM引擎对任何写操作都使用out-of-place的范式，包括摄入（插入）、修改（更新）和删除（删除）。因此，删除（更新）是通过插入额外的元数据来实现的，这些元数据在逻辑上使旧的目标条目失效[16]。我们把这个过程称为逻辑删除（更新） 。逻辑删除和更新都显示出复杂的三方权衡[13]，然而，逻辑删除在（i）空间放大方面有更广泛的影响。(ii) 读取成本，(iii) 写入放大，和(iv) 隐私考虑，因此，是这项工作的主要重点。
特别是，一个逻辑删除，插入一个墓碑，在验证一个给定的键的所有旧条目，并期望，最终，他们将被持久地删除。在实践中，删除持久性延迟是由(a)系统设计选择和(b)工作负载特性驱动的。两者在执行过程中都无法完全控制，因此，在最先进的LSM引擎中为持久性删除提供延迟保证几乎是不可能的。事实上，LSM树有一个潜在的无限制的删除持久性延迟。为了限制它，目前的设计采用了昂贵的全树压缩，干扰了读取性能和写入放大，并导致性能的不可预测性[39]。
LSM树中的删除。 LSM-树被用作关系系统[28]、流媒体系统[2, 41, 65]和纯键值存储[52, 68]的存储层。因此，LSM的删除操作可能被各种日志操作所触发，不限于用户驱动的删除。例如，删除操作是由涉及周期性数据迁移的工作负载[58]、运行窗口上的流式操作[39, 43]或在数据迁移期间需要清理的工作负载[58]所触发的。特别是，通过范围删除操作[58]，可以实现在具有多个列族的LSM树中删除表。另一个常见的例子是按创建时间戳排序的数据集合。在这种情况下，经典的就地更新是不够的，因为键（时间戳）也会改变。因此，每次更新都会转化为删除，然后再插入新的版本[15]。下面，我们提炼出两个频繁的删除用例的共同概念。
场景1：一家电子商务公司ECP在LSM树中存储了按订单**id排序的订单细节，并需要删除某个特定用户的订单历史。在系统中，这个删除请求被转换为一组对排序键*，即*订单**id的点和范围的删除。
场景2：一家数据公司DComp将其业务数据存储在LSM树中，文档**id为排序键。由于大部分数据只在D天内相关，DComp想删除所有时间戳超过D天的数据（并将其存档）。同时，DComp经常使用文档**id来访问文档，因此，排序键（文档_id）与删除键（时间戳）不同。
为什么目前的技术水平还不够？ LSM引擎不能有效支持第一种情况下的ECP，原因有二。首先，由于删除插入墓碑（保留物理条目），它们增加了空间放大率。其次，在树中保留多余的条目会对读取性能产生不利影响，因为读取查询必须丢弃潜在的大量无效条目集合，这进一步 "污染 "了过滤器元数据[39]，并增加了写入* 放大*，因为无效条目被重复地写入了。此外，LSM引擎不适合第二种情况下的DComp ，因为它们不能有效地支持排序键以外的删除键中的范围删除（称为二级范围删除 ）。相反，它们采用全树 压缩，在读取、合并和重写整个树的排序文件时，会造成过多的浪费的I/O[39]。
删除持久性延迟。 为了能够报告一个删除的持久性，相应的墓碑必须通过迭代compaction达到树的最后一层，以丢弃所有无效的条目。在树中插入墓碑和完成最后一级compaction之间所花费的时间被称为删除持续延时。LSM的逻辑删除不提供删除持久性延迟的保证，因此ECP不能向用户提供这种保证。为了给删除持久性延迟增加一个硬限制，目前的设计也采用了昂贵的全树compaction。
作为隐私的删除。 拥有无限制的删除持久性延迟可能会导致侵犯隐私。例如，最近有报道称，Twitter在用户信息被删除多年后仍保留这些信息，甚至在用户账户被停用后也是如此[67]。随着GDPR[34]和CCPA[1]等新的数据隐私保护法案的出台，端到端的数据生命周期有新的隐私挑战需要解决[26, 60]。随着用户权利，如被遗忘的权利开始发挥作用，在一个固定的阈值内持续的删除是至关重要的。
"应避免全树compaction"。
在我们与从事基于LSM的生产系统的工程师的交流中，我们了解到，基于时间戳的大部分数据的定期删除是非常频繁的。引用一位在XEngine[39]工作的工程师的话："应用程序可能会出于他们自己的目的将数据保留不同的时间（例如，7天或30天） 。但他们都有每天删除的要求。例如，他们可以保留数据30天，每天删除31天后的数据，实际上每天都要清除1/30的数据库。" 这种删除是通过全树压缩进行的。进一步引用同一团队的话，"强迫compaction设置一个删除延迟阈值，导致compaction频率显著增加，观察到的I/O利用率经常达到峰值。这很快就会引入性能上的痛苦。" 对于大型数据公司来说，删除他们数据库的1/7或1/30，就占了几GB或几十GB。
导致每天需要持续删除的TBs。目前采用全树压缩的方法是次优的，因为它（1）导致高延迟峰值，（2）增加写放大。这项工作的目标是解决这些挑战，同时保留LSM设计的优点。
解决方案： Lethe
我们提出了Lethe ，这是一个新的基于LSM的键值存储，它提供了高效的删除功能，而不影响LSM树的好处。Lethe通过增加删除持续性作为一个新的设计目标，推动了传统LSM设计空间的边界，并且能够满足用户的要求。
图1(A)和(B)显示了最先进的LSM引擎[5、6、29、36、68]和Lethe的质量比较。图1（A）和（B）显示了最先进的LSM引擎[5, 6, 29, 36, 68]和Lethe在及时持久性删除的效率和成本方面的定性比较。Lethe引入了两个新的LSM设计组件。FADE和KiWi。
FADE（快速删除）是一个新的压缩策略系列，它根据（a）所包含的无效条目的数量，（b）最古老的墓碑的年龄，以及（c）与其他文件重叠的范围来确定文件压缩的优先次序。FADE使用这些信息来决定何时对哪些文件进行compaction，以清除某个阈值内的无效条目。
KiWi（Key Weaving Storage Layout）是一个新的连续的物理布局，通过引入delete tiles的概念，允许可调整的二级范围删除，而不会导致延迟峰值的出现。一个LSM树级由几个排序的文件组成，逻辑上形成一个排序的运行。KiWi在每个文件的设计中增加了几个删除区，每个删除区包含几个数据页。一个删除图块按次要（删除）键进行排序，而每个数据页仍按排序键进行内部排序。KiWi在页面层面上拥有Bloom过滤器，并为排序键和二级删除键设置了栅栏指针，通过将整个页面从删除图块中删除来促进二级范围的删除，并在误报方面有一个不变的因素。保持页面在排序键上的排序也意味着，一旦页面在内存中，读取查询将保持与现有技术水平相同的效率。
综上所述，Lethe是我们所知的第一个LSM引擎，它在提高读取性能的同时提供了高效的删除，支持用户定义的删除延迟阈值，并能实现实用的二级范围删除。 贡献。 我们的贡献如下。
- 我们从读取性能、空间和写入放大以及用户隐私等方面分析了就地删除的问题。
- 我们引入了FADE，在不损害性能和资源消耗的情况下，限制了删除持久性延迟。
- 我们介绍了Key Weaving Storage Layout，这是第一个支持高效二级范围删除的布局。
- 我们介绍了Lethe的设计，它将FADE和KiWi整合到一个最先进的LSM引擎中，并实现了快速的在删除持久性延迟和系统的整体性能之间有一个可调整的平衡。
- 我们证明Lethe提供了删除延迟的保证，具有高达1.4倍的读取吞吐量。较高的读取吞吐量归因于显著较低的空间放大率（只有10%的删除量，高达9.8），因为它清除无效条目的速度更快。这些好处是以4%-25%的写入放大率为代价的。
- 最后，我们证明Lethe是第一个支持高效二级范围删除的LSM引擎，其代价是增加读取成本，我们还展示了如何调整Lethe以根据工作负载来摊销这一成本。
