HBase---LSM树_hbase global mapper lsmtree

参考—>开源网—LSM
参考—>B树、B+树、LSM树 区别

LSM-Tree(Log Structured Merge Tree)

LSM树的索引结构本质是将写入操作全部转化成磁盘的顺序写入，极大地提高了写入操作的性能。但是，这种设计对读取操作是非常不利的，因为需要在读取的过程中，通过归并所有文件来读取所对应的KV，这是非常消耗IO资源的。因此，在HBase中设计了异步的compaction来降低文件个数，达到提高读取性能的目的。由于HDFS只支持文件的顺序写，不支持文件的随机写，而且HDFS擅长的场景是大文件存储而非小文件，所以上层HBase选择LSM树这种索引结构是最合适的。

HBase选择顺序读写来代替随机读写的原因，如下图：

由于顺序读写的速度比起随机读写的快的不止一点点，再加上当数据量达到TB级别的时候，这个选择就非常有必要。

由于LSM结构是一种append-only-tree,文件是不支持修改的，只是通过追加方式，插入新的数据代替原来的数据，这种做法能够保证更快的实现数据的更新（不用去查询这个数据具体在哪里），但是由于追加的数据逐渐的增多，导致存储问题。所以HBase系统会周期性的执行合并操作（compaction)。 合并操作选择一些文件，并把他们合并到一起，移除重复的更新或者删除纪录，同时也会删除上述的冗余。更重要的是，通过减少文件个数的增长，保证读操作的性 能。因为sstable文件都是有序结构的，所以合并操作也是非常高效的。

其实写并不是我们看到的那么快（从客户端看到的），其实这是一种假象，HBase将我们要写入的数据会写到内存中（MemStore），之后会异步地将数据溢写到磁盘上。

上面也提到了HBase牺牲了读的性能，来实现顺序写入。当然，HBase并没有放弃文件的读性能，HBase是通过如下方式进行提高读性能的。

• 维护并减少sstable文件的个数
• 布隆过滤器（检索数据）

维护减少sstable文件个数
当一定数量的sstable文件被创建，例如有5个sstable，每一个有10行，他们被合并为一个50行的文件（或者更少的行数）。这个过程一 直持续着，当更多的有10行的sstable文件被创建，当产生5个文件时，它们就被合并到50行的文件。最终会有5个50行的文件，这时会将这5个50 行的文件合并成一个250行的文件。这个过程不停的创建更大的文件。（这就是HBase中HFile小文件过多时，会合并成一个大文件）像下图：

布隆过滤器：参考链接