LSM树以及在hbase中的应用

转自：http://www.cnblogs.com/yanghuahui/p/3483754.html

讲LSM树以前，须要提下三种基本的存储引擎，这样才能清楚LSM树的由来：

• 哈希存储引擎  是哈希表的持久化实现，支持增、删、改以及随机读取操做，但不支持顺序扫描，对应的存储系统为key-value存储系统。对于key-value的插入以及查询，哈希表的复杂度都是O(1)，明显比树的操做O(n)快,若是不须要有序的遍历数据，哈希表就是your Mr.Right
• B树存储引擎是B树（关于B树的由来，数据结构以及应用场景能够看以前一篇博文）的持久化实现，不只支持单条记录的增、删、读、改操做，还支持顺序扫描（B+树的叶子节点之间的指针），对应的存储系统就是关系数据库（Mysql等）。
• LSM树（Log-Structured Merge Tree）存储引擎和B树存储引擎同样，一样支持增、删、读、改、顺序扫描操做。并且经过批量存储技术规避磁盘随机写入问题。固然凡事有利有弊，LSM树和B+树相比，LSM树牺牲了部分读性能，用来大幅提升写性能。

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

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

 

以上这些大概就是HBase存储的设计主要思想，这里分别对应说明下：

• 由于小树先写到内存中，为了防止内存数据丢失，写内存的同时须要暂时持久化到磁盘，对应了HBase的MemStore和HLog
• MemStore上的树达到必定大小以后，须要flush到HRegion磁盘中（通常是Hadoop DataNode），这样MemStore就变成了DataNode上的磁盘文件StoreFile，按期HRegionServer对DataNode的数据作merge操做，完全删除无效空间，多棵小树在这个时机合并成大树，来加强读性能。

 

关于LSM Tree，对于最简单的二层LSM Tree而言，内存中的数据和磁盘你中的数据merge操做，以下图

图来自lsm论文

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

hbase在实现中，是把整个内存在必定阈值后，flush到disk中，造成一个file，这个file的存储也就是一个小的B+树，由于hbase通常是部署在hdfs上，hdfs不支持对文件的update操做，因此hbase这么总体内存flush，而不是和磁盘中的小树merge update，这个设计也就能讲通了。内存flush到磁盘上的小树，按期也会合并成一个大树。总体上hbase就是用了lsm tree的思路。