HBase/TiDB都在用的数据结构：LSM Tree，不得了解一下？

LSM Tree（Log-structured merge-tree）普遍应用在HBase，TiDB等诸多数据库和存储引擎上，咱们先来看一下它的一些应用：

这么牛X的名单，你不想了解下LSM Tree吗？装X以前，咱们先来了解一些基本概念。设计数据存储系统可能须要考虑的一些问题有：ACID，RUM（Read,Write,Memory）。

ACID

ACID 相信小伙伴都被面试官问过，我想简单讨论的一点是：如何 持久化数据 才能保证数据写入的 事务性 和 读写性能？

事务性可简单理解为：1.数据必须持久化。2.一次数据的写入返回给用户 写入成功就必定成功，失败就必定失败。

读写性能可简单理解为：一次读 或 一次写 须要的IO次数，由于访问速率：CPU>>内存>>SSD/磁盘。

对于单机存储，最简单的方式固然是：写一条就持久化一条，读一条就遍历一遍全部数据，而后返回。固然没人这么干，在内存中咱们都还知道用个HashMap呢。

拿Mysql InnoDB举例子：

读性能体如今数据的索引在磁盘上主要用B+树来保证。

写性能体如今运用 WAL机制 来避免每次写都去更新B+树上的全量索引和数据内容，而是经过redo log记录下来每次写的增量内容，顺序将redo log写入磁盘。同时在内存中记录下来本次写入应该在B+树上更新的脏页数据，而后在必定条件下触发脏页的刷盘。

redo log是数据增删改的实时增量数据，顺序写入保证了写性能和事务性。磁盘上的B+树是数据增删改的全量数据，经过定时脏页刷盘保证这份数据的完整性。

这里的问题是：虽然经过WAL机制，提升了写入性能，可是仍然避免不了脏页数据定时刷盘的随机IO写入。

由于数据在磁盘上是以block为单位存储的（好比4K，16K）,假如你更新了Order表一条数据，又更新了Product表一条数据，脏页刷盘时，这两条数据在磁盘上的block位置可能差了十万八千里，就变成了随机IO的写入。

RUM

RUM（Read,Write,Memory）相似分布式领域的CAP定理。若是想获得三者中的二者性能，必须以牺牲第三者的性能为代价。衡量这三者的性能指标有：读放大、写放大、空间放大。

读放大：是指每次查询读取磁盘的次数。若是每次查询须要查询5个page (或block)，则读放大是5.

写放大：是指数据写入存储设备的量和数据写入数据库的量之比。若是用户写入数据库的大小是10MB，而实际写入磁盘的大小是30MB，则写放大是3.另外SSD的写入次数是有限的，写放大会减小SSD的寿命。

空间放大：是指数据在存储设备的总量和数据在数据库的总量之比。若是用户往数据库上存10MB，而数据库实际在磁盘上用了100MB去存，则空间放大就是10.

一般，数据结构能够最多优化这其中的二者，如B+树有更少的读放大，LSM Tree有更少的写放大。

下面咱们将介绍LSM Tree的结构，它是如何解决 B+树中“全量数据的随机写入” 问题的；在RUM问题上，又该如何优化LSM Tree。

为何要有LSM Tree

LSM Tree（Log-structured merge-tree）起源于1996年的一篇论文：The log-structured merge-tree (LSM-tree)。

当时的背景是：为一张数据增加很快的历史数据表设计一种存储结构，使得它可以解决：在内存不足，磁盘随机IO太慢下的严重写入性能问题。

若是咱们前后修改两条数据，那么在脏数据块落盘时，不是一条条随机写入，而是以一个脏块批量落盘时，就能解决 B+树中“全量数据的随机写入” 问题了。

因此大佬设计了这么一种结构：

Ck tree是一个有序的树状结构，数据的写入流转从C0 tree 内存开始，不断被合并到磁盘上的更大容量的Ck tree上。这种方式写入是顺序写的，增删改操做都是append。这样一次I/O能够进行多条数据的写入，从而充分利用每一次写I/O。

merge所作的事情有：当上一棵树容量不足时，1.将上棵树中要删除的数据删除掉，进行GC回收。2.合并数据的最新版本，使得Ck tree不会过分膨胀。

这种初始结构存在的问题有：随着数据量的增大，merge费劲，没有好的索引结构，读放大严重。现代的LSM Tree结构以下：

MemTable：是LSM Tree在内存中还未刷盘的写入数据，这里面的数据能够修改。是一个有序的树状结构，如RocksDB中的跳表。

SSTable（Sorted String Table）：是一个键是有序的，存储字符串形式键值对的磁盘文件。当SSTable太大时，能够将其划分为多个block；咱们须要经过 下图中的Index 记录下来每一个block的起始位置，那么就能够构建每一个SSTable的稀疏索引。这样在读SSTable前，经过Index结构就知道要读取的数据块磁盘位置了。

LSM Tree读数据

读数据 包括点读和范围读，咱们分开讨论。假设LSM Tree中的key为[0-99]，

点读：是指准确地取出一条数据，如get(23),则其示意图为：

按照图中标示的顺序，会先读取内存，在从Level0依次往高层读取，直到找到key=23的数据。

范围读：是指读取一个范围内的数据，如读取[23-40]内的全部数据（ select * from t where key >= 23 && key <=40),

则须要作的是在每一层SSTable找到这个范围内的第一个block,而后遍历block块的数据，直到不符合范围条件。

“ReadOnly MemTable：如RocksDB，在MemTable 和 Level0数据之间还有一个内存的ReadOnly MemTable结构。它是LSM Tree在内存中还未刷盘的写入数据，这里面的数据不能够修改。是当MemTable到达必定量须要刷到SSTable时，由MemTable完整copy下来的。这样可避免从MemTable直接刷到SSTable时的并发竞争问题。

LSM Tree写数据

在LSM Tree写入数据时，咱们把ReadOnly MemTable画上，示意图以下：

当有写请求时，数据会先写入MemTable,同时写入 WAL Log；当MemTable空间不足时，触发ReadOnly MemTable copy,同时写入WAL Log；而后刷新到磁盘Level0的SSTable中。当低层SSTable空间不足时，不断经过Compaction和高层SSTable进行Merge。

LSM Tree合并策略

LSM Tree有两种合并策略，Tiering 和 Leveling。咱们看图说话：

Tiering的特色是：每层可能有N个重叠的sorted runs，当上一层的sorted runs 要merge下来时，不会和当前层重叠的sorted runs立刻合并，而是等到当前层空间不足时，才会合并，而后再merge到下一层。

Tiering这种策略能够减少写放大，可是以读放大和空间放大为代价。

Leveling的特色是：每层只有一个sorted run，当上一层的sorted run 要merge下来时，会立刻和当前层的sorted run合并。Leveling这种策略能够减少读放大和空间放大，但以写放大为代价。

LSM Tree的优化

上文中的大佬们提到了很多优化方式，我这里从读，合并方面简要总结下LSM Tree的优化。

点读的优化

尽管咱们能够经过SSTable的内存block稀疏索引结构简单判断key是否可能存在于block中，但如上get(23)，若是level1读不到，仍须要往下读level2,level3。（由于数据是按照增删改的时间顺序一层层往下落盘的，若是一个key不存在低level中，可能存在于更早的高level中）。这样的点读IO次数较多，读放大严重。

布隆过滤器

对于精确查询，hash的时间复杂度为 O(1)，那么能够经过布隆过滤器来优化。咱们只须要查询时先过一遍及隆过滤器，就能排除掉必定不存在的key了，避免没必要要的IO查询。

“布隆过滤器：是经过hash算法来判断一个key是否存在于某个集合中，布隆过滤器一般是一个bit数组，用针对一个key屡次hash算法肯定的多个bit值来表示key是否存在。多个bit值全为1，则表示key可能存在，不然不存在。好处是多个bit值一般比直接存储一个存在的key占用空间小，省内存。

分层布隆过滤器

上述布隆过滤器是假设每层数据都使用相同的布隆过滤器来进行过滤，而数据随着层数的增长一般是指数级增加的，若是使低层的数据使用更精确的布隆过滤器（所需bit数更多，可是精确度更高）,高层的数据使用稍微不那么精确的布隆过滤器，则总体点查的效率将提升。

上文中Monkey作了上述优化，即便随着数据量和层数的增大，点查仍能保持在一个稳定的时间内。

范围读的优化

Hash的不足就是没法支持范围查询索引，优化方式有：

并行查询

由于读数据不存在竞争问题，能够并行读每层的数据，缩短总体查询时间，可是这种方式实际并无缩短IO次数。

前缀布隆过滤器

前缀布隆过滤器是以key的前缀来Hash构建布隆过滤器，而不是key自己的值。这样能够起到过滤 like Monica* 这样的查询条件做用。RocksDB有作此优化。

合并的优化

上面提到了两种合并策略Tiering 和 Leveling。Tiering能够减少写放大，Leveling能够减少读放大和空间放大。上文中提到了数据库所采用的合并策略走势以下：

随着数据量的增大，整条曲线会上移。优化的重点在于：如何结合两种合并策略，使曲线总体下移。

Lazy Leveling

上文中Dostoevsky采用了一种Lazy Leveling的策略：它是对低层数据采用Tiering合并策略，对高层数据采用Leveling合并策略。从而权衡了读写性能。

RUM的取舍

RUM的取舍和权衡相似于分布式领域的CAP，在特定的场景采用适合的优化手段才能使总体性能最优。上文中的大佬还提到了Fluid Merge策略。233酱表示虽过了眼瘾，但还是个CRUD渣渣。关于RUM的优化，233我最后放一张图，但愿对你我有所启发。