LSM树理解
image.png
对比三种引擎的实现：
- hash存储引擎：哈希表持久化的实现，可以快速支持增删改查等随机操作，且时间复杂度为o(1)，但是不支持顺序读取扫描，对应的存储系统为k-v存储系统的实现。
- b树存储引擎是b树的持久化实现，不仅支持单条记录的增删改查操作，还支持顺序扫描，对应的存储系统就是mysql。
- lsm树存储引擎和b树存储引擎，一样支持，增删改查，也支持顺序扫描操作。LSM牺牲了读性能，提高写性能。
LSM的原理：将对数据的修改增量保存在内存中，达到指定大小限制之后批量把数据flush到磁盘中，磁盘中树定期可以做merge操作，合并成一棵大树，以优化读性能。不过读取的时候稍微麻烦一些，读取时看这些数据在内存中，如果未能命中内存，则需要访问较多的磁盘文件。极端的说，基于LSM树实现的hbase写性能比mysql高了一个数量级，读性能却低了一个数量级。
LSM树原理把一颗大叔拆分成N颗小树，它首先在内存中，它首先写入内存中，随着小树越来越大，内存中的小树会flush到磁盘中，磁盘中的树定期可以做merge操作，合并成为一个大叔，用来优化读性能。
image
以上就是hbase存储设计的重要思想，这里说明一下：
- 因为数据是先写到内存中，所以为了防止内存数据丢失，会先把数据写入hlog中，也符合了数据库中标准，先写日志，再写数据
- memstore上的树达到一定大小之后，需要flush到磁盘中，然后再定期做合并，提高读取的性能；
关于LSM Tree，对于最简单的二层lsm而言。
image
lsm tree，理论上，可以是内存中树的一部分和磁盘中一层数做merge，对于磁盘中的树直接做update操作有可能会破坏物理block的连续性，在实际场景中，一般lsm有多层，当磁盘中的小树合并成为一个大树的时候，可以重新排好顺序，使block连续，优化读性能。
hbase在视线中，是把整个内存在一定阈值后，flush到disk中，形成一个hfile文件。这个file的存储也是一个小的b+树，因为hbase是存储在hdfs上，hdfs不支持更新操作，所以hbase的数据也是定期flush到磁盘中，而不是和文件中的hfile做合并操作。
