leveldb源码笔记

关于KV数据库leveldb的介绍，网上已经太多了，这里只是自己再学习源码过程中，整理的笔记，磁盘存储和内存存储的结构用了伪代码表示出来了，首先是内存中存储结构，然后是log文件存储结构和磁盘数据sst文件存储结构。

MemTable存储格式

MemTable底层是用skiplist(跳跃表)进行存储, 数据全部存储在内存中, 具体结构设计如下:

class MemTable
{
    enum ValueType
    {
        kTypeDeletion = 0x0,  /*正常标记*/
        kTypeValue = 0x1      /*已删除标记*/
    };

    /*跳跃表中存储的实体信息*/
    struct Entity
    {
        /*key长度*/
        key_size;
        /*key数据*/
        key_bytes;
        /*标识是否删除ValueType中一个*/
        type;
        /*value长度*/
        value_size;
        /*value数据*/
        value_bytes;
    };

    SkipList<Entity*, KeyComparator> table_;
}

Log文件

　　Log文件存储在磁盘上, 用于数据恢复使用, 写入数据前先写入log文件, 与mysql方式类似, 写入的实体格式Entity如下, 写入块以32KB为单位, 如果一个块空间有足够空间容纳新写入的Entity, 则直接写入, 并将记录类型type置为KFullType; 如果无法完整写入, 则写入Entity开始部分的块类型为kFirstType, 写入中间部分块类型为kMiddleType, 写入最后部分块类型为kLastType. 一个块内可能写入多个Entity, 一个Entity可能写入多个块中,块方式写入之后,在读取日志进行恢复数据时, 变得很方便, 直接按块大小读取, 加快访问速度.

                                Entity实体结构示意图

|                 HEADER               |                            key, value对                                |
|--------------|------------|----------|------------|-----------|-------------|------------|-------------|......|
|   checksum   |   length   |   type   |  val_type  |  key_size |  key_bytes  |  val_size  |  val_bytes  |......|

struct Entity
{
    /*主要标识一个Entity是否在当前块中的*/
    enum RecordType
    {
        kZeroType = 0,
        kFullType = 1,
        kFirstType = 2,
        kMiddleType = 3,
        kLastType = 4
    };

    struct Header
    {
        /*32位crc校验码, 对写入数据校验*/
        int4 checksum;
        /*日志块长度*/
        int2 length;
        /*RecordType中一种*/
        int1 type;
    };

    /*键值对可以批量写入, 因此一次可能有N个键值对*/
    struct KeyValuePair
    {
        /*标识值被删除,还是正常状态*/
        val_type;
        /*键长度*/
        key_size;
        /*键内容*/
        key_bytes;
        /*key对应的值长度*/
        val_size;
        /*key对应的值内容*/
        val_bytes;
    }[N];
};

SST文件存储格式

　　SST文件存储最终落入磁盘的数据, 数据是只读的, 数据默认是压缩存储. 下面是伪代码的存储数据结构, 文件依次存储数据块, 数据块索引, 过滤器，文件尾。

　　1.key共享存储：block中存储的一条条记录, 每条记录中一个KV对, 假如存储key为user1, user2, user3, 则首先存入user1, shared_size值为0，non_shared_size为0，后面依次存入value长度和值，存入user2时，由于user1和user2是共享user部分，因此user2中shared_size为4，non_shared_size为1，后面依次存入value长度，non_shared值也就是1，value值，后面存入user3时，同理，shared_size为4，non_shared_size为1，后面依次存入value长度，non_shared值也就是3，value值，由于SST中存储的key值都是有序的，key如果相似的，这种存储可以节省很多空间。

　　2.重启点：block最后存储了一个重启点数组，默认间隔16条记录插入一个重启点，插入重启点位置的key是一个完整的key，没有共享字段，插入重启点是为了加快block中查找key的速度，block中进行查找时，我们首先在重启点数组中利用二分查找，找到距离查找小于key最近的重启点，然后顺着重启点依次查找，直到找到key，或者没有找到。

　　3.过滤器BlockMeta：为了减少操作磁盘次数，leveldb加入了过滤器，创建db的时候可以指定过滤器，leveldb实现了布隆过滤器供使用。BlcokMeta中每条记录对应一个BlockData的过滤器，查找时，如果过滤器中没有找到则直接返回，否则在BlockData中进行查找。

　　4.块索引BlcokIndex：存储块对应的索引，其中key为前一个块中最后一个key和后一个块中第一个key之间的一个值，比如block1中最后key为user1， block2中最小key为user5，索引的key值为user2；如果block2中最小的key为user2，则索引的key只能为user1。

/*M个数据块, 存储具体数据*/
struct Block
{
    /*每个数据块中存储N条记录*/
    struct Record
    {
        /*Key中共享字段长度*/
        size_t shared_size;
        /*Key中独有字段长度*/
        size_t non_shared_size;
        /*Key对应的Value字段长度*/
        size_t value_size;
        /*Key中独有字段内容*/
        byte non_shared_bytes[non_shared_size];
        /*Key对应Value字段内容*/
        byte value_bytes[value_size];
    }[N];

    /*重启点数组方式保存, 长度和重启点都已固定大小存储，值表示重启点距离block开始位置的偏移量*/
    uint32 restarts[restart_num];
    /*重启点个数*/
    uint32 restart_num;
    /*标识是否进行压缩*/
    byte type;
    /*数据校验码, 如果压缩数据, 则校验码是数据压缩之后的校验码, 校验数据的完整性*/
    uint32 crc;
};

class table
{
    /*存放数据的数据块*/
    Block BlocKData[N];
    /*存放Data数据块对应的索引, 每个记录对应一个Block, 其中value存储的是块相对于文件头的偏移量*/
    Block BlockIndex;
    /*存储过滤规则，默认没有，一般使用布隆过滤器，可能为空，里面每条记录对应一个block生成的过滤器*/
    Block BlcokMeta;

    struct Footer
    {
        /*过滤器数据相对于文件头的偏移量*/
        uint64 metaindex_offset;
        /*过滤器数据长度*/
        uint64 metaindex_size;
        /*BlockIndex数据相对于文件头的偏移量*/
        uint64 blockindex_offset;
        /*BlockIndex数据长度*/
        uint64 blockindex_size;
        /*文件尾部填充的魔数*/
        uint64 magic_number;
    }
};

LRU缓存

　　leveldb中读性能比不了内存数据库，由于分层存储，为了尽量减少磁盘操作，实现了一套缓存机制，缓存以查找的key作为hash，对应值为key所在的table指针。缓存做了两级,外层是是固定大小为16的hash表,hash表中每条记录中对应一个随元素数量增长的hash表, 两层hash一方面可以减少hash碰撞次数, 另一方面rehash时减少copy内存的长度, 内层的缓存操作是需要加锁的, 分层之后减少锁的竞争次数.

分层

leveldb磁盘存储的文件分为level-0到level-6, 每一层中有若干个文件, 所有文件长度和最大限制如下, 默认存储总量10TB左右. 其中level-0中默认最大文件个数限制为4

level-0 10M

level-1 100M

level-2 1000M

level-3 10000M

level-4 100000M

level-5 1000000M

level-6 10000000M

合并

　　leveldb数据存储分为两部分内存中MemTable和磁盘上Table文件, 合并的过程就是将内存数据合并入磁盘中, 磁盘中低层数据向高层合并.向数据库中写入一个key时, 首先将Key和Value值写入log文件中, 然后检查MemTable中数据大小, 如果大于临界值(默认4M), 则重新创建MemTable, 将Key插入, 原来的MemTable则保存在Imm中, 只用于查询使用, 检查是否需要进行合并操作, 流程如下.

　　1.判断Imm是否为空, Imm非空先遍历Imm中数据依次写入sst文件中, 然后挑选合适的level进行合并, 从level-0开始遍历到level-6, 挑选过程如下, 挑选结束后直接将生成的sst文件添加进挑选的level.

　　a) 由于level-0不同文件中存在重叠key, 因此单独判断Imm中key和level0中key是否重叠, 重叠则直接将Imm中数据合并入level-0中, 否则继续向下;

　　b) 假设遍历到level-1层发现key和Imm中key有重叠, 则直接将Imm合并入level-0层; 否则继续向下.

　　c) 假如遍历到level-1层发现key和Imm中key没有重叠, 但是level-2层中key与Imm中key重叠文件长度大于kMaxGrandParentOverlapBytes(默认20M), 则直接合并入level-0层, 避免level-1和level-2层重叠太多,后面产生过多的合并操作. 否则level+1后继续步骤b进行遍历.

　　2.Imm为空时, 则需要合并磁盘中的数据是否需要合并, 每次修改VersionSet集合中的文件时,都会对每层数据评估得出一个score, 评估出下次最合适合并的level,

　　level-0层 : score=文件个数/文件最大总数.

　　level-1~6层, score=文件总长度/本层文件最大长度.

　　根据获取的score值, 得出本次最需要合并的level, 如果level中文件在level+1中key没有重叠, 则直接将level中文件移除, 并添加到level+1中; level和level+1中key存在重叠, 则需要使用合并迭代器, 包含了level和level+1层需要合并的文件迭代器(可能包含多个文件), 每次合并迭代器迭代一次, 选择两层中最小的key, 插入到新的输出文件, 如果当前遍历的key已经被删除或者不是最新的, 则直接忽略. 最终生成一个新的文件, 插入到level+1层.

查找元素

　　查找元素过程, 首先在MemTable中查找, 找到则返回, 否则在Imm中查找, 找到则返回, 否则继续开始在level0~6中进行查找, 首先在每一层中使用二分查找key所在的文件, 文件找到之后, 通过快索引二分查找key所在的块, 通过块中的过滤器(一般是布隆过滤), 匹配key值是否存在, 不存在直接返回查找不到, 否则通过重启点二分查找key所在的记录, 从而定位key是否存在, 存在返回key对应的value, 否则返回查找不到.

添加删除修改元素

　　leveldb添加元素,只需要将元素添加进MemTable中即可, 添加元素时会生成一个内部key, 包含是否删除元素标志和唯一的序列号, 通过删除标志确定是否为删除元素, 通过序列号可以确定元素是否为最新元素, 进行合并操作时可以判断元素状态. leveldb删除元素时并不会对原来的元素进行修改移除, 只是插入一个设置删除标志位的新元素, 合并时会移除原来的元素, 更新操作操作一样, 同样插入一个新元素, 合并时通过序列号确定元素是否为最新的, 从而移除老的元素.

Version管理

　　leveldb中文件版本信息和数据库的信息都写入在MANIFEST-xxxxx文件中, 文件及其重要, 包含每一层的所有文件的描述, 日志文件序号, 插入key的序列号等信息, 丢失之后数据库基本废掉. VersionSet版本集合操作版本信息, VersionEdit保存了Version的修改信息, 以追加的方式添加在MANIFEST-xxxxx文件中, 因此MANIFEST-xxxxx文件中还保存有历史版本信息, 每次数据库重启都需要重新读取MANIFEST-xxxxx文件并将所有的版本信息读出, 并执行相应的VersionEdit, 生成当前版本Version. 每次进行合并操作都会生成一个VersionEdit, 追加到VersionSet中, 并写入MANIFEST-xxxxx文件中.