leveldb研究系列二——各个组件和读写时序介绍

在学习leveldb的过程中,我走了很多弯路,比如在对整体了解不足的情况下就开始阅读源代码,这其实是不可取的,所以我希望大家在学习leveldb的时候要对整体有个大致的了解,这样就可以加快整个学习过程,leveldb涉及很多数据结构的知识( skiplist,  bloom filter, 多路归并排序,还有一个LRUcache,hash,等等) 还有一点点令人棘手底层的问题,多线程,并发控制,原子操作,内存屏障,(memory barrier,想想关键字volitale)编码约定(大小端)。

总而言之,希望大家先有相关准备再去看源代码,让我先给大家介绍leveldb的组件和读写时序:

1.首先 我们要牢记,leveldb的是一个用来提高写性能的,内存小巧可控的KV数据库(可控的原因是在于后面讲到cache可以配置,可选), 采用一系列的方式保证写性能  先上图 给个写时序



write 操作很简单,写入磁盘log (顺序写入数据),在memtable 插入<key,value>  ,memtalbe主要依靠skiplist实现数据挂载,skiplist是一种类似于自平衡二叉树的数据结构,不过相对而言具有更好的写性能(调整节点少)   在后续章节我会详细讲解此数据结构。      到这里为止, write操作已经结束,也就是说write操作包括一次顺序磁盘顺序写,一次写内存。(现在应该有感觉,leveldb为何写这么快)  这里还有一个immutable memtable,  是这样的,在memtable达到check point(要满员的时候) memtable 就成immutable memtable(同时会有新的log被启用) 顾名思义,是不变的,只读不写,等待线程写入磁盘,生成SSTable文件(SSTable0)  SSTable会compaction到下N层, 一层又一层,所以叫leveldb.....  

顺便说一下,删除,修改都是write操作,删除只是做标记,修改是插入和原来key一样的新值,这些操作本质上都是写, 最后的物理的上删除和修改要到SSTbale合并的时候才执行 ,lazzy done,这里用到了Sequence来指明操作先后次序,在合并的时候保证取用最新的值,后续详讲。(谁能告诉我,这个编辑器怎么用?复制一个单词就变了字体,无力吐槽。。。。)

接下来该说说读时序,读是非常复杂和曲折,先上个图,ps :visio太渣 画了老半天(/ □ \)



虽然数据并没有即时的被归档,但是 数据有先后次序,按照先后次序,我们先在内存的memtable 和 immutable memtable 查找,如果没有找到我们就要去磁盘下面找或者在cache中,  这里有mainfest索引文件,指出SSTable 中开始和结束key 的区间,据此可以定位,key可能在哪个sstable中,需要提到sstble0 和其他sstbale区间是有可能重叠,其他sstbale区间彼此不重叠,这句话的意思就是说manifest查阅的结果,要么指定一个可能的sstbale;  要么有两个,并且一个是sstbale 0。

mainfest指出可能的sstable,  如果系统配置了cache被选用,这时候会首先在cache中查找,否则把磁盘中的sstbale调入内存cache中, 每个sstbale都有自己索引文件用来快速(按照磁盘block索引)在查找索引之前,首先采取bloom filter过滤大部分不在其中的数据,而后在查找索引,找到数据block,最后才能返回。   真的好曲折啊。。。。哈哈

 到此为止,我已经简单介绍了leveldb的读写时序,和各个组件功能,不过sstable的归并还没介绍,下章详细将,上次提到的lsm_tree策略,这里简单说来就是 不要即刻更新索引,而等到某个点,批量处理,合并排序, 这样写就会很快(不需要合并更新)  带来的副作用并不大,   这里副作用体现在 在读 查阅的时候,要先查找内存数据,再查找磁盘中归并的数据,而不是一次可以查找一个索引。  这样做的目的就是为了加快读,并且由于批量处理索引会大大减少磁盘I/O 。关于lsm_tree策略详见http://blog.csdn.net/v_july_v/article/details/7526689  (这人是我本科校友 哈哈哈哈)

哈哈    下面的章节我会详细介绍,各个组件组成,关键数据结构,源代码接口,性能比较      等等   未完待续。。。

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页