它是一个高性能的Key-Value数据库。设计了完善的持久化机制，同时保证性能和安全性。能够良好的支持范围查询，因为K-V记录就是按照Key来排序的。

下图为写入的流程：

b06ff0742ae3821223fb29274aef0b3e653c2f67

可以看到主要的三个组成部分，内存结构memtable，类似事务日志角色的WAL文件，持久化的SST文件。

数据会放到内存结构memtable，一定条件下触发写到到SST文件。写入WAL文件是可选的，用来恢复未写入到磁盘的memtable。

下图展示了读取的层次：

be279f90e727321873d47cbbdc97706d46ee9f37

memtable和SST文件组成数据的全集。之上是缓存层，缓存为提升查询性能做了分片，底层都采用hash查询，不同缓存结构的区别在于热点数据的替换逻辑。访问数据库时，都是访问的打开时间点的view（我猜测一个key有不同时间戳的多条记录）。除了直接查询db，还提供了查询快照的机制。直接访问db时，会持有文件句柄，这样多个SST文件合并时，已经被合并但被访问的文件就不能被删除。而快照机制保证了访问过程中文件能被删除（我并未想明白如何做到的），不过打开期间被删除的key的记录还会在新合并的文件里存在。

memtable的结构有几种可选，本质都是排序的结构（为了支持范围查询）

9ec7aa51eae012d152f677869b6b2746486b8fab

其中之一是上图的跳跃表，不了解跳跃表机制的读者可以简单理解为有序支持近似二分查找的时间复杂度为log2(N)的结构

f4e36ab8af1e045174ff6875f4992e32a532ec79

另外一种是hash结合跳跃表，是按照key的前缀做hash，单独访问一个key时性能更好，范围查询性能会差些

WAL文件结构如下图，按照写入的顺序来存储变长的K-V，按照固定长度来分组存储（可能一个K-V跨多个分组）的目的是便于读取

770db51ff074cfede56f2dd0dd65d7380b5d632e

支持几种SST文件结构

08b51387b3ac49e9d4973cc416c94deb0aad52f1

上图为按照多块来存储的结构。每块的K-V都是有序的，而多块也是有序的。文件中包含元数据相关的信息，包括数据压缩字典、过滤器等。会按照数据块所属的K-V范围来创建索引，为提升查询性能会给索引分片。

56765ff825d19c49ee00045b25e890ac93aeedc5

另外一种结构是每个K-V来存储。它的索引比较特殊，由hash结构和二进制查找缓存两部分组成。依然按照key的前缀做hash，如果桶对应的K-V记录很少，则直接指向第一个key（有多个key属于该桶）的记录位置。如果属于桶的K-V记录多于16条，或者包含多于一个前缀的记录，则先指向二进制查找缓存（先二分查找），而后指向第一个key的记录位置。

随着K-V的写入，会生成很多的SST文件，这部分文件需要被合并到一起。从而降低打开文件数量，并且移除已经不存在的记录。通常可以配置两种方式，通用合并（下图左侧）与level合并（右侧）。

c60d54d533ec0205bc7d9094cd02f1a3acfe2f79

其中一个概念是level，可以简单理解成越老的数据在越高的level（也就是数据最初写入到最低的level，level0就是memtable）。

我将通用合并简单理解为一种简单粗暴的合并，可以尽量降低写磁盘的压力，会增大读取的压力，临时空间占用大。

一般多采用level合并的方式。每个level都有max大小，超出后会触发本level与下一level的文件合并到一起。不同level的合并是可以并发执行的。

对rocksdb做个总结。所有记录在业务上是有序的，对key的查询其实会执行类似二分查找。持久化是通过写入有序文件来实现的。高性能的写入是通过先写入内存结构来保证的（写满的内存结构刷到持久化文件）。提供了level机制对数据做分层，优先查询最新写入的level来优化查询性能。