LSM-tree原理与应用

转自：https://cloud.tencent.com/developer/news/340271

LSM-tree 在 NoSQL 系统里非常常见，基本已经成为必选方案了。今天介绍一下 LSM-tree 的主要思想，再举一个 LevelDB 的例子。

正文 3056 字，预计阅读时间 8 分钟。

LSM-tree

起源于 1996 年的一篇论文《The Log-Structured Merge-Tree (LSM-Tree)》，这篇论文 32 页，我一直没读，对 LSM 的学习基本都来自顶会论文的背景知识以及开源系统文档。今天的内容和图片主要来源于 FAST'16 的《WiscKey: Separating Keys from Values in SSD-conscious Storage》。

先看名字，log-structured，日志结构的，日志是软件系统打出来的，就跟人写日记一样，一页一页往下写，而且系统写日志不会写错，所以不需要更改，只需要在后边追加就好了。各种数据库的写前日志也是追加型的，因此日志结构的基本就指代追加。注意他还是个 “Merge-tree”，也就是“合并-树”，合并就是把多个合成一个。

好，不扯淡了，说正文了。

LSM-tree 是专门为 key-value 存储系统设计的，key-value 类型的存储系统最主要的就两个个功能：

① put（k，v）写入一个（k，v）；

② get（k）给定一个 k 查找 v。

LSM-tree 最大的特点就是写入速度快，主要利用了磁盘的顺序写，pk掉了需要随机写入的 B-Tree。关于磁盘的顺序和随机写可以参考：《硬盘的各种概念》

下图是 LSM-tree 的组成部分，是一个多层结构，就跟一个树一样，上小下大。LSM树分为两个部分，一部分在磁盘一部分在内存，当内存空间逐渐被占满之后，LSM会把这些有序的键刷新到磁盘，同时和磁盘中的LSM树合并成一个文件。如下图所示首先是内存的 C0 层，保存了所有最近写入的（k，v），这个内存结构是有序的，并且可以随时原地更新，同时支持随时查询。剩下的 C1 到 Ck 层都在磁盘上，每一层都是一个在 key 上有序的结构。

写入流程：一个 put（k，v）操作来了，首先追加到写前日志（Write Ahead Log，也就是真正写入之前记录的日志）中，接下来加到 C0 层。当 C0 层的数据达到一定大小，就把 C0 层和 C1 层合并，类似归并排序，这个过程就是compaction（合并）。合并出来的新的 new-C1 会顺序写磁盘，替换掉原来的 old-C1。当 C1 层达到一定大小，会继续和下层合并。合并之后所有旧文件都可以删掉，留下新的。

注意数据的写入可能重复，新版本需要覆盖老版本。什么叫新版本，我先写（a=1），再写（a=233），233 就是新版本了。假如 a 老版本已经到 Ck 层了，这时候 C0 层来了个新版本，这个时候不会去管底下的文件有没有老版本，老版本的清理是在合并的时候做的。

写入过程基本只用到了内存结构，compaction 可以后台异步完成，不阻塞写入。

查询流程：在写入流程中可以看到，最新的数据在 C0 层，最老的数据在 Ck 层，所以查询也是先查 C0 层，如果没有要查的 k，再查 C1，逐层查。

一次查询可能需要多次单点查询，稍微慢一些。所以 LSM-tree 主要针对的场景是写密集、少量查询的场景。

LSM-tree 被用在各种键值数据库中，如 LevelDB，RocksDB，还有分布式行式存储数据库 Cassandra 也用了 LSM-tree 的存储架构。

LevelDB

其实光看上边这个模型还有点问题，比如将 C0 跟 C1 合并之后，新的写入怎么办？另外，每次都要将 C0 跟 C1 合并，这个后台整理也很麻烦啊。这里以 LevelDB 为例，看一下实际系统是怎么利用 LSM-tree 的思想的。

下边这个图是 LevelDB 的架构，首先，LSM-tree 被分成三种文件，第一种是内存中的两个 memtable，一个是正常的接收写入请求的 memtable，一个是不可修改的immutable memtable。

另外一部分是磁盘上的 SStable （Sorted String Table），有序字符串表，这个有序的字符串就是数据的 key。SStable 一共有七层（L0 到 L6）。下一层的总大小限制是上一层的 10 倍。

写入流程：首先将写入操作加到写前日志中，接下来把数据写到 memtable中，当 memtable 满了，就将这个 memtable 切换为不可更改的 immutable memtable，并新开一个 memtable 接收新的写入请求。而这个 immutable memtable 就可以刷磁盘了。这里刷磁盘是直接刷成 L0 层的 SSTable 文件，并不直接跟 L0 层的文件合并。

每一层的所有文件总大小是有限制的，每下一层大十倍。一旦某一层的总大小超过阈值了，就选择一个文件和下一层的文件合并。就像玩 2048 一样，每次能触发合并都会触发，这在 2048 里是最爽的，但是在系统里是挺麻烦的事，因为需要倒腾的数据多，但是也不是坏事，因为这样可以加速查询。

这里注意，所有下一层被影响到的文件都会参与 Compaction。合并之后，保证 L1 到 L6 层的每一层的数据都是在 key 上全局有序的。而 L0 层是可以有重叠的。

（关于这个图我觉得合理的解释应该是绿色的a=3，与L0的a=4其中一个写错了，他们应该是一个值）

上图是个例子，一个 immutable memtable 刷到 L0 层后，触发 L0 和 L1 的合并，假如黄色的文件是涉及本次合并的，合并后，L0 层的就被删掉了，L1 层的就更新了，L1 层还是全局有序的，三个文件的数据顺序是 abcdef。

虽然 L0 层的多个文件在同一层，但也是有先后关系的，后面的同个 key 的数据也会覆盖前面的。这里怎么区分呢？为每个key-value加个版本号。所以在 Compaction 时候应该只会留下最新的版本。

查询流程：先查memtable，再查 immutable memtable，然后查 L0 层的所有文件，最后一层一层往下查。

LSM-tree读写放大

读写放大（read and write amplification）是 LSM-tree 的主要问题，这么定义的：读写放大 = 磁盘上实际读写的数据量 / 用户需要的数据量。注意是和磁盘交互的数据量才算，这份数据在内存里计算了多少次是不关心的。比如用户本来要写 1KB 数据，结果你在内存里计算了1个小时，最后往磁盘写了 10KB 的数据，写放大就是 10，读也类似。

写放大：我们以 RocksDB 的 Level Style Compaction 机制为例，这种合并机制每次拿上一层的所有文件和下一层合并，下一层大小是上一层的 r 倍。这样单次合并的写放大就是 r 倍，这里是 r 倍还是 r+1 倍跟具体实现有关，我们举个例子。

假如现在有三层，文件大小分别是：9，90，900，r=10。又写了个 1，这时候就会不断合并，1+9=10，10+90=100，100+900=1000。总共写了 10+100+1000。按理来说写放大应该为 1110/1，但是各种论文里不是这么说的，论文里说的是等号右边的比上加号左边的和，也就是10/1 + 100/10 + 1000/100 = 30 = r * level。个人感觉写放大是一个过程，用一个数字衡量不太准确，而且这也只是最坏情况。

读放大：为了查询一个 1KB 的数据。最坏需要读 L0 层的 8 个文件，再读 L1 到 L6 的每一个文件，一共 14 个文件。而每一个文件内部需要读 16KB 的索引，4KB的布隆过滤器，4KB的数据块（看不懂不重要，只要知道从一个SSTable里查一个key，需要读这么多东西就可以了）。一共 24*14/1=336倍。key-value 越小读放大越大。

总结

关于 LSM-tree 的内容和 LevelDB 的设计思想就介绍完了，主要包括写前日志 WAL，memtable，SStable 三个部分。逐层合并，逐层查找。LSM-tree 的主要劣势是读写放大，关于读写放大可以通过一些其他策略去降低。

LSM-tree原理与应用相关推荐

LSM Tree 学习笔记——MemTable通常用 SkipList 来实现
最近发现很多数据库都使用了 LSM Tree 的存储模型,包括 LevelDB,HBase,Google BigTable,Cassandra,InfluxDB 等.之前还没有留意这么设计的原因,最近 ...
odoo tree视图过滤数据_数据存储结构 LSM Tree PK B TREE (从底层了解数据库设计)...
随着使用数据库的深度和理解能力的提升,有一个问题硬件的提升,与数据量的变化是否对数据库底层的架构有冲击. 我们公认的BTREE B+TREE 是否还能面对现在的硬件的变化. BTREE 到底是为那 ...
tidb mysql hbase_HBase/TiDB都在用的数据结构：LSM Tree，不得了解一下？
LSM Tree(Log-structured merge-tree)广泛应用在HBase,TiDB等诸多数据库和存储引擎上,我们先来看一下它的一些应用: 参考资料[4]这么牛X的名单,你不想了解下L ...
B+/-Tree原理及mysql的索引分析
B+/-Tree原理 B-Tree介绍 B-Tree是一种多路搜索树(并不是二叉的): 1.定义任意非叶子结点最多只有M个儿子:且M>2: 2.根结点的儿子数为[2, ...
行为树 Behavior Tree 原理
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明. 本文链接: https://blog.csdn.net/LIQIANGEASTSUN/arti ...
LSM tree(日志结构合并树)_笔记
WAL:Write Ahead Log 写前日志,顺序日志文件 1 LSM tree的定义 LSM tree: Log-Structured-Merge-Tree,日志结构合并树. Log-Struc ...
行为树 Behavior Tree 原理一
行为树 Behavior Tree 原理一行为树结构图如下,一棵倒置的树行为树采用节点描述行为逻辑,主要节点类型有: 组合节点:选择节点.顺序节点.随机选择节点.随机顺序节点.随机权重节点.并 ...
对于LSM Tree写放大问题的一些浅薄学习
本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可. 本作品 (李兆龙博文, 由李兆龙创作),由李兆龙确认,转载请注明版权. 文章目录引言性能评估优化方案 ...
【大数据哔哔集20210112】Sorry，Hbase的LSM Tree真的可以为所欲为！
点击上方蓝色字体,选择"设为星标" 回复"资源"获取更多惊喜我们先抛出一个问题: LSM树是HBase里使用的非常有创意的一种数据结构.在有代表性的关系型数据 ...
LSM Tree介绍及其应用
1. LSM Tree介绍 1.1 概念 B+树读效率高而写效率差:log型文件操作写效率高而读效率差:因此要在排序和log型文件操作之间做个折中,于是就引入了log-structed merge ...

LSM-tree原理与应用

LSM-tree原理与应用相关推荐

最新文章

热门文章