可动态适应的lsm树合并方法及系统的制作方法
【技术领域】
[0001]本发明涉及文件处理技术领域，尤其涉及一种可动态适应的LSM树合并方法及系统。
【背景技术】
[0002]Log-structured merge树，也被称为LSM树，是目前NoSQL数据库常用的数据组织方式。它把对索引的变更进行延迟和批量处理，并通过类似归并排序的方式高效地将更新迀移到磁盘。LSM树的节点在具体实现中往往就是一个文件，文件内部有序，文件之间无序，查询时需要查询所有文件，合并每个文件的结果，从而造成性能低下，所以一般会把若干个文件合并成一个大文件，通过合并文件，减少文件数量，真正删除数据，以减少每次查询涉及到的文件数，提高数据的查询效率，即Compact。Compact过程会读多个文件合并后重新写成文件，这会占用大量磁盘I/O等相关资源，而不当的Compact或不及时的Compact又会造成查询时涉及过多文件而使它的性能下降。目前主流的合并方法:Tiered Compact、LevelDB Compact 和 Stripe Compact。
[0003]1.Tiered Compact 策略如下:
[0004](I)首先将候选文件按照入库时间(Sequence ID，即顺序号)从旧到新排序，候选集为正在合并的文件之后的文件；
[0005](2)如果请求是一个Major Compact，如果目前的文件列表是所有的文件，则进行Major Compact，否则不能进行 Major Compact ；
[0006](3)如果列表文件数量小于配置的合并最小文件数量阈值，则放弃做MinorCompact ；
[0007](4)使用一个rat1参数，选取按照从老到新的顺序进行，遍历每个文件时，如果它的大小小于所有比它新的文件的和与rat1的乘积，则它是一个候选；
[0008](5)选取处理的文件个数大于配置的合并最小文件数量阈值，则进行MinorCompact,否则放弃执行。
[0009]该方法和系统简单易实现，完成合并操作以后能够提升读性能，但是合并过程本身的代价是比较大的，在更新密集型的操作中，这样就会带来以下问题:
[0010](I)数据分布不一致，一行数据可能在一个文件中，也可能跨越多个文件，最坏情况下可能每个文件中都有，这样针对不同key查询时涉及到的文件数量不同，查询性能不稳定;
[0011](2)浪费大量1/0，一个文件可能执行多次合并，滚雪球似的反复被重写。没有考虑数据的分布，如不变化的key区间其实是不需要再被合并的了，但是在这个算法中仍然会执行这不必要的合并；
[0012](3)只有Major Compact时才会清除掉删除数据，而Major Compact由于需要合并重写所有文件，消耗资源比较严重，执行时间很长，所以不会频繁执行，一般一天执行一次。那么由于无法保证删除的数据要多久才能被清除，在删除密集型操作中，有大量空间可能被浪费；
[0013](4)合并过程中旧的文件只有在新的文件写入完成后才能删除，需要额外占用磁盘空间。Major Compact要将所有的文件合并重写，使得临时磁盘空间到达原来的两倍。
[0014]2.LevelDB Compact 策略如下:
[0015](I)当Level-L的文件总大小超过阈值时，后台线程进行合并；
[0016](2)从Level-L中选出一个文件，从LeVel-(L+l)中选出与它的键值范围交叠的文件。Level-O比较特殊，因为Level-O的文件键值是互相交叠的，所以需要特别处理从Level-O到Level-1的合并:如果文件之间有键值交叠，可能需要从Level-O中选出多于一个文件；
[0017](3)合并线程读取这些文件内容，归并排序生成一系列Level-(L+1)文件，当生成文件的大小超过2MB的时候就转而生成一个新文件来写入，还有与当前键值范围交叠的Level-(L+2)文件超过了 10个时，那么也需要转而生成一个新文件来写入，这样可以保证后续Level-(L+1)文件的合并不会挑选出太多Level-(L+2)的文件；
[0018](4)当新文件生成并服务后，老的文件就会被舍弃；
[0019](5)对于一个Level，文件合并的顺序是轮流的，记录上次此Level合并的最大键值(end key)，下次此Level合并的时候则选择此键值开始的第一个文件(如果没有则转回此Level的第一个文件)；
[0020](6)合并清除同一个键的旧数据，也会清除删除标记影响的数据，当更高Level中没有此键值范围的文件就可以清除删除标记。
[0021]算法的好处是在合并的过程中，仅需由两个Level的部分文件参与，而不是要对所有文件执行合并操作，这样会加快合并执行的效率。大部分的读操作有LRU特性，都会落入较低的Level上。因此，数据越“热”，Level就越低，有利于多种存储介质的合理使用。
[0022]算法的主要问题是它无法动态调整Level层数，如果Level过多，在递归合并的过程中，容易造成某个区间的合并风暴，并且每次下推都需要重写文件。此外，不同Level之间的键值没有对应关系，上层Level的键值区间对应下层Level的区间事先无法预测，当上层Level的某一个文件需要与下层Level合并的时候，对下层Level的影响范围并不存在确定性，由当前的键值范围影响。
[0023]3.Stripe Compact 策略如下:
[0024](I)对于Reg1n下的键值区间进行二次切分，分成更多小区间，每个区间即为Stripe ；
[0025](2) Reg1n下的数据文件分为Level-Ο和Level-Ι两层。其中Level-Ο包括整个键值区间，从内存中刷写下来的文件和批量导入产生的文件默认放在Level-O ;
[0026](3)当Level-O文件积累到阈值时，通过合并把Level-O的文件切分到Level_l，每个键值与其相交的Stripe都会形成一个文件放入相应Stripe ；
[0027](4) Stripe内部可以进行合并以防止Stripe文件数过多；
[0028](5) Stripe的切分有两种方式:基于个数的方式(Count-based)和基于大小的方式(Size-based)；
[0029](6)读取时，一个键值所涉及的数据范围有内存、Level-Ο所有文件、以及Level-1中对应的Stripe的文件；
[0030](7)容错机制。在Level-1的Stripe间的键值范围应该是连续的，如果出现异常情况导致Stripe之间存在空洞，那么可将所有Level-1的文件重新放回Level-O ;
[0031]Stripe合并保留了分层的优势的同时，降低了层级数量和文件个数，有利于Reg1n的分裂和合并。它的问题在于Level-1中Stripe的分布和数量很难动态调整，如果Stripe过小，从Level-O刷写下来的文件就会过小；如果Stripe过大，Stripe区间很大，每个Stripe中会遇到与Reg1n内部Tiered Compact同样的问题。
[0032]现有技术无法动态适应数据的分布，数据的组织方式无法随着数据的分布不同而高效地动态调整，合并效率低下，经常做一些无用的合并，占用系统资源。
[0033]综上可知，现有技术在实际使用上显然存在不便与缺陷，所以有必要加以改进。
【发明内容】
[0034]针对上述的缺陷，本发明的目的在于提供一种可动态适应的LSM树合并方法及系统，其可以动态适应数据的分布，提高数据合并效率。
[0035]为了实现上述目的，本发明提供一种可动态适应的LSM树合并方法，所述方法包括:
[0036]将键值区间划分为若干节点，将所述节点组织为树形结构，每个所述节点对应一键值区间，每个所述键值区间包含对应该键值区间范围的文件；
[0037]根据当前数据的分布动态调整树的形状；
[0038]当有新写入的文件时，遍历树寻找最适节点放入；
[0039]对文件进行处理时，对节点内部进行Minor Compact处理，并且只通过叶节点执行Major Compact。
[0040]根据本发明的可动态适应的LSM树合并方法，所述树形结构的根节点对应完整的键值区间；
[0041]所述树形结构的子节点是父节点的划分，所有子节点的键值区间组合起来形成所述父节点的键值区间，且各个子节点对应的键值区间之间相互连续、互斥无重合。
[0042]根据本发明的可动态适应的LSM树合并方法，所述根据当前数据的分布动态调整树的形状步骤包括:
[0043]根据当前数据的分布动态调整树的节点数量和/或树的高度和/或树的度。
[0044]根据本发明的可动态适应的LSM树合并方法，所述方法还包括:
[0045]当文件中缺失了所在的节点信息时，遍历树寻找最适节点放入所述文件。