LSM存储模型

序

摘自：

https://zhuanlan.zhihu.com/p/37193700

 

LSM

LSM（log-structed-merge-tree）

常常用于 HBase、BigTable、Cassandra、MongoDB等NoSql底层的存储模型就是LSM。

Hbase 学习过程中也使用到了LSM模型，所以就重新来梳理下LSM模型。

 

背景

 

大家都知道磁盘的顺序读写速度很快，随机读写很慢。

现在市面上7200rpm的希捷SATA硬盘顺序读写基本都能达到300MB/s；

但是随机读写却很慢，100 IOPS，假设随机读写每次IO大小为1KB，则随机读写数据带宽为100KB/s。

顺序读写和随机读写差了三个数量级。

 

所以我们要尽可能的创建一些顺序读写的文件块，来帮助我们进行文件的查找读取。

 

针对磁盘的上述特性，应用都根据自身业务做一些读写特点做一些优化。

 

Mysql怎么做的

大家都很熟悉Mysql关系型数据库的内部构造和存储结构了，

Mysql的innodb存储引擎底层用B+树数据结构来组织磁盘上的数据，

B+ Tree演示：

https://www.cs.usfca.edu/~galles/visualization/BPlusTree.html

可能需要梯子

 

B+树因其节点的度远大于平衡二叉树

度就是一个Node保存的数据

平衡二叉树的度为2

 

所以B+树树高很低（一般为3~4），每一次数据的查询只需3~4次磁盘随机IO即可查找到数据，效率很高；

说法不太准确，其实是找到数据所在的page 16K，加载到内存中，

再以二分法查找数据，内存二分查找所耗时间远小于磁盘IO，可忽略不计

 

但是insert和update操作是随机的，update隐藏的含义先找到更新的primary-key，更新，调整B+树；

所以在进行写入的过程中，需要对B+ Tree进行更改

这意味着我们需要把需要更改的节点拿出来，然后更改值。

 

查找primary-key的过程很高效，但是调整B+树的磁盘IO开销却很大，因此关系型数据库mysql的写效率一致饱受诟病。

那有没有一种替代B+树的数据组织模型，在不太影响读效率的前提下，提高数据的写效率？

由O'Neil提出的LSM存储模型LSM paper就是解决上述问题的。

 

 

LSM如何解决B+ 的写效率问题

 

对于B+ Tree 的写效率问题，LSM是这样进行解决的：

简单来说，就是放弃部分磁盘读性能来换取写的顺序性。

我们假设要写入一个1000个key是随机数的数据，

对磁盘来说，最快的写入方式一定是顺序地将每一次写入都直接写入到磁盘中即可。

但这样带来的问题是，没办法查询，因为每次查询一个值都需要遍历整个数据才能找到，这个读性能就太差了；

那么如果我想获取磁盘读性能最高，应该怎么做呢？把数据全部排序就行了。

B+树就是这样的结构，但B+树的写性能太差了，需要提升写，可以放弃部分磁盘读性能，怎么办呢？

 

划分很多个小的有序的结构。

比如每M个数据，在内存里排序一次，下面100个数据，再排序一次……

这样依次做下去，我就可以获得N/M个有序的小的有序结构。

这样我每次排序在内存中，然后写入磁盘都是一个结构大小进行顺序写入，写效率得到提升。

 

那么怎么查询呢？

所以就从每个最小的有序结构进行查找，查找到所有有序结构或者需要的结构后进行返回。

那么每次有序结构的查询就为：

    log2M

    二分查找

 

总花费时间为：

    N/M * log2M

    N  总数据量

    M 有序结构大小

 

所以可以看到LSM是牺牲了读的效率来换取了写的效率。

或许我们其实还是觉得不够，所以HBase后续还有布隆过滤器bloomfilter和compaction机制。

当然每个数据结构都有自己的好坏，需要酌情使用。

可参考：RocksDBwiki

 

 

HBase为什么选用LSM? 

 

B+索引树和log型（append）文件操作（数据库WAL日志）是数据读写的两个极端。

B+树读效率高而写效率差；

log型文件操作写效率高而读效率差；

因此要在排序和log型文件操作之间做个折中，于是就引入了log-structed merge tree模型。

通过名称可以看出LSM既有日志型的文件操作，提升写效率，又在每个sstable中排序，保证了查询效率。

非常符合HBase这样需要大量分布式写入的格式。