LSMT 存储引擎浅析 | 青训营笔记

小叶要努力
156 阅读7分钟

image.png

这是我参与「第四届青训营 」笔记创作活动的的第15天

一、本课堂重点内容

  • LSMT与存储引擎介绍
  • LMST存储引擎的优势与实现
  • LSMT模型理论分析
  • LSMT存储引擎调优案例与展望

课程目录

image.png

二、详细知识点介绍：

01.LSMT与存储引擎介绍

1.1 LMST是什么？

  • 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等。

image.png

Append-only Write + 择机Compact【归并排序】（level+tier）来维护结构索引树

. Compact在LSMT中是将Key区间有重叠或无效数据较多的SST进行合并，以此来加速读取或者回收空间。Compact策略可以分为两大类，Level和Tier。下图是Level策略，

image.png . Level策略直接来自于LevelDB，也是 RocksDB的默认策略。每一个层不允许有SST的 Key区间重合。

1.2 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)= L* T* 1/B = T*L/B

. Point Lookup
对于每条Key，最多有L个重叠的区间。 每个区间都有BloomFilter，失效率为e^(-M/N)，只有当BloomFilter 失效时才会访问下一层。
O(PointLookup_Level) = L* eh(-M/N)
注意，这里不乘1/B系数的原因是写入可以批量提交拉低成本，但是读取的时候必须对齐到最小读取单元尺寸。

1.3 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。
    o(Write_Tier) = L* 1 *1/B = L/B

  • Point Lookup 对于每条Key，有L层。
    每层最多有Ⅰ个重叠区间的SST，对于整个SST来说有TL个可能命中的SST，乘上BloomFilter的失效率，e^(-M/N)，可得结果。
    O(PointLookup_Tier) = L    T* e^(-M/N)= T* L* e^(-M/N)
    注意，这里不乘1/B系数的原因是写入可以批量提交拉低成本，但是读取的时候必须对齐到最小读取单元尺寸。

1.4 存储引擎是什么？

分为：计算层+存储层
计算层主要负责SQL解析/查询优化/计划执行
数据库中的ACID强依赖于存储引擎
ACID是什么？Atomicity/Consistency(Correctness)/Isolation/Durability

image.png

除ACID外，还有负责：
·屏蔽IO细节提供更好的抽象
·提供统计信息与Predicate Push Down能力

存储引擎不掌控IO细节，让操作系统接管，例如使用mmap，会有如下问题︰
·落盘时机不确定造成的事务不安全
·Io Stall
·错误处理繁琐
·无法完全发挥硬件性能

02.LMST存储引擎的优势与实现

2.1LSMT与B+树的异同

1.B+tree中，数据插入是原地更新的
2.B+Tree在发生不平衡或者节点容量达到阈值后，必须立即进行分裂来平衡

image.png LSMT与B+Tree 可以用统一模型描述
3.从高昙次的数据结构角度来看，二者没有本质的不同，可以互相转化
4.工程实践上还是用LSMT来表示一个 Append-only和Lazy Compact 的索引树，B+Tree来表示一个lnplace-Update和Instant Compact的索引树。
5.Append-only和Lazy Compact这两个特性更符合现代计算机设备的特性。

image.png

2.2为什么要采用LSMT模型？

HDD时代：机械硬盘需要磁盘旋转和机械臂移动来进行读写，顺序写吞吐是随机读的25倍。 SSD时代：顺序写与随机写性能不对称，会给GC压力，顺序写吞吐是随机写的6倍

2.3 LSMT存储引擎的实现

RocksDB是一款十分流行的开源LSMT存储引擎，最早来自Facebook (Meta)，应用于MyRocks，TiDB等数据库。 ·在字节内部也有Abase,ByteKV，ByteNDB，Bytable等用户。

RocksDB写入流程主要有两个优化，批量WAL写入（继承自LevelDB )与并发MemTable更新 RocksDB在真正执行修改之前会先将变更写入WAL ，WAL写成功则写入成功。

多个写入者会选出一个Leader ，由这个Leader来一次性写入WAL，避免小IO。 不要求WAL强制落盘( Sync )时，批量提交亦有好处，Leader可以同时唤醒其余Writer，降低了系统线程调度开销。

没有批量提交的话，只能链式唤醒，但链式唤醒会加大前台延迟。

·写完WAL还要写MemTable。 RocksDB在继承LevelDB的基础上又添加了并发MemTable写入的优化。 . WAL一次性写入完成后，唤醒所有Writer并行写入 MemTable 由最后一个完成 MemTable 写入的 Writer执行收尾工作

2.4 Snapshot & SuperVision

· RocksDB的数据由3部分组成，MemTable/ lmmemTable / SST。持有这三部分数据并且提供快照功能的组件叫做SuperVersion。
. MemTable和SST的释放依赖于引用计数。对于读取来说，只要拿着SuperVersion，从MemTable一级一级向下，就能查到记录。拿着SuperVersion不释放，等于是拿到了快照。

image.png

如果所有读者都给SuperVersion的计数加1，读完后再减1，那么这个原子引用计数器就会成为热点。CPU 在多核之间同步缓存是有开销的，核越多开销越大。 为了让读操作更好的scale，RocksDB 做了一个优化是Thread Local SuperVersionCache 没有Thread Local缓存时，读取操作要频繁Acquire和 Release SuperVersion .CPU 缓存不友好

image.png

·有Thread Local 缓存，读取只需要检查一下SuperVersion并标记 ThreadLocal缓存正在使用即可
.CPU 缓存友好

image.png

03.LSMT模型理论分析

3.1 LSMT模型算法复杂度分析

Online Quiz

. Short Range Scan复杂度是如何推导的?
. Space Amplification复杂度是如何推导的?

04.LSMT存储引擎调优案例与展望

4.1 LSMT 存储引擎调优案例-TerarkDB

.TerarkDB aka LavaKV是字节跳动内部基于RocksDB深度定制优化的自研LSMT存储引擎，其中完全自研的KV分离功能，上线后取得了巨大的收益。
·KV分离受启发于论文 WiscKey: Separating Keys from Values in SSD-consciousStorage，概括起来就是Value较长的记录的Value单独存储。

image.png

4.2 TerarkDB & Abase & ByteGraph

image.png

4.3 TerarkDB & Flink

在字节内部Flink流处理状态存储场景实测
收益结论:
1．平均CPU开销在3个作业上降低了26%~39%
2. 峰值CPU开销在广告作业上有明显的收益，降低了67%
3．平均容量开销在3个作业上降低了17%~31.2%
4. 直播业务某集群容量不收缩，TerarkDB的schedule TTL GC彻底解决了该问题

三、个人总结：

1.对LSMT 存储引擎浅析的知识有了大概的了解，但没有建立一个完整的系统体系
2.有两个问题没有解决
. Short Range Scan复杂度是如何推导的?
. Space Amplification复杂度是如何推导的?

四、参考文献

. The Log-Structured Merge-Tree (LSM-Tree)

. github.com/facebook/ro… b/wiki/RocksDB-Overview
·MyRocks: LSM-Tree Database Storage Engine Serving Facebook's Socia Graph

. www.geeksforgeeks.org/insertion-i…

.Design Continuums and the Path Toward Self-Designing Key-Value Stores thatKnow and Learn
. Are You Sure You Want to Use MMAP in Your Database Management system?.\ zhuanlan.zhihu.com/p/470109297

.LSM-based Storage Techniques: A Survey
. WiscKey: Separating Keys from Values in sSD-conscious Storage

avatar
文章
阅读
粉丝