LSM-Tree 大数据索引技术

两盒软妹~` 提交于 2019-12-01 15:52:30

一、LSM-Tree概述

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

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

LSM Tree优化方式

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

三、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中,被删除的数据和删除标记才会真的被删除。

 

 

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!