源码下载
git clone https://github.com/google/leveldb.git
项目结构
- db/, 数据库逻辑
- doc/, MD文档
- helpers/, LevelDB内存版, 通过namespace覆盖
- port/, 平台相关代码
- table/, LSM有关的
主要模块
Log 文件
客户端的写请求会先 append 到 Log 文件，成功后再写入到 Memtable。如果宕机可以通过 Log 文件来恢复 Memtable。
Memtable 和 Immutable Memtable
内存数据结构，基于跳表。客户端的读写请求都会由 Memtable 处理。 当 Memtable 占用的内存达到一定阈值，重新生成新的 Memtable 处理客户端请求。原来的 Memtable 转成 Immutable Memtable，等待归并到 SST 文件中。
SST 文件
落地到磁盘的存储文件。SST 分为不同的 level，具体参考文档。
Manifest 文件
Manifest 记录不同 level 的 SST 文件，包括每个 SST 文件的 key range、大小等 metadata。
Current 文件
Current 记录了最新的 Manifest 文件。
LSMtree的核心思想以及问题
在LSM Tree中，所有数据直接写入memtable并打log, 当memtable足够大的时候, 变为immemtable, 开始往硬盘挪, 成为SSTable. 你可以用任何有道理的数据结构来表示memtable, immemtable和SSTable. LevelDB选择用跳跃表（skiplist）实现memtable和immemtable, 用有序行组来实现SSTable。
LSM Tree存在如下问题：
1.适用于插入多而查找少的情况。在查找key时，最坏情况要从memtable读到immemtable, 再到所有SSTable.
2.SSTable要怎么有效merge(major compaction)? 如果只有一个SSTable, 我要把新immemtable归并进去, 就要重写这个SSTable. 数据有多大, 这个SSTable也会有多大.那么把SSTable分成若干份, 每份2MB呢？在最坏的情况下，比如，当前这个immemtable恰好永远有一个key与任意SSTable中至少一个key重复，就回到刚刚重写全库的情况了.
针对以上问题，LevelDB打了两个增强补丁：
1. 添加BloomFilter, 这样可以提升全库扫描的速度, 直接跳过没有这个key的SSTable.
2. leveled compaction, 把SSTable分成不同的等级. 除等级0以外, 其余各等级的SSTable不会有重复的key.
LevelDB的做法让每次compaction波及到的范围是可预期的. 官方文档的说法是"The compaction picks a file from level L and all overlapping files from the next level L+1". 只按等级延迟合并，没有任何随机读写操作, 机制上简单, 而且不需要bookkeeping，可以优雅得释放被删除记录的空间。
需要注意的是：因为下级可能还有相同key的数据，因此，compaction不一定会清空所有deletion maker.
参考文献：
1.https://zhuanlan.zhihu.com/p/27329248
2.http://masutangu.com/2017/06/leveldb_1/