【数据库】LSMTree的并行压缩设计

1. LSMTree的并行压缩

1.1 分层存储的原因

通过归并排序实现分层,可以实现在常数次数的查找下可以确定key在哪一个SST文件中,从而提高性能。


1.2 压缩规则的设计

1.2.1 实现目标

  1. 实现一种从Lx到Ly的压缩(归并排序)sst的分层机制,提高查询的效率
  2. 在压缩过程中,正确识别无效key并删除,提高空间的利用率

我们将实现这个功能的组件命名为Compactor。

  • Compact组件在LSM初始化阶段创建后台执行的协程,周期性地检查levelManager中levels管理地各层状态,通过状态信息适时来触发Compact
    在这里插入图片描述
  • 当触发compact的条件之后,根据levels中的元信息生成压缩计划,指定出发层与到达层,以及涉及的两层sst的filename.
  • 执行compact任务时,对于所有选中的sst文件构建一个迭代器,逐个获取合并之后的kv数据,写入table builder之中,完成迭代之后flush到目标层上。

1.2.2 compact算法设计

1.2.2.1 基础方法
  1. L0层的sst是直接从memtable中落盘的,内部保证有序,但是sst之间必然存在重叠区间,每次L0层文件数量或者SST文件的总字节数到达一个阈值时就会触发合并。
  2. L1到L6层的合并,只需要在当前level的size超过阈值之后选择其中fid最小的sst文件即可,和下一层的所有sst文件判断是否存在重叠之后选中有重叠的文件然后执行多路归并生成新的sst文件。
  3. 在合并过程中遇到同一个key的不同版本时,必须要对至少两个sst文件实施归并排序,有序每个SST文件有序,不同key按照升序排序,相同的key按照版本的降序排序,因此合并时只需要写入第一个key,忽然剩余版本。

1.2.2.2 优化方法

  1. L0层无需,合并时涉及较多sst,如何优化读写延迟?

    • 合并时对于涉及的SST加读锁,保证依旧可以对外提供检索,而minor的过程只会向L0添加新的SST,因此可以保证无阻塞。当compact结束后再删除sst文件,此时无法避免阻塞。
    • 对于L0层的查询最坏情况下可能要遍历所有的SST文件,因此对L0层SST文件进行自压缩,可以有效减少L0层sst文件的数量。
  2. compact过程中需要从Ln到Ln+1,一个有效的key至少经过7次的移动,写放大严重

    • 如果Lmax层没有达到预期的容量,可以直接实现L0到Lmax的压缩,即跨层级压缩,来减少写放大的可能性
  3. Lmax层作为最终层,无法被压缩到下一层,可能会造成数据倾斜。

    • 实现L6层的自压缩,清理L6层的无效数据
  4. 为了充分发挥SSD的并行度,如何实现并行compact压缩,来提高性能?

    • 对level级别和table级别都加上读写互斥锁,维护一个全局的关于SST的状态表,记录每一个压缩任务的执行状态以及涉及的SST是哪些,在生成压缩计划的时候,检查其互斥性,如果当前压缩任务涉及的sst文件与正在执行的其他压缩任务没有冲突则执行,否则认定为失败

当面对从Lx到Ly层的压缩时,L0层根据SST文件的数量来决定压缩效益最大化,其他层则根据每个level的出去正在压缩状态的sst文件的总size数量与每一层的期望size的比值作为优先级(每个level的期望size之间差一个数量级,最终LSMtree呈现金字塔形状)
同时为了避免频繁的压缩计划冲突,在多个并发执行的压缩器初始化时,给予一个500ms左右的随机时间,使得每个压缩器执行的并发性被打散,降低冲突可能性。
为了避免迭代器的range过程中破坏了block的缓存,需要系统正确识别迭代器场景,跳过set cache的过程。
在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Ornamrr

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值