LSM树笔记整理

LSM 树

1 简单介绍

LSM 树：Log Structured Merge Tree 日志结构合并树

许多NoSQL数据库比如RocksDB、LevelDB、HBase以及Cassandra等，其底层的存储引擎都是基于LSM树，本质是一个key/value存储引擎。

• 思想：

  • 写：将对数据的增删改存在内存中，达到指定的threadhold后将该批更改批量写入到磁盘，在批量写入的过程中跟已经存在的数据做rolling merge。可以简单总结为磁盘顺序写 + 多个树(状数据结构) + 冷热数据分级 + 定期归并 + 非原地更新
  • 读：需要merge disk上的数据和memory中的修改数据

• 核心思想：牺牲一些读性能换较高的写性能，主要利用磁盘批量的顺序写性能，减少频繁的插入、修改、删除数据操作所需要的磁盘I/O次数。

• 适合场景：写入远大于读取

2 实现

2.1 核心数据结构：SSTable（Sorted String Table，来自于 Google 的 Bigtable 论文）

• 有序、不可变的键值存储结构
• index存在尾部，用于帮助快速查找特定的Block
• 当一个SSTable被打开的时候，index会被加载到内存，然后根据key在内存index里面进行一个二分查找，查到该key对应的磁盘的offset之后，然后去磁盘把响应的块数据读取出来。

2.2 LSM 树

SSTable有一份在内存里面，其他的多级在磁盘上

• MemTable：
  • 在内存中保存最近更新的数据，按Key有序地组织这些数据，可以采用红黑树或者skiplist相关的数据结构（例如Hbase用skiplist来保证内存中key的有序。）
  • 通常会通过WAL(Write-ahead logging，预写式日志)的方式来保证数据的可靠性。
• Immutable MemTable
  • 当MemTable达到一定大小后，会转化成 Immutable MemTable。Immutable MemTable是将MemTable变为磁盘中的SSTable的一种中间状态
  • 写操作由新的MemTable处理，在转存过程中不阻塞数据更新操作。
• SSTable(Sorted String Table)
  • 有序键值对集合
  • 为了加快SSTable的读取，可以通过建立key的索引以及布隆过滤器来加快key的查找。
• 分层
  • 在硬盘上有多个排序的数据文件，尺寸不同。例如：1GB内存作为L0层，一个10GB的硬盘文件作为L1层，一个100GB的硬盘文件作为L2，1TB为L3层，…，1000TB为L6层。

2.3 写入

收到一个写请求：（数据插入、修改、删除等操作记录）

1. 先把该条数据记录在WAL里面，用作故障恢复。
2. 把该条数据写入内存的Memtable里面（删除也是写入，删除数据会写入一条墓碑标记，更新是新记录一条的数据）
3. 当Memtable超过一定的大小后，会在内存里面冻结，变成Immutable MemTable，同时为了不阻塞写操作需要新生成一个Memtable继续提供服务。
4. 把内存里面不可变的Memtable给dump到硬盘上的SSTable层中，此步骤也称为Minor Compaction。这里需要注意在L0层的SSTable直接来源于memtable,是没有进行合并的，所以这里的key range在多个SSTable中可能会出现重叠，在层数大于0层之后的SSTable，不存在重叠key。
5. 当每层的磁盘上的SSTable的体积超过一定的大小或者个数，也会周期的进行合并。此步骤也称为Major Compaction，这个阶段会真正地清除掉被标记删除掉的数据以及多版本数据的合并，避免浪费空间，注意由于SSTable都是有序的，我们可以直接采用merge sort进行高效合并。

2.4 Compation策略

compaction任务运行期间会带来很大的资源开销，压缩/解压缩、数据拷贝和compare消耗大量cpu，读写数据引起disk I/O。

compaction策略约束了lsm-tree的形状，决定哪些文件需要合并、任务的大小和触发的条件，不同的策略对读写放大、空间放大和临时空间的大小有不同的影响，一般系统会支持不同的策略并配有多个调整参数，可根据不同的应用场景选取更合适的方式。

2.4.1 size-tiered compaction

• 保证每层SSTable的大小相近，同时限制每一层SSTable的数量。如上图，每层限制SSTable为N，当每层SSTable达到N后，则触发Compact操作合并这些SSTable，并将合并后的结果写入到下一层成为一个更大的sstable。

• 当层数达到一定数量时，最底层的单个SSTable的大小会变得非常大。并且size-tiered策略会导致空间放大比较严重。即使对于同一层的SSTable，每个key的记录是可能存在多份的，只有当该层的SSTable执行compact操作才会消除这些key的冗余记录。

2.4.2 leveled compaction

• sst的大小可控，默认每个sst的大小一致
• 在合并时，会保证除 Level 0（L0）之外的其他 Level 有序且无覆盖除 L0 外，每层文件的总大小呈指数增长，假如 L1 最多 10 个，则 L2 为 100 个，L3 为 1000 个…

2.5 读取

收到一个读请求的时候：

1. 直接先在内存里面查询，如果查询到就返回。
2. 如果没有查询到就会依次下沉，直到把所有的Level层查询一遍得到最终结果。

2.6 读取优化

如果SSTable的分层越多，那么最坏的情况下要把所有的分层扫描一遍，在 Bigtable 论文中提出了几种优化方式：

• 压缩
  SSTable可以启用压缩功能的，并且这种压缩不是将整个 SSTable 一起压缩，而是根据位置将数据分组，每个组分别压缩，这样的好处当读取数据的时候，我们不需要解压缩整个文件而是解压缩部分 Group 就可以读取。
• 缓存
  因为SSTable在写入磁盘后，除了Compaction之外，是不会变化的，所以我可以将Scan的Block进行缓存，从而提高检索的效率。
• 索引，Bloom filters
  正常情况下，一个读操作是需要读取所有的 SSTable 将结果合并后返回的，但是对于某些 key 而言，有些 SSTable 是根本不包含对应数据的，因此，我们可以对每一个 SSTable 添加 Bloom Filter，因为布隆过滤器在判断一个SSTable不存在某个key的时候，那么就一定不会存在，利用这个特性可以减少不必要的磁盘扫描。
• 合并
  这个在前面的写入流程中已经介绍过，通过定期合并，可以有效地清除无效数据，缩短读取路径，提高磁盘利用空间。但Compaction操作是非常消耗CPU和磁盘IO的，尤其是在业务高峰期，如果发生了Major Compaction，则会降低整个系统的吞吐量。一些NoSQL数据库，比如Hbase里面常常会禁用Major Compaction，并在凌晨业务低峰期进行合并。

3 与B+树的比较

• 写入：B+ Tree 数据的更新会直接在原数据所在处修改对应的值，但是LSM Tree 的数据更新是日志式的，写入速度快，当一条数据更新是直接append一条更新记录完成的。这样设计的目的就是为了顺序写，不断地将Immutable MemTable flush到持久化存储即可，而不用去修改之前的SSTable中的key，保证了顺序写。

• 查找：速度慢。一次查找操作可能需要先在内存里面找，找不到再到硬盘上去找。如果是多层的LSM树，那么在硬盘上可能需要查找多个数据文件。

• 空间：放大，LSM在硬盘上有很多层数据文件，当更新比较多的时候，这些文件中就会有大量key相同的数据记录。合并过程中也会出现有两份相同数据同时存在的情况。

• compaction存在读写放大，因为存在多次合并的过程中，所以就会对一个数据记录多次读写，而B+树只会读写一次。

• 后台的合并任务导致前台操作（put/get/del）相应时间不稳定。

参考

https://zhuanlan.zhihu.com/p/140325974

https://blog.csdn.net/itigoitie/article/details/126375996

https://cloud.tencent.com/developer/article/2113860?from=15425

https://mp.weixin.qq.com/s/sK2qqYCM-dZJTbbFn-23zg

https://mp.weixin.qq.com/s/Q4t0BcolJqngpBBR-tM7mg

https://cloud.tencent.com/developer/article/1441835

https://zhuanlan.zhihu.com/p/140325974