LSMT 存储引擎浅析笔记（二）| 青训营笔记
这是我参与「第四届青训营 -大数据场」笔记创作活动的第20天
三、LSMT 模型理论分析
1. Cloud-Native LSMT Storage Engine - HBase
- RocksDB 是单机存储引擎，那么现在都说云原生，HBase 比 RocksDB 就更「云」一些，SST 直接存储于 HDFS 上。
- 二者在理论存储模型上都是 LSMT。
2. LSMT 模型算法复杂度分析
T：sizeratio,每层LSMT比上一层大多少，LO大小为1，则L1大小为T,L2为T^2，以此类推
L：level num，LSMT层数B:每个最小的IO单位能装载多少条记录
M：每个BloomFilter有多少bits
N：每个BloomFilter生成时用了多少条Key
S：区间查询的记录数量
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。
O(Write_ Level) =LT1/B=T*L/B
● Point Lookup
对于每条Key, 最多有L个重叠的区间。
每个区间都有BloomFilter,失效率为e^(-M/N)， 只有当BloomFilter失效时才会访问下一层。
O(PointLookup_Level) = L* e^(-M/N)
注意，这里不乘1/B系数的原因是写入可以批量提交拉低成本，但是读取的时候必须对齐到最小读取单元尺寸。
2.2 Tier
● Write 每条记录抵达最底层前同样要经过L次Compact,每次Compact Ln中T个相同尺寸的SST 放到Ln+1。
设SST大小为1，那么T个SSTCompact的合并开销是T，换言之将T单位的Ln的SST推到Ln+1要耗费T的IO，单次Compact的写放大T/T=1。
每条记录的写入成本为1/B次最小单位IO。
O(Write_Tier) = L*1 *1/B=L/B
● Point Lookup
对于每条Key,有L层。
每层最多有T个重叠区间的SST,对于整个SST来说有T * L个可能命中的SST，乘上BloomFilter的失效率，e^(-M/N)， 可得结果。
O(PointLookup_ _Tier) = LT e^(-M/ N) = T * L* e^(-M/N)
注意，这里不乘1/B系数的原因是写入可以批量提交拉低成本，但是读取的时候必须对齐到最小读取单元尺寸。
3. 小结
Tier策略降低了写放大，增加了读放大和空间放大，Level 策略增加了写放大，降低了读和空间放大。
四、LSMT存储引擎调优案例与展望
1. TerarkDB
● TerarkDB aka LavaKV是字节跳动内部基于RocksDB深度定制优化的自研LSMT存储引擎，其中完全自研的KV分离功能，上线后取得了巨大的收益。
● KV分离受启发于论文WiscKey: Separating Keys from Values in SSD-conscious Storage,概括起来就是Value较长的记录的Value单独存储。
2. TerarkDB & Abase & ByteGraph
图存储场景描述:
Key size : 20B ~ 30B
Value size : 数十KB级别
写多读少
收益结论: 延迟大幅度降低，长尾消失，扛住了比RocksDB 高50%的负载。
3. TerarkDB & Flink
在字节内部Flink流处理状态存储场景实测
收益结论:
- 平均CPU开销在3个作业.上降低了26%~39%
- 峰值CPU开销在广告作业上有明显的收益，降低了67%
- 平均容量开销在3个作业.上降低了17% ~ 31.2%
- 直播业务某集群容量不收缩，TerarkDB的schedule TTL GC彻底解决了该问题
4. 新硬件
● 随着硬件的发展，软件设计也会随着发生改变。近年来，出现了许多新的存储技术，例如SMR HDD，Zoned SSD / OpenChannel SSD，PMem等。如何在这些新硬件上设计/改进存储引擎是一大研究热点。
e.g. MatrixKV: Reducing Write Stalls and Write Amplification in LSM-tree Based KV Stores with Matrix Container in NVM
这篇论文中的设计将LO整个搬进了PMem,降低了写放大。
5.新模型
● 经典LSMT模型是比较简单的，有时候不能应对所有工况，可以提出新的模型来解决问题。
e.g. WiscKey: Separating Keys from Values in SSD-conscious Storage 通过额外增加一个Value Store来存储大Value的记录来降低总体写放大。
e.g. REMIX: Efficient Range Query for LSM-trees 通过额外增加一种SST的类型来加速范围查询的速度
6. 新参数/新工况
● 已有的模型，在新的或者现有工况下，参数设置的不合理，可以通过更精确的参数设置来提升整体性能。
e.g The Log-Structured Merge-Bush & the Wacky Continuum，在最后一层使用Level Compaction,之上使用Tier Compaction，通过在除了最后一层以外的 SST加大BloomFilter的bits数来规避Tier Compaction带来的点查劣化。
五、课程总结
● 单机数据库的ACID特性依赖于存储引擎
● LSMT存储引擎的顺序写特性更适合现代计算机体系结构
● LSMT和B+Tree可以用同一模型描述并互相转化
● Level Compaction策略，降低了读放大和空间放大，增加了写放大
● Tier Compaction策略，降低了写放大，增大了读放大和空间放大
● 分布式KV存储，如HBase,背后的理论模型与单机存储引擎RocksDB一样都是 LSMT
