LSM-Tree 大数据索引技术

1、LSM-Tree概述

        核心思想就是放弃部分读能力，换取写入能力的最大化。LSM-Tree ，这个概念就是结构化合并树（Log-Structured Merge Tree）的意思，它的核心思路其实很是简单，就是假定内存足够大，所以不须要每次有数据更新（插入、删除）就必须将数据写入到磁盘中，而能够先将最新的数据驻留在内存中，等到积累到必定限制大小以后，再使用归并排序的方式将内存中的数据合并追加到磁盘队尾(由于全部待合并的树都是有序的，能够经过合并排序的方式快速合并到一块儿)。
        磁盘的技术特性:对磁盘来讲，可以最大化的发挥磁盘技术特性的使用方式是:一次性的读取或写入固定大小的一块数据，并尽量的减小随机寻道这个操做的次数。
        日志结构的合并树（LSM-tree）是一种基于硬盘的数据结构，与B+ tree相比，能显著地减小硬盘磁盘寻道开销，并能在较长的时间提供对文件的高速插入（删除）。然而LSM-tree在某些状况下，特别是在查询须要快速响应时性能不佳。一般LSM-tree适用于索引插入比检索更频繁的应用系统。

2、LSM-Tree VS B+ Tree

B+Tree

        RDBMS通常采用B+树做为索引的数据结构。RDBMS中的B+树通常是3层n路的平衡树。B+树的节点对应于磁盘数据块。所以对于RDBMS，数据更新操做须要5次磁盘操做（从B+树3次找到记录所在数据块，再加上一次读和一次写）。在RDBMS中，数据随机无序写在磁盘块中，若是没有B+树，读性能会很低。B+树对于数据读操做能很好地提升性能，但对于数据写，效率不高。对于大型分布式数据系统，B+树还没法与LSM树相抗衡。

        

        B+树最大的性能题问是会发生大批的随机IO，随着新数据的插入，叶子点节会渐渐裂分，逻辑上连续的叶子点节在物理上每每不连续，甚至分离的很远，但作围范查询时，会发生大批读随机IO。
        对于大批的随机写也同样，举一个插入key跨度很大的例子，如7->1000->3->2000 … 新插入的数据存储在磁盘上相隔很远，会发生大批的随机写IO。

LSM-Tree

        LSM树原理把一棵大树拆分红N棵小树，它首先写入内存中，随着小树愈来愈大，内存中的小树会flush到磁盘中，磁盘中的树按期能够作merge操做，合并成一棵大树，以优化读性能。No-SQL数据库通常采用LSM树做为数据结构，HBase也不例外。

        

        LSM和Btree差别就要在读性能和写性能进行取舍。在牺牲的同时，寻找其余方案来弥补。
        一、LSM具备批量特性，存储延迟。当写读比例很大的时候（写比读多），LSM树相比于B树有更好的性能。由于随着insert操做，为了维护B树结构，节点分裂。读磁盘的随机读写几率会变大，性能会逐渐减弱。 屡次单页随机写，变成一次多页随机写,复用了磁盘寻道时间，极大提高效率。
        二、B树的写入过程:对B树的写入过程是一次原位写入的过程，主要分为两个部分，首先是查找到对应的块的位置，而后将新数据写入到刚才查找到的数据块中，而后再查找到块所对应的磁盘物理位置，将数据写入去。固然，在内存比较充足的时候，由于B树的一部分能够被缓存在内存中，因此查找块的过程有必定几率能够在内存内完成，不过为了表述清晰，咱们就假定内存很小，只够存一个B树块大小的数据吧。能够看到，在上面的模式中，须要两次随机寻道（一次查找，一次原位写），才可以完成一次数据的写入，代价仍是很高的。
        三、LSM Tree放弃磁盘读性能来换取写的顺序性，彷佛会认为读应该是大部分系统最应该保证的特性，因此用读换写彷佛不是个好买卖。内存的速度远超磁盘，1000倍以上。而读取的性能提高，主要仍是依靠内存命中率而非磁盘读的次数。
LSM数据更新只在内存中操做，没有磁盘访问，所以比B+树要快。对于数据读来讲，若是读取的是最近访问过的数据，LSM树能减小磁盘访问，提升性能。 LSM树实质上就是在读写之间得取衡平，和B+树比相，它牲牺了部份读性能，用来大幅进步写性能。

LSM Tree优化方式

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

3、Hbase对LSM-Tree的使用方式

        hbase在实现中，是把整个内存在必定阈值后，flush到disk中，造成一个file，这个file的存储也就是一个小的B+树，由于hbase通常是部署在hdfs上，hdfs不支持对文件的update操做，因此hbase这么总体内存flush，而不是和磁盘中的小树merge update。内存flush到磁盘上的小树，按期也会合并成一个大树。总体上hbase就是用了lsm tree的思路。
        由于小树先写到内存中，为了防止内存数据丢失，写内存的同时须要暂时持久化到磁盘，对应了HBase的HLog(WAL)和MemStore
MemStore上的树达到必定大小以后，须要flush到HRegion磁盘中（通常是Hadoop DataNode），这样MemStore就变成了DataNode上的磁盘文件StoreFile，按期HRegionServer对DataNode的数据作merge操做，完全删除无效空间，多棵小树在这个时机合并成大树，来加强读性能。
        数据写（插入，更新）：数据首先顺序写如hlog (WAL), 而后写到MemStore, 在MemStore中，数据是一个2层B+树(图2中的C0树）。MemStore满了以后，数据会被刷到storefile (hFile)，在storefile中，数据是3层B+树（图2中的C1树），并针对顺序磁盘操做进行优化。

        

        数据读：首先搜索BlockCache,再搜索MemStore,若是不在MemStore中，则到storefile中寻找。
        数据删除：不会去删除磁盘上的数据，而是为数据添加一个删除标记。在随后的major compaction中，被删除的数据和删除标记才会真的被删除。