这是我参与「第四届青训营 」笔记创作活动的的第14天。
本节课程主要分为 4 个方面：
1.LSMT与存储引擎介绍
2.LSMT存储引擎的优势与实现
3.LSMT模型理论分析
4.LSMT存储引擎调优案例与展望
一.LSMT与存储引擎介绍
1.1.LSNT的历史
■ LSMT是Log-Structured Merge-Tree的缩写，由Patrick O'Neil etc。在1996年的论文，The Log-Structured Merge-Tree(LSM-Tree)，提出。
1.2.LSMT是什么？
一言以蔽之，通过Append-only Write+择机Compact来维护结构的索引树。
1.3.存储引擎是什么？
■ 以单机数据库MySQL为例，大致可分为：
◎ 计算层 ◎ 存储层(存储引擎层)
■ 计算层主要负责SQL解析/查询优化/计划执行
■ 数据库著名的ACID特性，在MySQL中全部强依赖于存储引擎
1).ACID是什么/存储引擎哪些组件保障了这些特性？
■ Atomicity：Write-Ahead Log(WAL)/Redo Log
■ Consistency(Correctness)：依赖于数据库整体
■ Isolation：Snapshot/2PL(Phase Lock)
■ Durability：Flusher遵循Sync语意
2).除了保障ACID以外，存储引擎还要负责：
■ 屏蔽IO细节提供更好的抽象
■ 提供统计信息与Predicate Push Down能力
存储引擎不掌控IO细节，让操作系统接管，例如使用ｍｍａｐ，会有如下问题：
■ 落盘时机不确定造成的事务不安全
■ IO Stall
■ 错误处理繁琐
■ 无法完全发挥硬件性能
二.LSMT存储引擎的优势与实现
2.1.LSMT与B+Tree的异同
写入流程：
▲ 在B+ Tree中，数据插入时原地更新的
▲ B+ Tree在发送不平衡或者节点容量
高层次：
▲ LSMT与B+ Tree可以用统一模型描述
▲ 从高层次的数据结构角度来看，二者没有本质的不同
▲ 工程实践上还是用LSMT来表示一个Append-only和Lazy Compact的索引树，B+Tree来表示一个Inplace-Update和Instant Compact的索引树。
▲ Append-only和Lazy Compact这两个特性更符合现代计算机设备的特性
2.2.为什么要采用LSMT模型？
▲ 在计算机存储乃至整个工程界都在利用Indirection处理资源的不对称性
▲ 存储引擎面对的资源
HDD时代：
◎ 顺序与随机操作性能不对称
SSD时代：
◎ 顺序写与随机写性能不对称
2.3.LSMT存储引擎的实现
▲ RocksDB是一款十分流行的开源LSMT存储引擎，最早来自Facebook(Meta)，应用于MyRocks，TiDB，在字节内部也有Abase，ByteKV，ByteNDB，Bytable等用户。因此接下来将会以RocksDB为例子介绍LSMT存储引擎的经典实现。
2.3.1.Write
▲ RocksDB写入流程主要又两个优化，批量WAL写入(继承自LevelDB)于并发MemTable更新
▲ RocksDB在真正执行修改之前会先将变更写入WAL，WAL写成功则写入成功
▲ WAL一次性写入完成后，唤醒所有Writer并行写入MemTable
▲ 由最后一个完成MemTable写入的Writer执行收尾工作
2.3.2.Snapshot & SuperVision
▲ Rocks DB的数据由3 部分组成，MenTable/ImmemTable/SST。持有这三部分数据并且提供快照功能的组件叫做SuperVersion。
▲ MenTable/SST的释放依赖于引用计数。对于读取来说，只要拿着SuperVersion，从MemTable一级一级向下，就能查到记录。拿着SuperVersion不释放，等于是拿到了快照。
2.3.3.Get & BloomFilter
▲ Rocks DB的读取在大框架上和B+ Tree类似，就是层层向下
▲ 相对于B＋Tree，LSMT点查询访问的数据块更多。为了加速点查，一般LSMT引擎都会在SST中嵌入BloomFilter。
2.3.4.Compact-Level
Compact在LSMT中是将Key区间有重叠或无效数据较多的SST进行合并，以此来加速读取或者回收空间。Compact策略可以分为两大类。
▲ Level 策略直接来自于 LevelDB，也是 RocksDB 的默认策略。每一个层不允许有 SST 的 Key 区间重合。
2.3.5.Compact- Tier
▲Tier策略允许LSMT每层有多个区间重合的SST。
三.LSMT模型理论分析
3.1.Cloud-Native LSMT Storage Engine-HBase
◉ RocksDB时单机存储引擎，那么现在都说云原生，HBase比RocksDB就更云一些，SST直接存储于HDFS上。
◉ 二者在理论存储模型上都是LSMT。
3.2.LSMT模型算法复杂度分析
◉ T：size ratio，每层LSMT比上一层大多少，L0 大小为1，则L1大小为T，L2 为T^2，以此类推
◉ L: level num，LSMT 层数
◉ M: 每个 BloomFilter 有多少 bits
◉ N: 每个 BloomFilter 生成时用了多少条 Key
◉ S：区间查询的记录数量
3.2.1.Level
◉ Write：
每条记录抵达最底层需要经过L次Compact，每次Compact Ln的一个小 SST和Ln+1的一个大SST。设小SST的大小为1，那么大SST的大小则为T，合并开销是 1+T，换言之将1单位的Ln的SST推到Ln+1要耗费1+T的IO，单次Compact写放大为T。每条记录的写入成本为1/B次最小单位IO。三者相乘即得结果。
◉ Point Lookup：
对于每条Key，最多有L个重叠的区间，每个区间都有BloomFilter，失效率为e−MNe^{-\frac{M}{N}}e−NM，只有当BloomFilter失效时才会访问下一层。因此二者相乘可得读取的开销。注意，这里不乘1/B的原因是写入可以批量提交，但是读取的时候必须对齐到最小读取单元尺寸。
3.3.LSMT模型算法复杂度分析-Tier
◉ Write：
每条记录抵达最底层前同样要经过L次Compact，每次Compact Ln中T个相同尺寸的SST放到Ln+1。设SST大小为1，那么T个SST Compact的合并开销是T，换言之将T单位的Ln的SST推到Ln+1要耗费T的IO，单次Compact的写放大为T/T=1。每条记录的写入成本为1/B次最小单位IO。三者相乘即得结果。
◉ Point Lookup：
对于每条 Key，有L层，每层最多有T个重叠区间的SST，对于整个SST来说有T*L个可能命中的SST，乘上BloomFilter的失效率即可得结果。
总结，Tier策略降低了写放大，增加了读放大和空间放大，Level策略增加了写放大，降低了读和空间放大。
四.LSMT存储引擎调优案例与展望
4.1.LSMT存储引擎调优案例-TerarkDB
▶ TerarkDB aka LavaKV是字节跳动内部基于RocksDB深度定制优化的自研LSMT存储引擎，其中完全自研的KV分离功能，上线后取得了巨大的收益。
▶ KV 分离受启发于论文 WiscKey: Separating Keys from Values in SSD-conscious Storage，概括起来就是Value较长的记录的Value单独存储。
4.2.Abase 图存储场景使用 TerarkDB
▶ 图存储场景描述
◎ Key size ：20B ~ 30B
◎ Value size：数十 KB 级别
◎ 写多读少
▶ 收益结论：
◎ 延迟大幅度降低，长尾消失，扛住了比 RocksDB 高 50% 的负载。
4.3.TerarkDB & Flink
▶ 平均CPU开销在 3个作业上降低了 26%～39%
▶ 峰值CPU开销在广告作业上有明显的收益，降低了67%
◎ live_feed_head 作业上峰值CPU开销降低43%
◎ multi_trigger 受限于分配的CPU资源，没有观察到峰值CPU收益(平均CPU开销降低39%)
▶ 平均容量开销在3个作业上降低了17%～31.2%
▶ 直播业务某集群容量不收缩，TerarkDB的schedule TTL GC彻底解决了该问题
4.4.存储引擎最新发展趋势--新硬件
▶ 随着硬件的发展，软件设计也会随着发生改变。近年来，出现了许多新的存储技术，例如SMR HDD，Zoned SSD/OpenChannel SSD，PMem等。
4.5.新模型
▶ 经典LSMT模型是比较简单的，有时候不能应对索引工况，可以提出新的模型来解决问题
4.6.新参数/新工况
▶ 已有的模型，在新的或者现有工况下。参数设置的不合理，可以通过更精确的参数设置来提升整体性能。
