LevelDB在以太坊中的研究笔记

LevelDB基本介绍

LevelDB is a fast key-value storage library written at Google that provides an ordered mapping from string keys to string values.

Authors: Sanjay Ghemawat ([email protected]) and Jeff Dean ([email protected])

Features

• Keys and values are arbitrary byte arrays.
• Data is stored sorted by key.
• Callers can provide a custom comparison function to override the sort order.
• The basic operations are Put(key,value), Get(key), Delete(key).
• Multiple changes can be made in one atomic batch.
• Users can create a transient snapshot to get a consistent view of data.
• Forward and backward iteration is supported over the data.
• Data is automatically compressed using the Snappy compression library.
• External activity (file system operations etc.) is relayed through a virtual interface so users can customize the operating system interactions.

Documentation

LevelDB library documentation is online and bundled with the source code.

Limitations

• This is not a SQL database. It does not have a relational data model, it does not support SQL queries, and it has no support for indexes.
• Only a single process (possibly multi-threaded) can access a particular database at a time.
• There is no client-server support builtin to the library. An application that needs such support will have to wrap their own server around the library.

源代码地址：https://github.com/google/leveldb

LevelDB是Google开源的持久化KV单机数据库，具有很高的随机写，顺序读/写性能，但是随机读的性能很一般，也就是说，LevelDB很适合应用在查询较少，而写很多的场景。

LevelDB是一个功能上类Redis的key/value存储引擎。Redis是一个基于纯内存的存储系统，而LevelDB是基于内存 + SSD的架构，内存存储最新的修改和热数据（可理解为缓存），SSD作为全量数据的持久化存储，所以LevelDB具备比redis更高的存储量，且具备良好的写入性能，读性能就略差了，主要原因是由于冷数据需要进行磁盘IO。Facebook在levelDB的基础上优化了 RocksDB。

LevelDB一般采用 proxy + 多机主备 的形式搭建集群，常见的兼容Redis协议，可通过Redis客户端访问。

LevelDB应用了LSM (Log Structured Merge) 策略，lsm_tree对索引变更进行延迟及批量处理，并通过一种类似于归并排序的方式高效地将更新迁移到磁盘，降低索引插入开销。

LevelDB的架构

LevelDB 有点类似于建筑，分为地基和地面两部分，也就是磁盘和内存，而地基又好比地壳结构分了很多层级，不同层级的数据还会定期从上往下移动 —— 沉积作用。如果磁盘底层的冷数据被修改了，它又会再次进入内存，一段时间后又会被持久化刷回到磁盘文件的浅层，然后再慢慢往下移动到底层。

内存结构

LevelDB 的内存中维护了 2 个跳跃列表，一个是只读的 rtable，一个是可修改的 wtable。简单理解，跳跃列表就是一个 Key 有序的 Set 集合，key通过分层连接的方式，提高链表的查找速率。跳跃列表的查找和更新操作时间复杂度都是 Log(n)。

跳跃列表是由多个层次的链表构成，其中最底层的链表存储了所有的 Key，它们是有序的。普通链表并不支持快速二分查找，但是跳跃链表的特殊结构可以让最底层的链表以近似二分查找算法的效率定位到指定节点。简单理解就是跳跃列表同时具备了有序数组的快速定位能力和链表的高效增删能力。但是它会付出一定的代价，在实现上有一定的复杂度。

rtable和wtable的数据结构

其中 sequence 为全局自增序列号，LevelDB 遇到一个修改操作，全局序列号自动加一。LevelDB 中的 Key 存储了多个版本的 Value。LevelDB 使用序列号来标记键值对的版本，序列号越大，对应的键值对越新。

type 为数据类型，标记是 Put 还是 Delete 操作，只有两个取值，0 表示 Delete，1 表示 Put。

如果是删除操作，后面的 value_size 字段值 为 0，value 字段值是空的。我们要将 Delete 操作等价看成 Put 操作。同时为了节省存储空间，internal_key_size 和 value_size 都要采用 varint 整数编码。

如果跳跃列表中同一个 key 存在多个修改操作，也就是说有多个「复合 Key」，那么这几个「复合 Key」 肯定会挨在一起按照 sequence 值排序的。当 Get 操作到来时，它会在跳跃列表中定位到 key 所在的位置，选择这几个同样的 key 中 seq 最大的「复合 Key」，提取出其中的 value 值返回。

待 Put 和 Delete 操作日志写到日志文件后，其键值对合并成「复合 Key」插入到 wtable 的指定位置中。

待 wtable 的大小达到一个阈值，LevelDB 将它凝固成只读的 rtable，同时生成一个新的 wtable 继续接受写操作。rtable 将会被异步线程刷到磁盘中。Get 操作会优先查询 wtable，如果找不到就去 rtable 中去找，rtable 如果还找不到，再去磁盘文件里去找。

因为 wtable 要支持多线程读写，所以访问它是需要加锁控制。而 rtable 是只读的，它就不需要，但是它的存在时间很短，rtable 一旦生成，很快就会被异步线程序列化到磁盘上，然后就会被置空。但是异步线程序列化也需要耗费一定的时间，如果 wtable 增长过快，很快就被写满了，这时候 rtable 还没有完成序列化，而wtable 急需变身怎么办？这时写线程就会阻塞等待异步线程序列化完成，这是 LevelDB 的卡顿点之一，也是未来 RocksDB 的优化点。

图中还有个日志文件，记录了近期的写操作日志。如果 LevelDB 遇到突发停机事故，没有持久化的 wtable 和 rtable 数据就会丢失。这时就必须通过重放日志文件中的指令数据来恢复丢失的数据。注意到日志文件也是有两份的，它和内存的跳跃列表正好对应起来。当 wtable 要变身时，日志文件也会跟着变身。待 rtable 落盘成功之后，只读日志文件就可以被删除了。

磁盘结构

LevelDB 在磁盘上存储了很多 sst 文件，sst 表示 Sorted String Table，文件里所有的 Key 都会有序的。每个文件都会对应一个层级，每个层级都会有多个文件。底层的文件内容来源于上一层，最终它们都会来源于 0 层文件，而 0 层的文件又来源于内存里的 rtable 序列化。一个 rtable 会被序列化为一个完整的 0 层文件。这就是我们前面所说的「下沉作用」。

从内存的 rtable 序列化成 0 层 sst 文件称之为「Minor Compaction」，从 n 层 sst 文件下沉到 n+1 层 sst 文件称之为「Major Compaction」。之所以这样区分是因为 Minor 速度很快耗费资源少，将 rtable 完整地序列化为一个 sst 文件就完事了。而 Major 会涉及到多个文件之间的合并操作，耗费资源多，速度慢。层级越深的文件总容量越大，在 LevelDB 源码里有一个层级容量公式，容量和层级呈指数级关系。而通常每个 sst 文件的大小都差不多，区别就成了每一层的文件数量不一样。

capacity=level>0&&10^(level+1)M

每个文件里面的 Key 都是有序的，也就是说它内部的 Key 取值会有一个确定的范围。0 层文件和其它层文件有一个明显的区别那就是其它层内部的文件之间范围不会重叠，它们按照 Key 的顺序严格做了切分。而 0 层文件的内容是直接从内存 dump 下来的，所以 0 层的多个文件的 Key 取值范围会有重叠。

当内存出现读 miss 要去磁盘搜寻时，会首先从 0 层搜寻，如果搜不到再去更深层次搜寻。

如果是其它层级，搜寻速度会很快，因为可以根据 Key 的范围快速确定它可能会位于哪个文件中。但是对于 0 层，因为文件 Key 范围会重叠，所以它可能存在于多个文件中，那就需要对这多个文件进行搜寻。正因如此，LevelDB 限制了 0 层文件的数量，如果数量超出了默认的 4 个，就需要「下沉」到 1 层，这个「下沉」操作就是 Major Compaction。

所有文件的 Key 取值范围、层级和其它元信息会存储在数据库目录里面的 MANIFEST 文件中。数据库打开时，读取一下这个文件就知道了所有文件的层级和 Key 取值范围。

MANIFEST 文件也有版本号，它的版本号体现在文件名上如 MANIFEST-000361。每一次重新打开数据库，都会生成一个新的 MANIFEST 文件，具有不同的版本号，然后还需要将老的 MANIFEST 文件删除。

数据库目录中还有另外一个文件 CURRENT，它里面的内容很简单，就是当前 MANIFEST 的文件名。LevelDB 首先读取 CURRENT 文件才知道哪个 MANIFEST 文件是有效文件。在遇到断电时，会存在一个小概率中间状态，新旧 MANIFEST 文件共存于数据库目录中。

我们知道 LevelDB 的数据库目录不允许多进程同时访问，那它是如何防止其它进程意外对这个目录文件进行读写操作呢？仔细观察数