LSM-Tree 大数据索引技术

最新推荐文章于 2024-04-20 11:59:30 发布

??yy

最新推荐文章于 2024-04-20 11:59:30 发布

阅读量700

点赞数

文章标签：大数据数据结构与算法 python

原文链接：https://my.oschina.net/peakfang/blog/2249902

版权

2019独角兽企业重金招聘Python工程师标准>>>

一、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树），并针对顺序磁盘操作进行优化。