【SIGMOD'20】Lethe: A Tunable Delete-Aware LSM Engine

Lethe

【SIGMOD'20】论文阅读笔记

Lethe: A Tunable Delete-Aware LSM Engine

https://dl.acm.org/doi/10.114...

简介

FADE + KiWi。使用非常小的额外元数据、新的delete-aware压缩策略、新的存储布局。

背景

  • LSM-tree逻辑删除的问题:(逻辑删除:插入tombstone,使目标键的旧条目失效)

    • 空间放大:保留了失效的条目,而增加了tombstone
    • 读代价:可能读到大量失效的
    • 写放大:失效的条目被重复压缩
    • 隐私问题:存在unbounded delete persistence latency。
  • 持久性删除延迟。逻辑删除不保证持久性删除。持久性删除延迟取决于系统的设计、负载特征,这在执行期间是难以控制的,延迟可能是无限的。(持久性删除延迟:从插入tombstone到完成最底层压缩的时间)
  • 非排序键上的大范围删除很棘手,如sort key是id,删除键是时间戳,需要全树压缩,代价巨大。

Lethe

  • FADE(fast deletion):保证在有限时间内完成持久性删除。根据包含的无效条目的数量、最古老tombstone的年龄、与其他文件重叠的范围,对文件进行压缩排序,来决定何时对何文件进行压缩、在阈值内清除无效条目。
  • KiWi(key weaving storage layout):实现高效的secondary range delete。引入delete tiles的概念。一个delete tile有多个页,一个文件有多个tile同一文件内,delete tile 间按sort key 排序,tile内的页与页间按 delete key 排序,页内按sort key 排序。在页面级使用布隆过滤器,在sort key和删除键上设置栅栏指针,KiWi通过从delete tile删除整个页面,来实现secondary range delete。假阳性的增加是一个常量。
  • Lethe融合FADE和KiWi,实现持久性删除和系统其他性能之间,可调的平衡。

结果

支持任何用户自定义的持久性删除延迟阈值,更高的写吞吐量(1.17-1.41x),更低的空间放大(2.1-9.8x),(代价是写放大提高4%-25%)。支持secondary delete key上高效删除,且不需牺牲写性能、不需全树合并。

FADE

新的压缩策略。添加额外信息:最古老tombstone的年龄$a^{max}$、失效条目估算值$b$。

TTL

$D_{th} $:delete persistence thresold

$d_i$: 第$i$ 层文件分配到的小TTL,$\sum \limits_{i=0}^{L-1} d_i = D_{th} $, 越大层的应分配越多的TTL(通常用指数增长的分配)

$d_i = T \cdot d_{i-1} , i \in [1,L-1] $ $ d_0 = D_{th} \cdot \frac{T-1}{T^{L-1}-1} $

要保证在$D_{th}$ 时间内到达最底层

在每个缓冲flush之后,要更新$d_i$

image

元数据

LSM引擎存储的元数据包括:文件创建的时间戳、每个文件条目的分布状况(以直方图形式)

如RocksDB,条目序列号(seqnum)、条目的数目(num_entries)、point tombstone的数目(num_delete)。

$a_f^{max}$ :文件f的最古老的tombstone的年龄,使用当前系统时间和最古老的tombstone的时间的差值算出来。存储需要一个时间戳(8字节)。要保证 $a_f^{max} < D_{th} $。用seqnum来计算

$b_f$:文件f因tombstone而失效的条目的估算值。用num_entries, num_delete来计算。$ b_f = p_f + rd_f $。$p_f$:文件f 精确的point tombstone的数目,$rd_f$:由于文件f的range tombstone而失效的(整个数据库)条目的估计数目。使用系统的直方图来预估。

压缩策略

  • 压缩触发策略。当前的:某一层饱和(大于阈值大小),触发压缩。FADE增加一条:文件的TTL满了后,即使该层没有饱和,也触发压缩。
  • 文件选择策略。当前的:随机选择文件,或者选择与下一层重叠最小的(以减小归并成本)。

FADE的文件选择三种模式

  • The saturation-driven trigger and overlap-driven file selection (SO)。类似于当前的,针对写放大优化。
  • The saturation-driven trigger and delete-driven file selection (SD)。选择$b$ 最高的文件,保证更多tombstone被压缩,针对空间放大优化。
  • The delete-driven trigger and delete-driven file selection (DD)。选择有过期tombstone的文件。

打成平手:

  • 在SD/DD模式下打成平手,则选择具有更古老的tombstone的文件。
  • 在SO模式下打成平手,则选择具有更多tombstone的文件。
  • 不同层间打成平手,则选择压缩最小的那一层,以免压缩过程中写阻塞。
  • 同层的打成平手,则选择有最古老tombstone的文件。

性能分析

  • 空间放大。缓解空间放大。$ S_{amp} = (csize(N) - csize(U) ) / csize(U) $

    $ csize(N) $: 积累的条目数量 $ csize(U) $: 积累的唯一的条目数量

  • 写放大。$ W_{amp} = (csize(N^+) - csize(N) ) / csize(N) $

    $N^+$:写入磁盘的所有条目的数量,包括在压缩后作为未修改的重新写入的条目的数量

    总体上减少写放大。

  • 读性能。由于压缩了无效条目和点tombstone,减少了布隆过滤器需哈希的条目数,降低了假阳率(FPR)。查询可以查更少的层。及时压缩也可加速长范围查找。
  • 一致性保证。保证在用户定义的时间阈值内完成持久性删除。
  • 空删除。探查BF,仅当返回真值时,插入tombstone。

KiWi

排序键和删除键的交织排序。引入delete tiles。牺牲了小量的额外元数据代价、可调的读性能。

布局

![上传中...]()

用$S$ 表示排序键image

  • 层布局。同当前的,即每一层都是包含$S$ 的非重叠范围的文件集合。同一层,若$i < j $,则文件 $ i $ 的所有条目的$S$ 小于文件$j$ 的。
  • 文件布局。一个delete tile由多个页组成,一个文件由多个delele tile组成。同一文件,若$k < l $,则delete tile $k$ 的所有条目的$S$ 小于delete tile $ l $ 的。
  • delete tile布局。delete tile 的页按删除键排序。同一 delete tile,若$ p < q $,则页 $p$ 的所有$D$ 小于页 $q$的。范围删除时,可以快速清除连续的页(有栅栏指针)。
  • 页布局。页内条目按 sort key 排序。

范围删除

  • 可以快速清除满足条件连续的页,不需读、更新。 ( full page drop )。
  • 对于那些只有部分条目在删除范围的页,则加载这些页,重写。( partial page drops ) 后续压缩会回收空间。一个 delete tile 有0或1个这样的页,就地编辑的开销。

BF、栅栏指针

  • 布隆过滤器。KiWi 在一个页上维护一个$S$ 的布隆过滤器full page drop 不需重构BF,partial page drop 只需少量CPU开销。
  • 栅栏指针。对每个 delete tile,设置栅栏指针,跟踪 tile 内 $S$ 最小的条目,辅助BF进行查找。另有删除栅栏指针,在内存中记录每个页的最小$D$,full page drop 时就不需要加载、读取这些页面。

性能分析

Delete tile 粒度。每个 delete tile 的页数 $h $。随着$h$ 增大,删除 $1/h$大多数为 full drop;读性能下降。$h$ 的选取取决于查找、范围删除的频率,以及BF分配的内存、size ratio

空间

image

查找

  • 点查找。先查 $S$ 的栅栏指针,定位可能包含搜索码的 delete tile 。再用BF过滤器探查,若返回真值,读页进内存,$S$ 上二分查找。若非真值,取下一个tile。

    能找到,leveling:$O(1 + h · e ^{−m/N} )$ tiering:$O(1 + T \cdot h · e ^{−m/N} )$

​ 不能找到,leveling:$O(h · e ^{−m/N} )$, tiering:$O(T \cdot h · e ^{−m/N} )$

​ 与state-of-art比,糟糕了一点。

  • 范围查找。差不多。见封面。
  • secodary范围查找。高效。

trade-off计算

$f$:各负载的占比。

$f_{EPQ}$:点,zero-result查。 $f_{SRQ}$:短范围查。 $f_{SRQ}$: secondary range query。 $f_I$:插入。

image

用(2)可以按需找到 secondary range deletelookup 的最佳 trade-off

image

Lethe

image

在RocksDB顶层实现。

实验评估

image
详见论文。

注意:

  • C图,Lethe的高于RocksDB,原因是选择过期TTL的文件压缩(DD文件选择策略),这些文件可能与目标层有相当大的重叠。
  • F图,一开始,Lethe由于earge merging,写的是RocksDB的1.4倍。但由于压缩清除了无效的条目,过了一段时间后,后续压缩就变少,写的数量与RocksDB持平。可见,Lethe可很快减少写放大。

一点体会

LSM的优化方法众多,取决于RUM的权衡,细节很多。以后要一点点补上这一系列设计智慧。

Lethe着重于保证用户定义阈值内的持久性删除,和快速的大范围secondary range delete,trade-off也是可调的,很有创新性。

一点困惑:F图,似乎效果不尽人意;能否在完成这些功能的同时,及时高并发的外部读写请求?怎么基于Lethe的思想,利用好存储介质本身的特性,做进一步的优化?

代价分析还没完全看懂。论文的定性定量分析方法,也值得一学。



附图RUM的优化(不完整)。

image

你可能感兴趣的:(数据库存储引擎LSM)