B+树和LSM树对比

B+树

B树存储引擎是B树的持久化实现，不仅支持单条记录的增、删、读、改操作，还支持顺序扫描（B+树的叶子节点之间的指针），对应的存储系统就是关系数据库（Mysql等）。

B+树将数据完全排序，读数据时很快，但当要修改数据时，就需要将新入数据下面的数据重新排位，特别是当写入的数据排在较高的位置时，需要大量的移位操作才能完成写入。

• 优点：数据完全排序，读数据时很快
• 缺点：修改数据时需要大量的移位操作才能完成写入，写入数据慢

LSM树

LSM树（Log-Structured Merge Tree）存储引擎和B树存储引擎一样，同样支持增、删、读、改、顺序扫描操作。而且通过批量存储技术规避磁盘随机写入问题。当然凡事有利有弊，LSM树和B+树相比，LSM树牺牲了部分读性能，用来大幅提高写性能。

LSM树的设计思想非常朴素：将对数据的修改增量保持在内存中，达到指定的大小限制后将这些修改操作批量写入磁盘，不过读取的时候稍微麻烦，需要合并磁盘中历史数据和内存中最近修改操作，所以写入性能大大提升，读取时可能需要先看是否命中内存，否则需要访问较多的磁盘文件。极端的说，基于LSM树实现的HBase的写性能比Mysql高了一个数量级，读性能低了一个数量级。

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

• 优点：底层用LSM树，顺序写入磁盘快
• 缺点：数据未排序，随机读取数据很慢

LSM树的优化

SLM牺牲部分读性能，从而提高写性能：将数据分散到多个有序列表中，每个列表保存一部分数据，这样读取数据时，就需要先查找在哪个有序列表，再从这个列表中读取具体数据，但是写的时候，受影响的数据就会减少，从而减少写入时间。

有以下2种方法优化读取时间：

• Bloom filter : 就是个带随即概率的bitmap,可以快速的告诉你，某一个小的有序结构里有没有指定的那个数据的。于是我就可以不用二分查找，而只需简单的计算几次就能知道数据是否在某个小集合里啦。效率得到了提升，但付出的是空间代价。
• 小树合并为大树： 也就是大家经常看到的compact的过程，因为小树性能有问题，所以要有个进程不断地将小树合并到大树上，这样大部分的老数据查询也可以直接使用log2N的方式找到，不需要再进行(N/m)*log2n的查询了。 

 

参考

https://blog.csdn.net/mingyuezh/article/details/80839868