lsm tree java_LSM树（Log-Structured Merge Tree）存储引擎浅析

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

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

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

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的过程。