从 RocksDB 看 LSM-Tree 算法设计

• Meta Block，存储 Filter 相关信息，用于加快 sst 中查询数据的效率；Filter 通过 Bloom Filter 来过滤判断指定的 data block 中是否存在要查询的数据。

• Meta Index Block，对 Meta Block 的索引，它只有一条记录，key 是 meta index 的名字（也就是 Filter 的名字），value 为指向 meta index 的位置；

• Index Block，index block 用来存储所有 data block 的相关索引信息。indexblock 包含若干条记录，每一条记录代表一个 data block 的索引信息；

• Footer，指向各个分区的位置和大小。Footer 是定长的，读取 SSTable 文件的时候，就是从文件末尾，固定读取字节数，进而得到了 Footer 信息。 Footer 中的信息，指明了 MetaIndexBlock 和 IndexBlock 的位置，进而找到 MetaBlock 和 DataBlock。

可以看到，SSTable 文件除了存储实际数据外，还有索引结构 和 Filter，来加快 SST 的查询效率，设计非常精妙。

2. 其他的一些名词概念

Column Family （CF）

RocksDB 3.0 以后添加了一个 Column Family 的 feature，每个 kv 存储之时都必须指定其所在的 CF。RocksDB 为了兼容以往版本，默认创建一个 “default” 的 CF。存储 kv 时如果不指定 CF，RocksDB 会把其存入 “default” CF 中。

RocksDB 允许用户创建多个 Column Family ，这些 Column Family 各自拥有独立的 memtable 以及 SST 文件，但是共享同一个 WAL 文件，这样的好处是可以根据应用特点为不同的 Column Family 选择不同的配置，但是又没有增加对 WAL 的写次数。

如果类比到关系型数据库中，列族可以看做是表的概念。

3. 读 & 写

3.1 读操作

1. 在 active memtable 中查找；

2. 如果 active memtable 没有，则在 immutable memtable 中查找；

3. 如果 immutable memtable 没有，则在 L0 SSTable 中查找（RocksDB 采用遍历的方法查找 L0 SSTable，为了提高查找效率会控制 L0 文件的个数）；

4. 如果找不到，则在剩余的 SSTable 中查找（对于 L1 层以及 L1 层以上层级的文件，每个 SSTable 没有交叠，可以使用二分查找快速找到 key 所在的 Level 以及 SSTable）

每个 SSTable 在查找之前通过 bloom filter 快速判断数据是否存在于当前文件，减少不必要的 IO。

RocksDB 为 SST 中访问频繁的 data blocks 设置了一个读缓存结构 Block cache，并提供了两种开箱即用的实现 LRUCache 和 ClockCache 。

3.2 写操作

1. 写操作会先写 WAL 文件，保证数据不丢失；