目录
目录
背景
简介
描述
整体架构
内存
Log文件
SST文件
Manifest文件
Current文件
Lock文件
多路归并
性能比对
实践
背景
- 对比内存存储： Redis 是一个纯内存的数据库，Redis 之所以高性能是因为它的纯内存访问特性，而这也成了它致命的弱点 —— 内存的成本太高。所以在绝大多数场合，它比较适合用来做缓存，长期不被访问的冷数据被淘汰掉，只有热的数据缓存在内存中，这样就不会浪费太多昂贵的内存空间。
- 数据一致性问题，解决比较复杂
LevelDB 出现了！
简介
描述
LevelDB是Google开源的KV存储引擎，无论从设计还是代码上都可以用精致优雅来形容，非常值得细细品味。LevelDB的数据是存储在磁盘上的，采用LSM-Tree的结构实现。LSM-Tree将磁盘的随机写转化为顺序写，从而大大提高了写速度。为了做到这一点LSM-Tree的思路是将索引树结构拆成一大一小两颗树，较小的一个常驻内存，较大的一个持久化到磁盘，他们共同维护一个有序的key空间。写入操作会首先操作内存中的树，随着内存中树的不断变大，会触发与磁盘中树的归并操作，而归并操作本身仅有顺序写。
整体架构
LevelDB有几个重要的角色，包括对应于上文提到的内存数据的Memtable，分层数据存储的SST文件，版本控制的Manifest、Current文件，以及写Memtable前的WAL
内存
LevelDB 的内存中维护了 2 个跳跃列表，一个是只读的 rtable，一个是可修改的 wtable
- Memtable：内存数据结构，跳表实现，新的数据会首先写入这里 可写
- Immutable Memtable：达到Memtable设置的容量上限后，Memtable会变为Immutable为之后向SST文件的归并做准备，顾名思义，Immutable Mumtable不再接受用户写入，同时会有新的Memtable生成只读
Log文件
写Memtable前会先写Log文件，Log通过append的方式顺序写入。Log的存在使得机器宕机导致的内存数据丢失得以恢复；
SST文件
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。
实现
1、每个SST文件大小上限为2MB，所以，LevelDB通常存储了大量的SST文件；
2、SST文件由若干个4K大小的blocks组成，block也是读/写操作的最小单元；
3、SST文件的最后一个block是一个index，指向每个data block的起始位置，以及每个block第一个entry的key值（block内的key有序存储）；
4、使用Bloom filter加速查找，只要扫描index，就可以快速找出所有可能包含指定entry的block。
5、同一个block内的key可以共享前缀（只存储一次），这样每个key只要存储自己唯一的后缀就行了。如果block中只有部分key需要共享前缀，在这部分key与其它key之间插入"reset"标识。
Manifest文件
Manifest文件中记录SST文件在不同Level的分布，单个SST文件的最大最小key，以及其他一些LevelDB需要的元信息。
- 存储信息： 所有文件的【 Key 取值范围】、【层级】和【其它元信息（文件名称，最小key和最大key各自是多少）】会存储在数据库目录里面的 MANIFEST 文件中。数据库打开时，读取一下这个文件就知道了所有文件的层级和 Key 取值范围。
- 版本号：MANIFEST 文件也有版本号，它的版本号体现在文件名上如 MANIFEST-000361，每一次重新打开数据库，都会生成一个新的 MANIFEST 文件，具有不同的版本号，然后还需要将老的 MANIFEST 文件删除。
Current文件
LevelDB启动时的首要任务就是找到当前的Manifest，而Manifest可能有多个。Current文件简单的记录了当前Manifest的文件名，从而让这个过程变得非常简单。
数据库目录中还有另外一个文件 CURRENT，它里面的内容很简单，就是当前 MANIFEST 的文件名。LevelDB 首先读取 CURRENT 文件才知道哪个 MANIFEST 文件是有效文件。在遇到断电时，会存在一个小概率中间状态，新旧 MANIFEST 文件共存于数据库目录中。
Lock文件
我们知道 LevelDB 的数据库目录不允许多进程同时访问，那它是如何防止其它进程意外对这个目录文件进行读写操作呢？仔细观察数据库目录，你还会发现一个名称为 LOCK 的文件，它就是控制多进程访问数据库的关键。当一个进程打开了数据库时，会在这个文件上加上互斥文件锁，进程结束时，锁就会自动释放。
多路归并
Compaction 是比较耗费资源的操作，为了不影响线上的读写操作，LevelDB 将 Compaction 工作交给一个单一的异步线程来完成。
- 问题：如果工作量巨大，这个单一的异步线程也会有点吃不消。当异步线程吃不消的时候，线上内存的读写操作也会收到影响。因为只有 rtable 沉到磁盘里了，wtable 才可以变身。只有 wtable 变身了，才会有新的 wtable 被创建来容纳后续更多的键值对。总之就是一环套一环，环环相扣。
- Minor Compaction：就是内容空间有限，所以需要将 rtable 中的数据 dump 到磁盘 0 层文件。那为什么需要从 0 层文件 Compact 下沉到 1 层文件呢？因为 0 层文件如果过多，就会影响查找效率。前面我们提到 0 层文件之间的 Key 范围会有重叠，所以单个 Key 可能存在于多个文件中，IO 读次数将会被文件的数量放大
- Major Compaction ：采用多路归并算法，将相关的 0 层文件和 1 层 sst 文件作为输入，进行多路归并，生成多个新的 1 层 sst 文件，再将老的 sst 文件干掉，同时还会生成新的 MANIFEST 文件。对于每个 0 层文件，它会根据 Key 的取值范围搜寻 1 层文件中和它的范围有重叠部分的 sst 文件。如果 1 层文件数量过多，每次多路归并涉及到的文件数量太多，归并算法就会非常耗费资源。所以 LevelDB 同样也需要控制 1 层文件的数量，当 1 层容量满时，就会继续下沉到 2 层、3 层、4 层等。
性能比对
开源项 | 对比 |
SSDB | |
Tair | |
RocksDB | https://github.com/facebook/rocksdb/wiki/Performance-Benchmarks#setup |
实践
1.社交场合，feeds流
2.直播排序
3.大存储，低延迟，非结构化
