1. LSM（Log-StructuredMerge-Tree）树
随着NoSQL系统尤其是类BigTable系统的流行，LSM的文件系统越来越让人熟知。LSM主要用于为那些长期具有很高记录更新（插入和删除）频率的文件提供低成本的索引机制。LSM树实现了所有的索引值对于所有的查询来说都可以通过内存组件或某个磁盘组件进行访问。LSM减少了磁盘磁壁的移动次数降低了进行数据插入时磁盘磁壁的开销。LSM在进行需要即时响应的操作时会损失I/O效率，最适用于索引插入比查询操作多的情况。

2. lSM树 VS B+树
2.1 B+树
众所周知，RDBMS一般采用B+树作为索引的数据结构，如图1。RDBMS中的B+树一般是3层n路的平衡树。B+树的节点对应于磁盘数据块。因此对于RDBMS，数据更新操作需要5次磁盘操作（从B+树3次找到记录所在数据块，再加上一次读和一次写）。

在RDBMS中，数据随机无序写在磁盘块中，如果没有B+树，读性能会很低。B+树对于数据读操作能很好地提高性能，但对于数据写，效率不高。对于大型分布式数据系统，B+树还无法与LSM树相抗衡。

图1 B+ 树
B+树最大的性能题问是会发生大批的随机IO，随着新数据的插入，叶子点节会渐渐裂分，逻辑上连续的叶子点节在物理上往往不连续，甚至分离的很远，但做围范查询时，会发生大批读随机IO。

对于大批的随机写也一样，举一个插入key跨度很大的例子，如7->1000->3->2000 … 新插入的数据存储在磁盘上相隔很远，会发生大批的随机写IO.

2.2 LSM树
LSM树全称是基于日志结构的合并树（Log-Structured Merge-Tree）。No-SQL数据库一般采用LSM树作为数据结构，HBase也不例外。
LSM树可以看成n层合并树。在Hbase中，它把随机写转换成对memstore和hfile的连续写。图2展示了LSM树数据写的过程。

图2 LSM树

数据写（插入，更新）：数据首先顺序写如hlog (WAL), 然后写到MemStore, 在MemStore中，数据是一个2层B+树(图2中的C0树）。MemStore满了之后，数据会被刷到storefile (hFile)，在storefile中，数据是3层B+树（图2中的C1树），并针对顺序磁盘操作进行优化。

数据读：首先搜索MemStore,如果不在MemStore中，则到storefile中寻找。

数据删除：不会去删除磁盘上的数据，而是为数据添加一个删除标记。在随后的major compaction中，被删除的数据和删除标记才会真的被删除。

LSM数据更新只在内存中操作，没有磁盘访问，因此比B+树要快。对于数据读来说，如果读取的是最近访问过的数据，LSM树能减少磁盘访问，提高性能。
LSM树实质上就是在读写之间得取衡平，和B+树比相，它牲牺了部份读性能，用来大幅进步写性能。