LSM树存储模型

----《大规模分布式存储系统：原理解析与架构实战》读书笔记

之前研究了Bitcask存储模型，今天来看看LSM存储模型，两者尽管同属于基于键值的日志型存储模型。可是Bitcask使用哈希表建立索引，而LSM使用跳跃表建立索引。这一区别导致了两个存储系统的构造出现明显的分化。为此，我还先去捣腾了一番跳跃表的实现.今天算是进入了正题。

LSM的结构

LSM的基本思想是将改动的数据保存在内存，达到一定数量后在将改动的数据批量写入磁盘，在写入的过程中与之前已经存在的数据做合并。同B树存储模型一样，LSM存储模型也支持增、删、读、改以及顺序扫描操作。LSM模型利用批量写入攻克了随机写入的问题，尽管牺牲了部分读的性能，可是大大提高了写的性能。

MemTable

LSM本身由MemTable,Immutable MemTable,SSTable等多个部分组成，当中MemTable在内存，用于记录近期改动的数据，一般用跳跃表来组织。当MemTable达到一定大小后，将其冻结起来变成Immutable
MemTable，然后开辟一个新的MemTable用来记录新的记录。而Immutable MemTable则等待转存到磁盘。

Immutable MemTable

所谓Immutable MemTable，即是仅仅能读不能写的内存表。内存部分已经有了MemTable，为什么还要使用Immutable MemTable？个人觉得其原因是为了不堵塞写操作。由于转存的过程中必定要保证内存表的记录不变，否则假设新插入的记录夹在两条已经转存到磁盘的记录中间，处理上会非常麻烦，转存期间势必要锁住全表，这样一来就会堵塞写操作。所以不如将原有的MemTable变成仅仅读Immutable MemTable,在开辟一个新的MemTable用于写入，即简单，又不影响写操作。

SSTable

SSTable是本意是指有序的键值对集合( a set of sorted key-value pairs )。是一个简单实用的集合，正如它的名字一样，它存储的就是一系列的键值对。当文件较大的时候，还能够为其建立一个键-值的位置的索引，指明每一个键在SSTable文件里的偏移距离。这样能够加速在SSTable中的查询。(当然这一点是可选的，同一时候让我想去了Bitcask模型中hint文件，通过记录 键-值的位置 ,来加速索引构建)

使用MemTable和SSTable这两个组件，能够构建一个最简单的LSM存储模型。这个模型与Bitcask模型相比，不存在启动时间长的问题，可是这个模型的读性能很的差，由于一但在MemTable找不到对应的键，则须要在依据SSTable文件生成的时间，从近期到较早在SSTable中寻找，假设都不存在的话，则会遍历全然部的SSTable文件。


假设SSTable文件个数非常多或者没有建立SSTable的文件内索引的话，读性能则会大大下降。

除了在对SSTable内部建立索引外，还能够使用Bloom Fileter,提高Key不在SSTable的判定速度。相同，定期合并旧的SSTable文件，在降低存储的空间的同一时候，也能提高读取的速度。以下这幅图非常好的描写叙述了在LSM的大部分结构和操作

LevelDB怎样优化读性能

Leveldb是一个轻量级的，高速的以存储为目的的key-value存储引擎。其使用的正是LSM存储模型。我们能够看看LevelDB是怎样来优化读性能的。在LevelDB中，存在一种元信息文件MANIFEST，用于记录leveldb的元信息，比方DB使用的Comparator名，以及各SSTable文件的管理信息：如Level层数、文件名称、最小key和最大key等等。相比而言，元信息文件而SSTable文件的数目成正比，一般来说不会太多，是能够加载内存的，因此Level能够通过查询元信息，从而推断哪些文件里存在我们须要的Key相应的记录，降低SSTable文件读取次数。此外，LevelDB的合并操作Compaction是分层次进行的，每一层都有多个SSTable文件，每次合并后除了Level0和内存的MemTable，Immutable
MemTable中会有反复的键值外，LevelN(N>=1)的各层内部的SSTable文件不会再有反复的键值。同一时候，假设在Level N 层读到了数据，那么就不须要再往后读Level N+1,Level N+2等层的数据了.由于Level N层的数据总是比Level N+1等层的数据更“新奇”。

实现一个简单的LSM存储模型

依据上面讲述的原理，实现了一个简单的LSM模型(https://github.com/Winnerhust/Code-of-Book/blob/master/Large-Scale-Distributed-Storage-System/lsm_tree.py)。这个模型也内存表为一个跳跃表，SSTable就是简单的有序键值对集合，没有SSTable内部使用索引,没有使用Bloom过滤器。事实上能就是将我之前的Bitcask模型进行了简单的改造：

• 将原来的哈希表换成了跳跃表；
• 原来读取记录全然依赖哈希表，如今假设在跳跃表中没有的话，就去读取文件SSTable文件里的数据，依据文件编号从大到小进行，编号越大，表示数据越新；
• 去掉了载入数据的功能(LSM不须要)；

简单起见，没有完毕对范围扫描的支持，只是内存表和SSTable都是有序的，因此这个也不是非常难。

參考：

具体解释SSTable结构和LSMTree索引

---

欢迎光临我的站点----蝴蝶忽然的博客园----人既无名的专栏。


假设阅读本文过程中有不论什么问题，请联系作者，转载请注明出处！