这是我参与「第四届青训营 」笔记创作活动的第13天
LSMT历史&是什么
-
Log-Structured Merge-Tree的缩写，由Patrick O ‘Neil etc.在1996年的论文，The Log-Structured Merge-Tree (LSM-Tree)，提出。
-
早期的数据库系统一般都采用B-Tree家族作为索引，例如 MySQL。2000年后诞生的数据库大多采用LSMT 索引，例如Google BigTable，HBase，Canssandra等
-
是通过Append-only Write ＋择机 Compact来维护结构的索引树。
为什么要用LSMT
-
在B+Tree 中，数据插入是原地更新的
-
B+Tree在发生不平衡或者节点容量到达阈值后，必须立即进行分裂来平衡
-
LSMT B+Tree 可以用统一模型描述
-
从高层次的数据结构角度来看，二者没有本质的不同，可以互相转化
-
工程实践上还是用LSMT来表示一个Append-only和Lazy Compact的索引树，B+Tree 来表示一个Inplace-Update和Instant Compact的索引树。
-
Append-only 和 Lazy Compact这两个特性更符合现代计算机设备的特性
-
相对于B+树的优势
- 顺序写对SSD设备更友好，Append-only 和 Lazy Compact更符合现代计算机的特性
- SST 不可修改的特性使得其能使用更加紧凑的数据排列和加上压缩
- 后台延迟 Compact 能更好利用 CPU 多核处理能力，降低前台请求延迟
-
相对于HashTable的优势
- LSTM更通用，既能点查询，又能是顺序查询，而Hashtable只能点查询
LSMT存储引擎
以RocksDB为例
- RocksDB是一款十分流行的开源LSMT存储引擎，最早来自Facebook (Meta)，应用于MyRocks，TiDB等数据库。
- 在字节内部也有Abase,ByteKV，ByteNDB，Bytable 等用户。
Write
多个写入者会选出一个 Leader，由这个 Leader 来一次性写入。这样的好处在于可以批量聚合请求，避免频繁提交小 IO
Snapshop & SuperVision
-
RocksDB的数据由3部分组成，MemTable/ lmmemTable / SST。持有这三部分数据并且提供快照功能的组件叫做SuperVersion。
-
MemTable 和SST的释放依赖于引用计数。对于读取来说，只要拿着SuperVersion，从MemTable 一级一级向下，就能查到记录。拿着SuperVersion不释放，等于是拿到了快照。
-
如果所有读者都给SuperVersion的计数加1，读完后再减1，那么这个原子引用计数器就会成为热点。CPU在多核之间同步缓存是有开销的，核越多开销越大。
-
为了让读操作更好的scale，RocksDB做了一个优化是Thread Local SuperVersionCache
Get & BloomFilter
RocksDB读取是层层向下的，相对于B+Tree, LSMT点查需要访问的数据块更多
-
优化
- 在SST中嵌入BloomFilter加速点查
- 两层索引
- 前缀压缩
Compact
LSMT中将Key区间有重叠或无效数据较多的SST进行合并，以此来加速读取或回收空间
-
Level
-
每一层不允许有SST的Key重合
-
缺点：
- 存在写放大的问题
- 实际上，将L0作为例外，允许有SST Key区间重叠来降低写放大
-
-
Tier
-
允许LSMT每层有多个区间重合的SST
-
缺点
- 每层的区间内重合的SST越多，读取时查询的SST越多
- 用读放大的增加换取了写放大的减小
-
Cloud-Native LSMT Storage Engine --- HBase
- RocksDB是单机存储引擎，那么现在都说云原生，HBase 比 RocksDB就更「云」一些SST直接存储于HDFS上。
- 二者在理论存储模型上都是LSMT。
LSMT模型理论分析
- Level 策略增加了写放大，降低了读和空间放大
- Tier 策略降低了写放大，增加了读放大和空间放大
