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

432 阅读16分钟

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

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

第36篇,这是对Lethe的benchmark,针对具有删除和不同删除持久性阈值的一系列工作负载,针对最先进的 LSM 树设计评估 Lethe。在YCSB中是没有涉及很多关于删除的workload,所以作者自己设计了在YCSB workload A的混入删除的百分比在ingestion量的2%到10%之间变化的新workload。

本文还在持续推导h的合适大小,也就是image.png 图中page的个数。

论文来自cs-people.bu.edu/dstara/pdfs…

4.3 Lethe

Lethe 结合了 FADE 和 KiWi 的优点,以更好地支持 LSM 树中的删除。 对于给定的工作负载和持久性删除延迟阈值,Lethe 通过仔细调整持久性删除的成本及其对系统整体性能的影响来提供最大性能。 关键调整旋钮是 (i) 删除持久性阈值 (Dth) 和 (ii) delete tile 粒度 (h)删除持久性阈值被指定为数据保留 SLA 的一部分,Lethe 为树级别设置 TTL 以确保及时持久性。

对于具有次级范围删除的工作负载,Lethe 调整存储布局以使用相对于次级范围删除频率的读取操作频率找到delete tile粒度的最佳值。 h 的最优值通过求解关于 h 的 Eq2 给出。

image-20221225222113521

例如,对于一个400GB的数据库和4KB的页面大小,如果在两次范围删除之间执行任何类型的50M点查询,10K短程查询,并且FPR≈0.02且T = 10,使用Eq3,我们得到h的最佳值为:

image-20221225222242476

实现。 Lethe是在RocksDB上实现的,RocksDB是一个开源的基于lsm的键值存储,在业界广泛使用[27,29]。目前RocksDB的实现是通过分级实现的(只有Level 1被实现为分级以避免写暂停),并且具有固定的大小比率(默认为10)。我们为Lethe开发了一个新的API,以对基础设施进行细粒度控制。该API允许我们基于自定义触发器在RocksDB中启动压缩,并在压缩过程中设计自定义文件拾取策略。RocksDB已经为每个文件存储了元数据,其中包括每个文件的条目和删除数量。我们进一步存储aдe作为每个文件的唯一附加信息。删除持久性阈值在设置时作为用户输入,用于动态设置级别ttl。

评估

我们针对具有删除和不同删除持久性阈值的一系列工作负载,针对最先进的 LSM 树设计评估 Lethe。

实验装置。 我们使用配备两个 Intel Xeon Gold 6230 2.1GHz 处理器的服务器,每个处理器具有 20 个启用虚拟化的内核和 27.5MB L3 缓存、384GB 2933MHz 的 RDIMM 主内存和 240GB SSD。

默认设置。 除非另有说明,否则实验设置由一个最初为空的数据库组成,其ingestion速率为每秒 2^10 个条目。 每个条目的大小为 1KB,条目在密钥域中均匀随机分布,并以随机顺序插入。 内存缓冲区的大小为 1MB(作为跳过列表实现)。 数据库的大小比率设置为 10,对于内存中的布隆过滤器,我们每个条目使用 10 位。 为了确定原始性能,写入操作被认为具有比压缩更低的优先级。 对于执行的所有实验,Lethe 的实现与 RocksDB 设置的不同之处仅在于压缩触发器和文件选择策略。 我们启用了块缓存和直接 I/O 并禁用了 WAL。 删除仅针对已插入数据库并在工作负载中均匀分布的键发出。 我们在数据库中插入 1GB 数据,压缩优先级高于写入。 删除持久性阈值设置为实验运行时间的 16.67%、25% 和 50%。 该实验模拟了长时间运行的工作负载的行为。 为实验选择的删除持久性阈值具有实际应用的代表性,对于运行 1 年的商业数据库,阈值分别为 2 个月(16.67%)、3 个月(25%)、6 个月(50%) 年 [26]。 在填充整个数据库后发出所有查找。

度量。 与compaction有关的性能指标包括:(i)执行compaction的总次数,(ii)compaction的字节数,(iii)树中存在的墓碑数量,以及(iv)包含墓碑的文件的年龄,都是通过在实验后对数据库进行快照来测量的。然后使用第3.2.13.2.3节中的公式计算空间写入放大率

工作负载。 鉴于缺乏删除基准,我们设计了一个合成工作负载生成器,它产生了YCSB工作负载A的变化,其中50%为一般更新,50%为点查询。在我们的实验中,我们将删除的百分比在ingestion量的2%到10%之间变化。

5.1 实现及时删除的持久性

Lethe减少了空间放大。我们首先表明,Lethe通过及时持久化删除,大大减少了空间放大。我们通过改变RocksDB和Lethe的工作负载中的删除百分比,以及三种不同的删除持久性阈值来设置这个实验。图6(A)所示。对于没有删除的工作负载,Lethe和RocksDB的性能是相同的。这是因为在没有删除的情况下,Lethe执行由级别饱和度触发的压缩,选择重叠度最小的文件。

这是默认的rocksdb选项。level饱和度+重叠度最小的files,下图看到,rocksdb的空间放大是比较大的。

有删除的情况下,在删除持续阈值(Dth )的驱动下,Lethe更频繁地压缩文件以确保符合阈值。它持续地删除日志上无效的条目,在这个过程中,减少了数据库中的空间放大。即使当Dth 被设置为工作负载执行时间的50%时,Lethe也能将空间放大率降低约48%。对于较短的DthLethe在空间放大方面的改进是进一步明显的。

image-20221231214812661

Lethe执行了较少的compaction。6(B)和(C)显示,与RocksDB相比, Lethe执行的compaction次数更少,但在每次compaction过程中compaction的数据更多。 Lethe根据Dth* ,在滚动的基础上进行compaction。每次实验后,发现Lethe与RocksDB相比,磁盘上的文件更少。这是因为,Lethe以一种贪婪的方式压缩无效的条目,对于一个甚至有一小部分(2%)删除的工作负载,它减少了45%的压缩次数,如图[6]B)所示。然而,在压缩TTL过期的文件时,所选择的文件可能与目标层的文件数量相对较多的文件重叠,因此,当Dth 被设置为实验运行时间的50%时,Lethe压缩的数据多了4.5%,如图6(C)所示。

注意这里说Lethe多压缩了数据是看全局写入数据量来表征,这是一个不错的观测点。

image-20221231215409198

Lethe 实现了更好的读取* 吞吐量。**在这个实验中,我们表明Lethe与RocksDB相比,提供了更高的读取性能。在这个实验中,我们用1GB的数据填充数据库,然后对现有条目进行点查询。注意,查找的条目可能是在插入后被墓碑删除的。随着工作负载中更多的删除,无效的条目(包括墓碑)哈希到BFs的数量增加。 Lethe通过持久化的方式清除这些多余的条目,因此,清理了BFs,提高了它们的FPR。对一个持久性删除的键进行查询,无需执行磁盘I/O来读取墓碑,就能返回负数。总的来说,图6(D)显示Lethe对有删除的工作负载提高了高达17%的查询性能。** Lethe*****保证了及时的删除持久性。 6(E)显示了实验结束时墓碑年龄的分布,以证明Lethe确保了及时的持久性删除。X轴显示了所有包含墓碑的文件的年龄,Y轴显示了在快照的瞬间,年龄与X轴值对应或更小的墓碑的累积数量。 Lethe的目标是拥有比现有技术水平更少的年龄小的墓碑,所有墓碑的年龄都小于*Dth我们在与RocksDB的比较中表明。

image-20221231220230239

Lethe在40%至80%的墓碑上持续存在,而这样做的同时也遵守了删除持久性的阈值。对于Dth = 50%的实验运行时间,而RocksDB有40,000个墓碑(即 所有插入的墓碑的40%),分布在比Dth 更早的文件中,Lethe持久化了阈值内的所有删除。

写入放大倍数在* Lethe** 中得到了摊销。这个实验表明, Lethe最初的急切合并所引起的较高的写入放大率会随着时间的推移而被摊销。对于Lethe ,我们将Dth* 设置为60秒,并在实验执行过程中以180秒的时间间隔进行快照。在每次快照中,我们都会测量在过去的时间间隔内写入的累计字节数。我们为RockDB(不支持设置Dth )测量相同的指标,并使用它来规范化写入的字节。我们在图6(F)中绘制了归一化后的写入字节数与时间(跨快照)的关系。我们观察到,由于急切合并,Lethe 在第一个快照中写入的数据是 RocksDB 的 1.4 倍。然而,通过预先保存无效条目,Lethe从树中清除了多余的条目,因此在随后的压缩中压缩了更少的条目。这就减少了Lethe在一段时间内的正常化写入量。在实验结束时,我们观察到,与RocksDB相比,Lethe只多写了0.7%的数据。在这个实验中,我们把Dth ,比实验时间小15,以模拟最坏的情况。在实践中,LSM引擎中的插入会持续更长的时间(甚至是永久的),Dth 被设置为一个小的恒定持续时间。在这种情况下,Lethe的写入放大作用将很快被摊销。

image-20221231220255334

Lethe的 规模与技术状态相似。 这个实验表明,随着数据量的增长,* Lethe和最先进的技术水平遵循相同的性能趋势。我们用默认配置设置了这个实验,并改变了数据大小。除了用于计算混合工作负载延迟的YCSB工作负载A之外,我们还使用一个只写的工作负载来测量写延迟。图6(G),显示了两个工作负载的平均延迟,数据大小在X轴上。我们观察到,RocksDB和Lethe的写延迟不受数据大小的影响。由于在Lethe的初始写入放大率增加的情况下,其写入延迟比RocksDB高0.1-3%。然而,对于混合工作负载, Lethe的平均延迟提高了0.5-4%。这一改进主要是由于Lethe*实现了更高的读取吞吐量,如图6(D)所示。对于较小的数据量,大多数数据条目都存储在内存或第一层磁盘中,这大大降低了读取延迟。

* 5.2 二级范围的删除

接下来,我们对Lethe的二级范围删除进行评估。

设置。 除非另有提及,工作负载包括0.001%的二级范围删除操作,以及1%的范围查询和50%的点查询。每个文件有256页,每页的大小为4KB。

Lethe 实现了卓越的删除性能。6(H)到(L)显示,* Lethe通过使用KiWi将数据存储在磁盘上,提供了卓越的整体性能。在第一个实验中,我们改变了二级范围删除操作的选择性,即删除数据库的部分,并测量在操作过程中可以完全放弃的页面数量。完整的页面删除不需要将页面读到内存中,因此,一个较高的值沿着Y轴是可取的。我们对不同的删除瓦片颗粒度( h*)重复实验。随着二级范围删除操作的选择性增加,全页下降的数量减少了。这个问题在较小的删除瓦片颗粒度上进一步加剧了。

尽管较高的h值对于减少二级范围删除的I/O要求是可取的,但它与查找性能有一定的权衡,如图6(I)所示。零结果和非零结果的查询成本随着瓦片大小的增加而线性增加。因此,h的最佳值是由工作负载组成驱动的。选择最佳的存储布局。6(J)显示了Lethe在存储布局的连续性方面的能力,并通过确定最佳存储布局来提供卓越的整体性能。对于一个有次要的工作负载范围内删除与查找的比率为2 10-6(即1个次级每0.5M次查询的范围删除),随着二级范围删除操作的选择性改变,磁盘上存储数据的最佳方式也会改变。对于0.01%的选择性,分类存储布局(h=1)提供了最佳性能。随着选择性的增加,设计的选择也发生了变化,我们观察到,对于选择性为0.05%的情况下,每个删除瓦片存储64个磁盘页(h=64)可以达到最佳性能。

分析CPU-I/O的权衡。 在这个实验中,我们展示了Lethe的CPU和I/O成本之间的权衡。这个实验的工作负载有50%的点查询和1%的范围查询,选择性为0.001%,49%的插入,以及一个单一的二级范围删除。我们在一个大小为90GB的预装数据库上运行这个工作负载(即在24小时内以每秒210次的速度插入)。我们有一个单一的二级范围删除操作,删除了1/7的数据库(模仿删除所有超过7天的数据的行为)。我们测量过滤器探针的哈希计算所花费的总时间和向磁盘输入/输出所花费的总时间。

6(K)显示了Lethe和RocksDB在不同的删除瓦片大小时,在散列和I/O访问方面花费的总时间。然而,由于散列词条的时间比磁盘访问延迟小3个数量级,而且只有点查询能从布隆过滤器中受益,磁盘访问时间在工作负载执行时间中占主导地位。通过去掉符号,Lethe计算出h的最佳值,在这种情况下是8。对于h=8,Lethe的I/O成本比RocksDB低76%。这是以散列成本增加5%为代价的,这完全隐藏在I/O总数的巨大好处背后。

排序键和删除键之间的相关性的影响。6(L)显示了排序键和删除键之间的相关性的影响。我们对两个工作负载进行了这个实验。在第一个工作负载中,没有相关性在排序和删除键之间,交织的存储布局的影响是突出的。当我们增加h时,范围内的删除成本急剧下降(因为有更大一部分页面可以被完全删除),而牺牲了范围查询的成本。对于第二个工作负载,即排序和删除键之间的正相关关系(1),删除瓦片对性能没有影响。在这种情况下,经典的LSM存储布局(即h=1)成为最优。

image-20221226234807618

相关的工作

关系型系统中的删除。 过去关于关系系统中数据删除的工作主要集中在批量删除方面[14, 31, 47]。高效的批量删除依赖于类似于高效读取的技术:对数据进行分类或散列,以快速定位,最好是将要删除的条目放在一起。在空间数据[45]和视图维护[8]的背景下,高效的删除也被研究。与过去的工作相反,Lethe旨在支持用户提供的删除持久性延迟阈值。

自毁的数据。 此外,过去的研究已经提出了在满足特定条件时自动使数据消失。消失是一种方案,它确保在用户指定的时间后,某些数据的所有副本变得不可读,而不需要用户采取任何具体行动[32, 33]。Kersten[42]和Heinis[37]提出了通过生物学启发的机制在数据系统中遗忘的概念,作为一种更好地管理存储空间和高效数据分析能力的方式,因为数据生成的趋势继续增加。与此相反,Lethe支持由用户/应用程序设置的及时数据删除。

2 结论

在这项工作中,我们表明,最先进的基于LSM的键值存储在有小部分删除的工作负载中表现不尽如人意,而且这些数据存储的删除持久性延迟可能是无界的。为了解决这个问题,我们建立了Lethe,一个新的基于LSM的引擎,引入了新的压缩策略系列FADE和KiWi,一个连续的物理数据存储布局。FADE在用户定义的阈值内强制执行删除持久性,同时增加读取吞吐量并减少空间放大,代价是适度增加写入放大。KiWi提供了高效的二级范围删除,可以对其进行调整,使其在特定的工作负载下的表现优于现有技术。