REMIX: Efficient Range Query for LSM-trees

REMIX: Efficient Range Query for LSM-trees

   基于lsm树的key-value (KV)存储以多级结构组织数据以实现高速写入。传统lsm -tree的范围查询必须在运行时从多个表文件中查找、排序和合并数据，代价昂贵且读取性能一般。为了提高lsm树的范围查询效率，提出了一种空间高效的KV索引数据结构REMIX，该结构记录了KV数据的全局排序视图，该视图横跨多个表文件。对多个remix索引的数据文件进行范围查询可以使用二分查找快速定位目标键，并按顺序检索后续的键，而无需进行键比较。我们构建了RemixDB，一个基于lsm树的KV-store，采用写效率高的合并策略，并利用RemixDB实现快速的点和范围查询。实验结果表明，remix能够显著提高基于写优化的lsm树KV-store的范围查询性能。 

一背景

     

1）它们在内存中缓冲更新，并定期将更新刷新到持久存储，以生成不可变的表文件。然而，这也会影响搜索效率，因为一个范围内的键可能位于不同的表中，由于计算量和I/O成本高，可能会减慢查询速度。基于lsm树的设计体现了更新代价和搜索代价之间的权衡，与B+树相比，lsm树保持了较低的更新代价和较高的搜索代价。 

2）Bloom filters cannot handle range queries。当查询可以通过缓存回答时，访问过滤器的计算成本可能会导致平庸的性能，这在现实工作负载中经常是这样[2,8,13]。

二研究

      我们设计了REMIX，范围查询高效多表索引的缩写。现有的改进范围查询的解决方案在物理重写数据和执行昂贵的动态排序合并之间挣扎，REMIX采用了一种空间高效的数据结构来记录跨多个表文件的KV数据的全局排序视图。使用remix，基于lsm树的KV-store可以在不牺牲搜索性能的情况下利用写效率高的合并策略。

我们构建了RemixDB，一个基于mix索引的lsm树的KV-store。结合写效率高的分层合并策略和分区LSM-tree布局，RemixDB同时实现了低WA和快速查找。实验结果表明，remix能够有效提高在多重叠表上的范围查询性能。性能评估表明，RemixDB在同时读取和写入操作上的性能优于最先进的基于lsm树的KV-stores。

REMIX

REMIX的动机是通过保留底层表的排序视图并在未来的搜索中重用它们来利用表文件的不变性。

    为了提高I/O效率，基于lsm树的KV-stores采用了内存高效的元数据格式，包括稀疏索引和布隆过滤器[4]。如果我们记录每个键和它的位置，以在存储中保留排序视图，存储的元数据可能会显著膨胀，导致读写性能下降。为避免这个问题，REMIX数据结构必须是空间高效的。 

 下面是一个seek操作的例子。如图3所示，底部的四个框表示编码排序视图的REMIX元数据。注意，括号中的键不是元数据的一部分。要查找键17，需要使用二分查找选择第二段，其中包含键(11、17、23、29)。然后根据段的游标偏移量((1,2,1))，游标分别被放置在R0、R1和R2中的键11、17和31上。同时，将当前指针设置为指向该段的第一个run选择器(0，图中的第五个选择器)，表示当前键(11)在R0的游标下。因为11<17，迭代器需要改进以找到满足k≥17的最小键k。要前进迭代器，首先要前进R0上的游标，让它跳过键11，现在移动到键23上。迭代器的游标偏移量现在变成了2、2和1。然后，当前指针向前移动到该段的第二个运行选择器(1，图中的第六个选择器)。高级迭代器选择R1, R1游标下的当前键17就是目标键。查找操作到此结束。后续的键(23、29、31…)可以通过反复推进迭代器来检索排序视图。

RemixDB

为了评估REMIX的性能，我们实现了一个基于LSMtree的KV-store模型——RemixDB。RemixDB采用分级合并策略来实现最佳的写入效率

 图5显示了RemixDB的系统组件。与LevelDB和RocksDB类似，RemixDB将更新缓冲到MemTable中。同时，更新也被附加到WAL (write-ahead log，预写日志)中进行持久化。当缓存中的更新达到一个阈值时，MemTable会被转换成一个不可变的MemTable进行合并，并创建一个新的MemTable来接收更新。分区中的合并会创建分区的新版本，其中包含新旧表文件的混合，以及新的REMIX文件。旧版本在合并后被垃圾回收。

在多级LSM-tree设计中，一个MemTable的大小通常只有几十MBs，接近默认的SSTable大小。在分区存储布局中，较大的memtable可以在触发合并之前累积更多的更新[3,24]，这有助于减少WA。memtable和WAL具有几乎恒定的空间成本，考虑到当今数据中心的大内存和存储容量，这是适度的。在RemixDB中，MemTable的最大大小被设置为4 GB。接下来，我们将介绍文件结构(§4.1)、合并过程(§4.2)以及使用混音的成本和权衡(§4.3)。