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

用户5236754501065
156 阅读10分钟

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

Lecture14. LSMT 存储引擎浅析

01. LSMT与存储引擎介绍

数据库 = 存储 + 计算

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

1.2 LSMT是什么?

一言以蔽之，通过 Append-only Write ＋择机Compact来维护结构的索引树。

  • 先写入WAL：原子性
  • Memtable：内存中索引
  • Immutable：Memtable堆积 ---> 写盘
  • SST，Compaction：（归并排序）

1.3存储引擎是什么?

以单机数据库MySQL为例，大致可以分为∶

  • 计算层
  • 存储层（存储引擎层)

计算层主要负责SQL解析/查询优化/计划执行。

数据库著名的ACID特性，在MySQL中全部强依赖于存储引擎。

ACID是什么/存储引擎哪些组件保障了这些特性?

  • Atomicity原子性

    • Write-Ahead Log(WAL)/ Redo Log

  • Consistency(Correctness)一致性

    • 依赖于数据库整体

  • Isolation隔离性

    • Snapshot / 2PL(Phase Lock) + MVCC

  • Durability持久性

    • Flusher遵循Sync语意

存储引擎还要负责：服务上层

  • 屏蔽IO细节提供更好的抽象

    • 不同系统的不同IO API、规范

  • 提供统计信息与Predicate Push Down（过滤）能力

存储引擎不掌控IO细节，让操作系统接管，例如使用mmap，会有如下问题:

  • 落盘时机不确定造成的事务不安全
  • IO Stall
  • 错误处理繁琐
  • 无法完全发挥硬件性能

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

2.1 LSMTB+Tree的异同

在B+Tree中，数据插入是原地更新的

B+Tree在发生不平衡或者节点容量到达阈值后，必须立即进行分裂来平衡

  • LSMT B+Tree 可以用统一模型描述

  • 从高层次的数据结构角度来看，二者没有本质的不同，可以互相转化

  • 工程实践上还是用LSMT来表示一个Append-only和Lazy Compact的索引树，B+Tree 来表示一个lInplace-Update和Instant Compact的索引树。

  • Append-only和Lazy Compact这两个特性更符合现代计算机设备的特性。

2.2 为什么要采用 LSMT模型?

All problems in computer science can be solved by another level of indirection—— Butler Lampson

  • 在计算机存储乃至整个工程界都在利用Indirection处理资源的不对称性
  • 存储引擎面对的资源不对称性在不同时期是不同的

HDD机械硬盘时代

  • 顺序与随机操作性能不对称

由于机械硬盘需要磁盘旋转和机械臂移动来进行读写，顺序写吞吐是随机读的25倍。

SSD时代

  • 顺序写与随机写性能不对称

由于SSD随机写会给主控带来GC压力，顺序写吞吐是随机写的6 倍。

结论

  • HDD时代，顺序操作远快于随机操作
  • SSD 时代，顺序写操作远快于随机写操作

这二者的共性是顺序写是一个对设备很友好的操作，LSMT符合这一点，而B+Tree依赖原地更新，导致随机写。

2.3 LSMT存储引擎的实现，以 RocksDB为例

  • RocksDB是一款十分流行的开源LSMT存储引擎，最早来自Facebook (Meta)，应用于MyRocks，TiDB等数据库。
  • 在字节内部也有Abase,ByteKV，ByteNDB，Bytable 等用户。
  • 因此接下来将会以RocksDB为例子介绍LSMT存储引擎的经典实现。

2.3.1 LSMT 存储引擎的实现-Write

  • RocksDB写入流程主要有两个优化，批量WAL写入(继承自LevelDB)与并发MemTable更新

  • RocksDB在真正执行修改之前会先将变更写入WAL, WAL写成功则写入成功。

  • 多个写入者会选出一个 Leader，由这个Leader来一次性写入WAL，避免小lO。

  • 不要求WAL强制落盘(Sync)时，批量提交亦有好处，Leader可以同时唤醒其余Writer，降低了系统线程调度开销。

  • 没有批量提交的话，只能链式唤醒。

  • 链式唤醒加大前台延迟。

  • 写完WAL还要写MemTable。

  • RocksDB在继承LevelDB的基础上又添加了并发MemTable写入的优化。

  • WAL一次性写入完成后，唤醒所有Writer并行写入MemTable

  • 由最后一个完成 MemTable 写入的 Writer执行收尾工作

2.3.2 LSMT存储引擎的实现-Snapshot & SuperVision（隔离性Isolation）

  • RocksDB的数据由3部分组成，MemTable/ lmmemTable / SST。持有这三部分数据并且提供快照功能的组件叫做SuperVersion。

  • MemTable和SST的释放依赖于引用计数。对于读取来说，只要拿着SuperVersion，从MemTable一级一级向下，就能查到记录。拿着SuperVersion不释放，等于是拿到了快照。

  • 如果所有读者都给SuperVersion 的计数加1，读完后再减1，那么这个原子引用计数器就会成为热点。CPU在多核之间同步缓存是有开销的，核越多开销越大。

  • 为了让读操作更好的 scale，RocksDB做了一个优化是Thread Local SuperVersionCache

  • 没有Thread Local缓存时，读取操作要频繁Acquire和ReleaseSuperVersion（+1 / -1）

  • CPU 缓存不友好

  • 有Thread Local缓存，读取只需要检查一下SuperVersion并标记 (所有的)ThreadLocal 缓存正在使用即可

  • CPU 缓存友好

2.3.3 LSMT存储引擎的实现- Get & BloomFilter

  • RocksDB的读取在大框架上和B+ Tree类似，就是层层向下。
  • 相对于B+Tree,LSMT点查需要访问的数据块更多为了加速点查，一般LSMT引擎都会在SST中嵌入BloomFilter。

假设在之内

[1，10]表示这个索引块存储数据的区间在1-10之间。查询2，就是顺着标绿色的块往下。

2.3.4 LSMT存储引擎的实现Compact - Level

Level策略

  • Compact在 LSMT中是将Key 区间有重叠或无效数据较多的SST进行合并，以此来加速读取或者回收空间。Compact策略可以分为两大类，Level和Tier。
  • Level策略直接来自于LevelDB，也是RocksDB的默认策略。每一个层不允许有SST的 Key区间重合。

2.3.5 LSMT存储引擎的实现 Compact - Tier

合并

Tier策略允许LSMT每层有多个区间重合的 SST

03. LSMT模型理论分析

3.1 Cloud-Native LSMT Storage Engine - HBase

  • RocksDB是单机存储引擎，那么现在都说云原生，HBase 比 RocksDB就更「云」一些,SST直接存储于HDFS 上。
  • 二者在理论存储模型上都是LSMT。

3.2 LSMT 模型算法复杂度分析

  • T: size ratio，每层LSMT比上一层大多少，LO大小为1，则 L1大小为T，L2为TA2，以此类推
  • L: level num,LSMT层数B:每个最小的IO单位能装载多少条记录
  • M:每个 BloomFilter有多少bits
  • N:每个 BloomFilter生成时用了多少条Key
  • S:区间查询的记录数量

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系数的原因是写入可以批量提交拉低成本，但是读取的时候必须对齐到最小读取单元尺寸。

3.3 LSMT模型算法复杂度分析–Tier

Write

  • 每条记录抵达最底层前同样要经过L次Compact，每次Compact Ln中T个相同尺寸的SST放到Ln+1。
  • 设SST大小为1，那么T个SST Compact的合并开销是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来说有T *L个可能命中的SST，乘上BloomFilter的失效率，e(-M/N)，可得结果。

O(PointLookup_Tier) = L* T* e^(-M/N)= TL e^(-M/N)

注意，这里不乘1/B系数的原因是写入可以批量提交拉低成本，但是读取的时候必须对齐到最小读取单元尺寸。

3.4 LSMT 模型算法复杂度分析

做一个平衡。

总结，Tier策略降低了写放大，增加了读放大和空间放大，Level策略增加了写放大，降低了读和空间放大。

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

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

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

4.2 LSMT存储引擎调优案例TerarkDB & Abase & ByteGraph图存储场景

收益结论:

延迟大幅度降低，长尾消失，扛住了比 RocksDB高50%的负载。

4.3 LSMT 存储引擎调优案例- TerarkDB & Flink

在字节内部Flink流处理状态存储场景实测

收益结论:

  1. 平均CPU 开销在3个作业上降低了26%~39%
  2. 峰值CPU开销在广告作业上有明显的收益，降低了67%
  3. 平均容量开销在3个作业上降低了17%~31.2%
  4. 直播业务某集群容量不收缩，TerarkDB的schedule TTL GC彻底解决了该问题

4.4 存储引擎最新发展趋势–新硬件

  • 随着硬件的发展，软件设计也会随着发生改变。近年来，出现了许多新的存储技术，例如SMR HDD，Zoned SSD /OpenChannel SSD，PMem等。如何在这些新硬件上设计/改进存储引擎是一大研究热点。

e.g. MatrixKV: Reducing Write Stalls and Write Amplification in LSM-tree Based KV Stores withMatrix Container in NVM

这篇论文中的设计将LO整个搬进了PMem，降低了写放大。

4.5 存储引擎最新发展趋势–新模型

  • 经典LSMT模型是比较简单的，有时候不能应对所有工况，可以提出新的模型来解决问题。

e.g. WiscKey: Separating Keys trom Values in SSD-conscious Storage

  • 通过额外增加一个 Value Store来存储大Value的记录来降低总体写放大。

e.g. REMIX: Efficient Range Query for LSM-trees

  • 通过额外增加一种 SST的类型来加速范围查询的速度

4.6存储引擎最新发展趋势-新参数/新工况

  • 已有的模型，在新的或者现有工况下，参数设置的不合理，可以通过更精确的参数设置来提升整体性能。

e.g.The Log-Structured Merge-Bush & the Wacky Continuum

avatar
文章
阅读
粉丝