首页 技术 正文
技术 2022年11月14日
0 收藏 459 点赞 3,992 浏览 2231 个字

Introduction

主流的基于LSM树的KV存储都在两方面进行权衡,一方面是写入更新的开销,另一方面是查询和存储空间的开销。但它们都不是最优的,问题在于这些存储系统在LSM树的每一个level上都采用相同且开销很大的合并策略。论文中提出了Lazy Leveling和Fluid LSM-tree来解决这个问题,同时提出了Dostoevsky模型。

问题的根源

  • 写入更新:写入更新的开销主要来自于之后涉及写入的项的合并操作,虽然更大的level上合并操作的代价越大,但是更大的level上合并操作的发生频率更低,因此写入更新在每一个level上花费的代价均等。
  • 点查找:可以最小化所有bloom过滤器的FPR之和,以此来减小点查找的代价,当然这也意味着对更小的level的访问频率可能会呈指数级别的下降,因此大多数点查询最终发生在最大的level上。
  • 大范围查找:不同level的容量呈指数级别的放大,因此最大的level包含了大多数的数据,那么就更可能包含给定范围的数据,所以大多数大范围查询最终发生在最大的level上。
  • 小范围查找:小范围查找只涉及每个run中的一个block,由于所有level上的run的最大个数是确定的,因此小范围查找在每一个level上花费的代价均等。
  • 空间放大:最坏情况下,除了最大level外的所有level中的key在最大level中都有重复,因此空间放大主要来自于最大的level。

DESIGN SPACE AND PROBLEM ANALYSIS

tiering和leveling的开销对比如下图(图来自论文)所示:

Dostoevsky: Better Space-Time Trade-Offs for LSM-Tree Based Key-Value Stores via Adaptive Removal of Superfluous Merging 阅读笔记

Dostoevsky: Better Space-Time Trade-Offs for LSM-Tree Based Key-Value Stores via Adaptive Removal of Superfluous Merging 阅读笔记

  1. 写入更新

    • tiering:一个项在一个level只涉及一次合并操作,花费O(1)时间,一共有L个level,一次合并操作中一次I/O读取一个block涉及B个项,均摊到每个项的开销为O(L/B)。
    • leveling:上一个level的每一个run移动到当前level都会触发一次合并操作,因此一个项在一个level上平均会涉及T/2次合并操作,其他分析同tiering,开销为O(L·T/B)。
  2. 点查询

    最坏情况为零结果点查询。

    • tiering:对于零结果点查询,开销来自于当一个run上的bloom过滤器有误报时产生的一次I/O(读取这个run),每个level中最多可能有T个run,一共有L个level,bloom过滤器的FPR是e^(-M/N),因此开销为O(e^(-M/N)·L·T)。
    • leveling分析同tiering,开销为O(e^(-M/N)·L)。

    当然Monkey模型在不同的level上设置不同的bloom过滤器,可以将点查询的开销优化为上图中的开销。

  3. 空间放大

    1到L-1的level包含了LSM树1/T的容量,第L个level包含了LSM树(T-1)/T的容量。

    • tiering:最坏情况为第L个level中的每个run都包含相同的key,1到L-1的level中的key在第L个level中的每个run中都有重复,因此空间放大为O(T)。
    • leveling:最坏情况为1到L-1的level中的key在第L个level中都有重复的key,因此空间放大为O(1/T)。

优化的空间:减少不必要的合并操作,点查询、范围查询和空间放大的开销主要取决于最大的level,而写入更新在每一个level上的开销均等。因此较小的level上的合并操作显著增大写入更新的开销,而对于减少点查询、范围查询和空间放大的开销却没有特别多的帮助。

Lazy Leveling

主要结构:在最大的level采用leveling的合并策略,在其余level采用tiering的合并策略。

与leveling的对比:

  1. 提升了更新写入的性能
  2. 点查询、大范围查询和空间放大的复杂度相同
  3. 小范围查询的性能相似

tiering、leveling、lazy leveling三者开销对比如下图(图来自论文)所示:

Dostoevsky: Better Space-Time Trade-Offs for LSM-Tree Based Key-Value Stores via Adaptive Removal of Superfluous Merging 阅读笔记

  1. 点查询的分析涉及bloom过滤器的设置,就是个数学问题,详见论文附录。
  2. 写入更新:1到L-1的level的写入更新开销分析同tiering,第L个level的写入更新开销分析同leveling。
  3. 空间放大:分析同leveling。

Fluid LSM-Tree

最大的level最多有Z个run,其余level最多有K个run,每一个level有个active run用于合并来自上一个level的run,且这个active run有容量限制,最大的level限制为T/Z,其余level限制为T/K。当一个level中的所有run的容量总和超过了当前level的限制,这些run合并入下一个level。

开销如下图(图来自论文)所示:

Dostoevsky: Better Space-Time Trade-Offs for LSM-Tree Based Key-Value Stores via Adaptive Removal of Superfluous Merging 阅读笔记

  1. 点查询的分析涉及bloom过滤器的设置,就是个数学问题,详见论文附录。
  2. 写入更新:分析同tiering。
  3. 空间放大:最坏情况是1到L-1的level的key均在第L个level有重复,第L个level中有Z-1个run包含的全部都是重复的key。

Dostoevsky模型

写入更新的开销为W,零结果点查询的开销为R,有结果点查询的开销为V,范围查询的开销为Q,通过统计以上四种操作在工作负载中的比例,赋予这四种开销权重系数w、r、v、q,另外计从存储中读取一个block的时间为Ω。我们可以得到吞吐τ的计算公式为:

τ = Ω^-1 · (w · W + r · R + v · V + q · Q)^-1

在实际运行时可以通过对K、Z、T三个参数的动态调整来使得吞吐达到最优。

389 Love u

相关推荐
python开发_常用的python模块及安装方法
adodb:我们领导推荐的数据库连接组件bsddb3:BerkeleyDB的连接组件Cheetah-1.0:我比较喜欢这个版本的cheeta…
日期:2022-11-24 点赞:878 阅读:9,082
Educational Codeforces Round 11 C. Hard Process 二分
C. Hard Process题目连接:http://www.codeforces.com/contest/660/problem/CDes…
日期:2022-11-24 点赞:807 阅读:5,557
下载Ubuntn 17.04 内核源代码
zengkefu@server1:/usr/src$ uname -aLinux server1 4.10.0-19-generic #21…
日期:2022-11-24 点赞:569 阅读:6,406
可用Active Desktop Calendar V7.86 注册码序列号
可用Active Desktop Calendar V7.86 注册码序列号Name: www.greendown.cn Code: &nb…
日期:2022-11-24 点赞:733 阅读:6,179
Android调用系统相机、自定义相机、处理大图片
Android调用系统相机和自定义相机实例本博文主要是介绍了android上使用相机进行拍照并显示的两种方式,并且由于涉及到要把拍到的照片显…
日期:2022-11-24 点赞:512 阅读:7,815
Struts的使用
一、Struts2的获取  Struts的官方网站为:http://struts.apache.org/  下载完Struts2的jar包,…
日期:2022-11-24 点赞:671 阅读:4,898