LSM-Tree树原理

什么是LSM-Tree

LSM-Tree 即 Log Structrued Merge Tree，这是一种分层有序，硬盘友好的数据结构。核心思想是利用磁盘顺序写性能远高于随机写。

LSM-Tree 并不是一种严格的树结构，而是一种内存+磁盘的多层存储结构。HBase、LevelDB、RocksDB这些 NoSQL 存储都使用了 LSM-Tree。

LSM-Tree简介

LSM Tree（Log Structure Merge Tree）是一种数据结构，是一种基于日志追加写、有一定结构、并且会merge合并的树（数据结构）

特点

• 利用磁盘批量的顺序写要远比随机写性能高出很多来支持随机读写操作
• 更适用于写多读少类型的场景
• 广泛应用在各大 NoSQL 中。比如基于 LSM 树实现底层索引结构的 RocksDB，就是 Facebook 用 Golang 对 LevelDB 的实现，Hbase也是用LSM-Tree的数据结构实现的

LSM的组成部分

MemTable

MemTable 是 LSM-Tree 在内存中的数据结构，只用于保存最新的数据，按照 Key 有序地组织这些数据。

LSM-Tree 没有规定用怎样的数据结构实现 MemTable，例如 HBase 使用跳表来保证内存中 Key 的有序性。

存在内存中的数据会因为断电丢失，所以我们通常使用 WAL，即预写日志的方式来保证数据的可靠。

WAL: 预写日志，即事务的所有修改在提交之前要先写入 log 文件中

Immutable MemTable

MemTable 达到一定大小后，会转化为 Immutable MemTable。Immutable MemTable 是将 MemTable 转为磁盘上的 SSTable 的一种中间状态。

转化过程中写操作由新的 MemTable 处理，过程中不阻塞数据更新操作。

SSTable

SSTable 是有序键值对集合，是 LSM 树在磁盘中的数据结构。它是一种持久化、有序且不可变的键值村存储结构

SSTable 内部包含一系列可配置大小的 Block 块。这些 Block 的 index 会被存储在 SSTable 的尾部，用于帮助快速查找特定的 Block。当一个 SSTable 被打开时，index 表会被加载到内存，然后根据 key 在内存 index 中进行一个二分查找，查到该 key 对应的磁盘的 offset 后，去磁盘把响应的块数据读取出来。

MemTable 达到一定大小会被 flush 到硬盘中变成 SSTable。在不同的 SSTable 中可能存在相同的 Key 记录。但这样会带来一些问题：

• 冗余存储。对于某个 Key，除了最新的记录，其他记录都是冗余无用的。所以我们需要进行 Compact 操作（合并多个 SSTable），来清除冗余的记录。
• 读取时需要从最新的 SSTable 出发进行查询，最坏情况下药查询完所有的 SSTable。可以通过索引或布隆过滤器来优化查找速度。

LSM-Tree读写数据

LSM-Tree写数据流程

• WAL当收到写请求，先将数据记录在 WAL Log 中，用作故障恢复。把操作同步到磁盘中WAL做备份（追加写、性能极高）

• Memtable完成WAL后将(k,v)数据写入内存中的Memtable，Memtable的数据结构一般是跳表或者红黑树

  内存内采用这种数据结构一方面支持内存内高速增删改查（时间复杂度O(logM)），另一方面可以保持有序，为写入磁盘中的SSTable打基础

  • 如果是删除，则做墓碑标记
  • 如果是更新，则新记录一条数据

• Immutable Memtable

  • MemTable 达到一定大小后，在内存中冻结，成为不可变的 ImmuTable MemTable。同时也要生成新的 MemTable 来提供服务。

• **Minor Compaction ** SSTable的数据结构是LSM-Tree设计的精髓，他一方面可以保持有序，一方面又能利用磁盘追加写的高性能。

  • 内存中不可变的 MemTable 被 dump 到硬盘上的 SSTable 中，这也称为 **Minor Compaction。**注意 L0 层的 SSTable 是没有合并的，所以 key 在多个 SSTable 中往往会重叠、冗余。
  • 当每层 SSTable 超过一定大小，就会周期性的进行合并，这也称为 Major Compaction。这个阶段回清除掉荣誉的数据，防止浪费空间。由于 SSTable 都是有序的，可以使用归并排序进行高效合并。

Major Compaction merge

当level 0中的segment越来越多，查询需要遍历的segment也就会越来越多，并且随着时间的推移，重复的key也会越来越多，在后面的步骤就需要对level 0层的segment进行合并merge。

合并的过程中是吧多个有序的segment进行归并合并，所以性能不会很差，多个老的segment会合并成一个更长的同样有序的segment并设置到下一层每一层的segment的数量和大小都会有限制，每当超出限制后，就会做合并操作。

• 虽然定期合并可以有效的清除无效数据，缩短读取路径提升查询效率，提高磁盘利用空间。但Compaction操作是非常消耗CPU和磁盘IO的，尤其是在业务高峰期，如果发生了Major Compaction，则会降低整个系统的吞吐量，这也是一些NoSQL数据库，比如Hbase里面常常会禁用Major Compaction，并在凌晨业务低峰期进行合并的原因。

LSM-Tree读数据流程

• 当收到读请求，现在内存中查询，查询到就返回。
• 如果没有查询到，由内存到磁盘，在各级 SSTable 中依次下沉，直到得到结果
  • 按照Memtable（内存）、Immutable Memtable（内存）、level 0 segments（磁盘）、level 1 segments（磁盘）、level 1 segments（磁盘）的顺序查询
  • 每层先查新生成的segment，每个segment从后向前查。

LSM-Tree的Compact策略

Compact 是 LSM 树中的关键操作，只有 Compact 的策略合理，才能及时有效地清除冗余的数据。介绍以下几个概念:

• **读放大。**读取数据时实际读取的数据量大于真正的数据量。例如在不同层次的 Table 中查找。
• **写放大。**写入数据时实际写入的数据量大于真正的数据量。例如写入时触发 Compact，导致写入大量数据。
• **空间放大。**数据占用的磁盘空间比真正的数据大小要大很多。即冗余存储。

size-tiered策略

size-tiered 策略保证每层中每个 SSTable 的大小相近，同时限制每一层 SSTable 的数量。

每层限制有 N 个 SSTable，每层数量达到 N 后，触发 Compact 操作来合并这些 SSTable，放入下一层成为更大的 SSTable。

当层数越来越大，单个 SSTable 的大小也会越来越大。该策略会导致空间放大比较严重。对每一层的 SSTable 来说，每个 key 的记录也可能存在多份。只有该层执行 Compact 操作才会消除这些冗余记录。

leveled策略

leveled 策略限制每一层总文件的大小。

**leveld 同样将每一层划分为大小相近的 SSTable。并保证在一层内全局有序。**这意味着与一个 Key 在每一层至多只有一条记录，不存在冗余记录。

leveled 策略相比 size-tiered 策略来说，每层内的 Key 是有序、不重复的。这样就很好地控制了冗余 Key 的量。

查询优化

查询过程中我们发现，在原始情况下，我们需要遍历所有的 SSTable。我们考虑以下方式，尝试优化查询的效率。

• **压缩。**SSTable可以进行压缩，而且不是压缩整个 SSTable。而是根据局部性原理将数据分组。每个分组分别压缩。这样读取数据的时候我们就不需要解压缩整个文件，而是解压缩部分 Group 即可读取。
• **缓存。**SSTable 除了进行 Compaction，其他情况下是不可变的。所以我们可以将一次扫描到的 Block 进行缓存，提高下一次检索的效率。
• **索引/布隆过滤器。**正常情况下，一次读操作需要读取所有 SSTable，再将结果合并后返回。但是对某些 Key 而言，有些 SSTable 根本不包含对应数据。所以我们可以为每个 SSTable 添加布隆过滤器。来判断当前 SSTable 有没有我们需要的 Key。
• **合并。**合并本身肯定可以优化数据的组织情况，提高查询效率。但是也要注意查询是非常消耗 CPU 和磁盘 IO 的操作。一般我们选在业务量不大的凌晨等情况进行合并。

为什么LSM不直接顺序写入磁盘，而是需要在内存中缓冲一下

单条写的性能没有批量写快，很多中间件比如elasticsearch、kafka、mysql都有类似的内存缓冲设计

在磁盘缓冲的另一个好处是，针对新增的数据，可以直接查询返回，能够避免一定的IO操作

LSM-Tree和B+Tree的比较

• LSM-Tree的优点是支持高吞吐的写O1，这个特点在分布式系统上更为看重针对读取普通的LSM-Tree结构，读取是On的复杂度在使用索引或者缓存优化后的也可以达到O(logN)的复杂度。适用于写多读少

• B+tree的优点是支持高效的读（稳定的O(logN)）但是在大规模的写请求下（O(LogN)），效率会变得比较低，因为随着insert的操作，为了维护B+树结构，节点会不断的分裂和合并。操作磁盘的随机读写概率会变大，故导致性能降低。适用于写少读多或写读平衡

• LSM-Tree 的写放大问题比 B-Tree 要好一些。因为 B 树写入的页分裂操作实在太消耗磁盘 IO。

• LSM-Tree 可以支持更好的压缩。由于碎片，B-Tree 无法使用某些磁盘空间，而 LSM-Tree 会定期重写来消除碎片。

• LSM_Tree 在执行压缩操作时，很容易发生读写请求等待的问题。而 B-Tree 的响应延迟则更具确定性。

• B-Tree 中的每个键都位于索引中的每个位置，而日志结构的存储引擎可能在不同的段中有相同键的多个副本。如果数据库希望提供严格的事务语义，B-Tree 要更容易实现一些，因为锁可以定义到树中。

• LSM_Tree 在执行压缩操作时，很容易发生读写请求等待的问题。而 B-Tree 的响应延迟则更具确定性。

• B-Tree 中的每个键都位于索引中的每个位置，而日志结构的存储引擎可能在不同的段中有相同键的多个副本。如果数据库希望提供严格的事务语义，B-Tree 要更容易实现一些，因为锁可以定义到树中。