这是我参与「第四届青训营 」笔记创作活动的的第5天，学习的内容为《LSMT存储引擎浅析》
了解LSMT
LSMT的历史介绍
- LSMT是 Log-Structured Merge-Tree的缩写，由Patrick O 'Neil etc.在1996年的论文，The Log-Structured Merge-Tree (LSM-Tree)，提出。
- 相较而言，B-Tree出现就早得多了，在1970年由 Bayer, R.; McCreight,E.提出。
- 早期的数据库系统一般都采用 B-Tree家族作为索引，例如MySQL。2000年后诞生的数据库大多采用LSMT索引，例如Google BigTable，HBase,Canssandra等。
LSMT 介绍
- Log-Structured Merge-Tree(LSMT)，最早由Patrick在1996年提出，2000年后的数据库大多采用LSMT索引
- 相较而言，B-Tree在1970年由Bayer提出，早期的数据库常用其作为索引
LSMT是通过Append-only Write + 择机Compact来围护结构的索引树
LMST存储引擎的优势与实现
LSMT与B+Tree的异同
- B+Tree
- 数据插入是原地更新的
- 在发生不平衡或者节点容量到达阈值后，必须立刻进行分裂来平衡
- 在 B+Tree 中，数据插入是原地更新的，装有 (10, 20, 30, 40) 的节点在插入和分裂后，原节点覆写成 (10, 15)。此外，B+Tree 在发生不平衡或者节点容量到达阈值后，必须立即进行分裂来平衡。
- 反观 LSMT，数据的插入是追加的（Append-only），当树不平衡或者垃圾过多时，有专门 Compact 线程进行 Compact，可以称之为延迟（Lazy）的。
- 尽管 LSMT 和 B+Tree 可以用一个模型描述，工程实践上我们还是用 LSMT 来表示一个 Append-only 和 Lazy Compact 的索引树，B+Tree 来表示一个 Inplace-Update 和 Instant Compact 的索引树。Append-only 和 Lazy Compact 这两个特性更符合现代计算机设备的特性。
为什么要采用LSMT模型
- 在计算机存储乃至整个工程界都在利用Indirection处理资源的不对称性
- 存储引擎面对的资源不对称性在不同时期是不同的
- HDD时代：顺序与随机操作性能不对称
- SSD时代：顺序写与随机写性能不对称
- 这二者的共性是顺序写是一个对设备很友好的操作，LSMT符合这一点，而B+ Tree依赖原地更新，导致随机写。
LSMT存储引擎的实现
- 以RocksDB为例
- Write
- 写入流程主要有两个优化，批量WAL写入与并发Memtable更新
- 在真正执行修改之前会先将变更写入WAL，WAL写成功则写入成功
- Snapshot & SuperVision
- 数据由三部分组成，Memtable/Immemtable/SST，持有这三部分数据并提供快照功能的组件叫做SuperVision
- Memtable和SST的释放依赖于引用计数，对于读取来说，只要拿着SuperVision，从Memtable一级一级向下，就能查到记录。拿着SuperVision不释放，等于是拿到了快照。
- Thread Local Supervision Cache
- Get&BloomFilter
- 读取在大框架上和B+Tree类似，就是层层向下。
- 相对于B+Tree，LSMT点查需要访问的数据块更多。为了加速点查，一般LSMT引擎都会在SST中嵌入BloomFilter
- Compact
- Compact在LSMT中是将Key区间有重叠或无效数据较多的SST进行合并，以此来加速读取或者回收空间。Compact策略可以分为两大类，Level和Tier
LSMT模型理论分析
- *Tier*策略降低了写放大，增加了读放大和空间放大
- *Level*策略增加了写放大，降低了读和空间放大
- 调优案例与展望
- KV分离
- WiscKey:Separating Keys from values in SSD-conscious Storage
- 数据库存两类数据，索引以及用户输入的数据，数据只要可以读就行，不需要跟着compact
- 大value场景，收益很高
- WiscKey:Separating Keys from values in SSD-conscious Storage
- KV分离
