论文阅读（６）：ｒｌｓｍ

２０１８　ＩＥＥＥ

Nae Young Song and Heon Young Yeom

Dept. of Computer Science and Engineering

Seoul National University

Efficient key-value stores with Ranged　Log-structured Merge Trees

 

摘要：针对的还是ＬＳＭ的写放大问题，提出了ｒａｎｇｅｄ　ｌｓｍ，简化了存储的逻辑结构，保持数据在无序状态。另外，通过把磁盘上的数据分为不交叠的多个文件来防止读性能下降。在ｈｂａｓｅ上实现的。

性能参数：减少了３ｘ的写放大（与原始数据量）．内存开销也下降２４％．

 

相关工作：ＬＳＭｔｒｉｅ，构建基于ｈａｓｈ的ｔｒｉｅ结构替代ｔｒｅｅ，减少ｃｏｍｐａｃｔ中的重排开销。

ＬＷＣ（１５）建议轻量级的ｃｏｍｐａｃｔ，ａｐｐｅｎｄ　ｄａｔａ按照ｋｅｙ　ｒａｎｇｅ，同步合并元数据。

ｐｅｂｂｌｅｓｄｂ使用ｇｕａｒｄ来维持ｄａｔａｒａｎｇｅ，尽管ｇｕａｒｄ内部可能无序。

１４，１５，１６，２０，２１，２３针对ｃｏｍｐａｃｔ的过程进行了优化。

本文思路：磁盘上只有两级的ｓｓｔａｂｌｅ文件，一级是ｆｌｕｓｈｅｄｆｉｌｅ，一级是ｃｏｍｐａｃｔｅｄｆｉｌｅ。另外，使用基于ｈａｓｈ的数据结构避免ｃｏｍｐａｃｔ过程中的开销，通过ａｐｐｅｎｄ来完成ｃｏｍｐａｃｔ。根据它的ｄａｔａｒａｎｇｅ选择一个ｆｉｌｅ　ｉｎｓｅｒｔ进去。

 

ｒｌｓｍ系统设计：

１．ｒｌｓｍ：

ｒｌｓｍ不要求数据严格有序，ｈａｓｈ　ｋｅｙ在ｈａｓｈ表中存储对应的数据，当内存ｂｕｆｆｅｒ满了之后，按照ｈａｓｈｅｄ的顺序被ｆｌｕｓｈ到文件（ｆｌｕｓｈｅｄｆｉｌｅ）中。

将ｃｏｍｐａｃｔ过程中的文件分为ｖｉｃｔｉｍ和ｔａｒｇｅｔ。然后只有ｖｉｃｔｉｍ的数据被加载到内存并重写到ｔａｒｇｅｔ。

因为ｆｌｕｓｈｅｄｆｉｌｅ是ｒａｎｇｅ交叠的，会造成严重的写放大，所以需要ｃｏｍｐａｃｔ，根据每个文件的ｋｅｙｒａｎｇｅ。

ｒｌｓｍ中每个文件都会记录最大和最小的ｋｅｙ。ｃｏｍｐａｃｔ过程中，ｖｉｃｔｉｍ中每个ｋｖ对都会ａｐｐｅｎｄ到ｋｅｙｒａｎｇｅ包括ｋ的ｔａｒｇｅｔ文件中（这样说，ｔａｒｇｅｔ应该是ｋｅｙｒａｎｇｅ不交叠吧）。数据在文件级别是有序的，即使内部是无序的。（感觉和ｐｅｂｂｌｅｓｄｂ很像，只是这个有序和无序的界限不一样，一个是文件级别（ｒｌｓｍ），一个是ｇｕａｒｄ文件区间（ｐｅｂｂｌｅｓｄｂ））。生成的文件叫做ｃｏｍｐａｃｔｅｄｆｉｌｅ。

没太弄明白，内存中为什么要按照ｈａｓｈｔａｂｌｅ来存放ｋｖ而不是跳表结构。（好像是，如果通过ｋｅｙｒａｎｇｅ确定ｋｅｙ在这个文件中后，将文件加载到内存，可以通过ｈａｓｈ来快速查找ｋｖ对）

 

ｃｏｍｐａｃｔ有几种情况：

１．ｌ１层没有文件，那么直接把ｌ０层文件ｄｏｗｎ到ｌ１层。

２．ｌ１层有文件，优先选择ｕｎｉｏｎｓｅｔ，然后是按照ｄｅｎｓｉｔｙ（ｋｖｎｕｍ/maxkey-minkey）

（１）ｖｉｍｃｉｍ　的ｋｅｙｒａｎｇｅ在ｔａｒｇｅｔｋｅｙｒａｎｇｅ范围内，直接ａｐｐｅｎｄ，不用修改元数据。

（２）对密度大的ｖｉｃｔｉｍ，ｋｖ更聚集，很可能会ｃｏｍｐａｃｔ到一个文件中。

文件的负载均衡：

在ｃｏｍｐａｃｔ过程中，很可能不同ｃｏｍｐａｃｔｅｄｆｉｌｅ到后期大小差别很大，从而在读取时造成巨大的差异。

策略是，当文件大小超出限制时，自动分区。使用的线性选择算法（２４），对列表数据重排找到第ｋ小的数据。时间复杂度为o(n)。

除了ｐａｒｔｉｔｉｏｎ，还有ｍｅｒｇｅ操作。

猜测，垃圾回收也是在ｐａｒｔｉｔｉｏｎ的迭代每个ｋｖ过程中完成的。

添加数据：

内存中用ｈａｓｈ表存放ｋｅｙ时，数据的文件偏移也会存放到ｈａｓｈ表中ｋｅｙ的对应位置，然后持久化到ｆｉｌｅｉｎｆｏ块中，其中还包括元数据（ｍａｘｋｅｙ，ｍｉｎｋｅｙ）。

数据索引策略，ｌ０层使用布隆过滤器，因为键值是交叠的。

ｌ１层使用索引树，每个ｎｏｄｅ代表一个ｃｏｍｐａｃｔｅｄｆｉｌｅ。因为ｆｉｌｅｓ间的ｋｅｙｒａｎｇｅ不交叠，可以使用二叉搜索树快速查找文件。

 

ｅｖａｌｕａｔｉｏｎ：基本没看点查询以及范围查询的性能比较。