LSM树(Log-Structured Merge Tree)存储引擎浅析

2019独角兽企业重金招聘Python工程师标准>>> hot3.png

其实每一种数据库,它都是一种抽象的数据结构的具体实现。

随着rocksDB(facebook的),levelDB(google的),以及我们熟知的hbase,他们都是使用的LSM树结构的数据库。

它的核心思路其实非常简单,就是假定内存足够大,因此不需要每次有数据更新就必须将数据写入到磁盘中,而可以先将最新的数据驻留在内存中,等到积累到最后多之后,再使用归并排序的方式将内存内的数据合并追加到磁盘队尾(因为所有待排序的树都是有序的,可以通过合并排序的方式快速合并到一起)。下图是最简单的二层LSM Tree.

LSM树(Log-Structured Merge Tree)存储引擎浅析_第1张图片

图来自lsm论文

lsm tree,理论上,可以是内存中树的一部分和磁盘中第一层树做merge,对于磁盘中的树直接做update操作有可能会破坏物理block的连续性,但是实际应用中,一般lsm有多层,当磁盘中的小树合并成一个大树的时候,可以重新排好顺序,使得block连续,优化读性能。

一般数据库的存储一定要保持有序,有序是一个非常重要的概念(当然hash结构的除外,hash不支持顺序扫描,对应的存储系统为key-value存储系统。对于key-value的插入以及查询,哈希表的复杂度都是O(1),明显比树的操作O(n)快,如果不需要有序的遍历数据,哈希表就是your Mr.Right ).

LSM树相比于B+树(大量的叶节点操作,不仅支持单条记录的增、删、读、改操作,还支持顺序扫描(B+树的叶子节点之间的指针)对B树的写入过程是一次原位写入的过程,主要分为两个部分,首先是查找到对应的块的位置,然后将新数据写入到刚才查找到的数据块中,然后再查找到块所对应的磁盘物理位置,将数据写入去。当然,在内存比较充足的时候,因为B树的一部分可以被缓存在内存中,所以查找块的过程有一定概率可以在内存内完成,不过为了表述清晰,我们就假定内存很小,只够存一个B树块大小的数据吧。可以看到,在上面的模式中,需要两次随机寻道(一次查找,一次原位写),才能够完成一次数据的写入,代价还是很高的。 ), 弄了很多个小的有序结构,比如每m个数据,在内存里排序一次,下面100个数据,再排序一次……这样依次做下去,我就可以获得N/m个有序的小的有序结构。 在查询的时候,因为不知道这个数据到底是在哪里,所以就从最新的一个小的有序结构里做二分查找,找得到就返回,找不到就继续找下一个小有序结构,一直到找到为止。 很容易可以看出,这样的模式,读取的时间复杂度是(N/m)*log2N 。读取效率是会下降的。

LSM树原理把一棵大树拆分成N棵小树,它首先写入内存中,随着小树越来越大,内存中的小树会flush到磁盘中,磁盘中的树定期可以做merge操作,合并成一棵大树,以优化读性能。

总结为,LSM树并不是像B+树单次在磁盘寻址,根据索引来进行写入。而是大量堆集内存,达到一定阈值后,写入磁盘,因为是批量处理,磁盘IO对其性能影响很小,对写操作的性能大大提升。然后再磁盘内再进行合并(Merge)操作,再来提升读性能,可见,对于即时读取的性能不高,不可能写进去马上就读出来,而是要经过一个Merge的过程。

转载于:https://my.oschina.net/u/3768341/blog/1861086

你可能感兴趣的:(数据库,python,数据结构与算法)