Skip to content

Latest commit

 

History

History
34 lines (17 loc) · 2.93 KB

Choose-Level-Compaction-Files.md

File metadata and controls

34 lines (17 loc) · 2.93 KB

介绍

Level压缩风格是rocksdb默认的压缩风格,所以他也是用户间最常用的压缩风格。有时候用户会好奇level压缩在每次压缩的时候如何选择哪个文件进行压缩。在这wiki中,我们会在这个议题里面深入聊一下,节省你读代码的时间

步骤

从Level 0 到最高level,以选择第一个level,Lb,满足这个层的分数大于1,以此作为压缩的基础层。

决定压缩的输出层Lo = Lb + 1

根据不同的压缩优先选项,找到第一个需要被压缩的,优先级最高的文件。如果这个文件或者他在Lo的父母(就是那个key范围与他有交错的文件)正在被另一个压缩任务使用,跳过这个文件,使用第二高优先级的文件,知道找到一个候选文件。把这个文件加到压缩输入

不断拓展输入,直到我们确定 输入文件和周围的文件 有一个“清晰分离的”边界。这保证了压缩过程中,没有部分key被丢失。例如,我们有五个文件,key范围如下:

f1[a1 a2] f2[a3 a4] f3[a4 a6] f4[a6 a7] f5[a8 a9]

如果我们在第三步选择f3,然后在第四步,我们需要从{f3}拓展输入到{f2,f3,f4},因为f2和f3,f3和f4,的边界是连在一起的。之所以两个文件会有一个相同的用户key,是因为在rocksdb中,文件里的InternalKey会包含用户key原始信息,key的类型以及序列号。所以文件可能会存储多个用户key相同的InternalKey。因此,如果压缩发生,所有的用户key相同的InternalKey都需要被一起压缩。

检查当前的输入文件不会与任何已经在压缩的文件有交集。否则,尝试查找是否有可用的人工压缩。如果没有,放弃这次压缩挑选任务。

找出Lo上与输入文件有交集的文件,然后根据第四部的操作拓展他们,直到我们在Lo上有一个“清晰分离的”边界。如果他们中的任何文件正在被压缩,放弃这次压缩挑选任务。否则,把它们放入output_level_inputs

一个可选的优化步骤。检查我们是否可以进一步增加Lb的输入文件,同时不用改变我们挑选的Lo的文件。如果这会导致Lb包含一些用户key的InternalKey,而又排除其他的相同用户key的InternalKey,我们同样会选择不拓展,导致,“一个不清晰的分离”。这可能在用户key分散在多个文件的时候发生。前面的描述可能让人困惑,所以我给一个例子出来解释这个优化。

考虑一下例子:

Lb: f1[B E] f2[F G] f3[H I] f4[J M] Lo: f5[A C] f6[D K] f7[L O]

如果我们最开始在第三步选择f2,现在我们会压缩f2(输入)以及f6(第四步的output_level_inputs)。但是我们可以安全地压缩f2,f3和f6,而不用拓展输出level。

输入的文件和output_level_inputs的文件就是这次level压缩的候选文件了。