8、LSM树

爱欧米

已于 2023-03-10 11:07:21 修改

阅读量487

点赞数

分类专栏： # 数据结构文章标签：数据结构 lsm-tree

于 2023-03-10 00:19:20 首次发布

本文链接：https://blog.csdn.net/god8816/article/details/129434054

版权

数据结构专栏收录该内容

13 篇文章 0 订阅

订阅专栏

文章详细介绍了LSM树的数据结构定义，包括其内存与磁盘的层次结构、有序性、合并机制等特点。通过对插入、删除、修改和查询操作的分析，揭示了LSM树高写入性能和相对较低的读取性能。文章还讨论了LSM树的优缺点，适合高写入需求的NoSQL数据库使用。

摘要由CSDN通过智能技术生成

一、前言

最近在调研NoSQL数据库，发现RocksDB、LevelDB、HBase以及Prometheus等，其底层的存储引擎都是基于LSM树，于是决定花时间彻底吃透LSM树这一数据结构。

不幸的是，在查阅资料学习的过程中，发现网上各种文章汗牛充栋、抄来抄去，不是文不对题就是不知所云。

一气之下决定自己写一篇出来消消气，便有了这篇文章。。。

PS：学了这么多数据结构，LSMTree应该是最年轻的一个，它在1996年被设计出来(属老鼠的)，年纪比我还小~

相比于B/B+树或者倒排索引，LSMTree采用了“疯狂到不顾一切”的干啥都磁盘顺序写的方案，赋予了它无与伦比的写吞吐量。

二、LSM树数据结构定义

查阅了一些资料，LSM树并没有一种固定死的实现方式，更多的是一种将：

“磁盘顺序写” + “多个树(状数据结构)” + “冷热（新老）数据分级” + “定期归并” + “非原地更新”这几种特性统一在一起的思想。

为了方便后续的讲解分析，我们尝试先对LSM树做一个定义。

LSM树的定义：

LSM树是一个横跨内存和磁盘的，包含多颗"子树"的一个森林。
LSM树分为Level 0，Level 1，Level 2 ... Level n 多颗子树，其中只有Level 0在内存中，其余Level 1-n在磁盘中。
内存中的Level 0子树一般采用排序树（红黑树/AVL树）、跳表或者TreeMap等这类有序的数据结构，方便后续顺序写磁盘。
磁盘中的Level 1-n子树，本质是数据排好序后顺序写到磁盘上的文件，只是叫做树而已。
每一层的子树都有一个阈值大小，达到阈值后会进行合并，合并结果写入下一层。
只有内存中数据允许原地更新，磁盘上数据的变更只允许追加写，不做原地更新。

以上6条定义组成了LSM树，如图1所示。

图1 LSM树的组成和定义（狗日的知乎把我高清图片压缩了。。。）

图1中分成了左侧绿色的内存部分和右侧蓝色的磁盘部分（定义1）。
图1左侧绿色的内存部分只包含Level 0树，右侧蓝色的磁盘部分则包含Level 1-n等多棵"树"（定义2）
图1左侧绿色的内存部分中Level 0是一颗二叉排序树（定义3）。注意这里的有序性，该性质决定了LSM树优异的读写性能。
图1右侧蓝色的磁盘部分所包含的Level 1到Level n多颗树，虽然叫做“树”，但本质是按数据key排好序后，顺序写在磁盘上的一个个文件（定义4），注意这里再次出现了有序性。
内存中的Level 0树在达到阈值后，会在内存中遍历排好序的Level 0树并顺序写入磁盘的Level 1。同样的，在磁盘中的Level n（n>0）达到阈值时，则会将Level n层的多个文件进行归并，写入Level n+1层。（定义5）
除了内存中的Level 0层做原地更新外，对已写入磁盘上的数据，都采用Append形式的磁盘顺序写，即更新和删除操作并不去修改老数据，只是简单的追加新数据。图1中右侧蓝色的磁盘部分，Level 1和Level 2均包含key为2的数据，同时图1左侧绿色内存中的Level 0树也包含key为2的数据节点。（定义6）

下面我们遵循LSM树的6条定义，通过动图对LSM树的增、删、改、查和归并进行详细分析。

三、插入操作

LSM树的插入较简单，数据无脑往内存中的Level 0排序树丢即可，并不关心该数据是否已经在内存或磁盘中存在。（已经存在该数据的话，则场景转换成更新操作，详见第四部分）

图2展示了，新数据直接插入Level 0树的过程。

图2 LSM树的插入操作示例

如上图2所示，我们依次插入了key=9、1、6的数据，这三个数据均按照key的大小，插入内存里的Level 0排序树中。该操作复杂度为树高log(n)，n是Level 0树的数据量，可见代价很低，能实现极高的写吞吐量。

四、删除操作

LSM树的删除操作并不是直接删除数据，而是通过一种叫“墓碑标记”的特殊数据来标识数据的删除。

删除操作分为：待删除数据在内存中、待删除数据在磁盘中和该数据根本不存在三种情况。

3.1 待删除数据在内存中：

如图3所示，展示了待删除数据在内存中的删除过程。我们不能简单地将Level 0树中的黄色节点2删除，而是应该采用墓碑标记将其覆盖（思考题：为什么不能直接删除而是要用墓碑标记覆盖呢）

图3 LSM树删除操作示例——待删除数据在内存中时

3.2 待删除数据在磁盘中：

如图4所示，展示了待删除数据在磁盘上时的删除过程。我们并不去修改磁盘上的数据（理都不理它），而是直接向内存中的Level 0树中插入墓碑标记即可。

图4 LSM树删除操作示例——待删除数据在磁盘中时

3.3 待删除数据根本不存在：

这种情况等价于在内存的Level 0树中新增一条墓碑标记，场景转换为情况3.2的内存中插入墓碑标记操作。

综合看待上述三种情况，发现不论数据有没有、在哪里，删除操作都是等价于向Level 0树中写入墓碑标记。该操作复杂度为树高log(n)，代价很低。

五、修改操作

LSM树的修改操作和删除操作很像，也是分为三种情况：待修改数据在内存中、在磁盘中和该数据根本不存在。

4.1 待修改数据在内存中：

图5 LSM树修改操作示例——待修改数据在内存中时

如图5所示，展示了待修改数据在内存中的操作过程。新的蓝色的key=7的数据，直接定位到内存中Level 0树上黄色的老的key=7的位置，将其覆盖即可。

4.2 待修改数据在磁盘中：

图6 LSM树修改操作示例——待修改数据在磁盘中时

如图6所示，展示了待修改数据在磁盘中的操作过程。LSM树并不会去磁盘中的Level 1树上原地更新老的key=7的数据，而是直接将新的蓝色的节点7插入内存中的Level 0树中。

4.3 该数据根本不存在：

此场景等价于情况b，直接向内存中的Level 0树插入新的数据即可。

综上4.1、4.2、4.3三种情况可以看出，修改操作都是对内存中Level 0进行覆盖/新增操作。该操作复杂度为树高log(n)，代价很低。

我们会发现，LSM树的增加、删除、修改（这三个都属于写操作）都是在内存中倒腾，完全没涉及到磁盘操作，所以速度飞快，写吞吐量高的离谱。。。

六、查询操作

LSM树的查询操作会按顺序查找Level 0、Level 1、Level 2 ... Level n 每一颗树，一旦匹配便返回目标数据，不再继续查询。该策略保证了查到的一定是目标key最新版本的数据（有点MVCC的感觉）。

我们来分场景分析：依然分为待查询数据在内存中和待查询数据在磁盘中两种情况。

5.1 待查询数据在内存中：

如图7所示，展示了待查询数据在内存中时的查询过程。

图7 LSM树查询操作示例——待查询数据在内存中时

沿着内存中已排好序的Level 0树递归向下比较查询，返回目标节点即可。我们注意到磁盘上的Level 1树中同样包括一个key=6的较老的数据。但LSM树查询的时候会按照Level 0、1、2 ... n的顺序查询，一旦查到第一个就返回，因此磁盘上老的key=6的数据没人理它，更不会作为结果被返回。

5.2 待查询数据在磁盘中：

如图8所示，展示了待查询数据在磁盘上时的查询过程。

图8 LSM树查询操作示例——待查询数据在磁盘中时

先查询内存中的Level 0树，没查到便查询磁盘中的Level 1树，还是没查到，于是查询磁盘中的Level 2树，匹配后返回key=6的数据。

综合上述两种情况，我们发现，LSM树的查询操作相对来说代价比较高，需要从Level 0到Level n一直顺序查下去。极端情况是LSM树中不存在该数据，则需要把整个库从Level 0到Level n给扫了一遍，然后返回查无此人（可以通过布隆过滤器 + 建立稀疏索引来优化查询操作）。代价大于以B/B+树为基本数据结构的传统RDB存储引擎。

六、合并操作

合并操作是LSM树的核心（毕竟LSM树的名字就叫: 日志结构合并树，直接点名了合并这一操作）

之所以在增、删、改、查这四个基本操作之外还需要合并操作：一是因为内存不是无限大，Level 0树达到阈值时，需要将数据从内存刷到磁盘中，这是合并操作的第一个场景；二是需要对磁盘上达到阈值的顺序文件进行归并，并将归并结果写入下一层，归并过程中会清理重复的数据和被删除的数据(墓碑标记)。我们分别对上述两个场景进行分析：

LSM树

6.1 内存数据写入磁盘的场景：

如图9所示，展示了内存中Level 0树在达到阈值后，归并写入磁盘Level 1树的场景。