leveldb设计思想学习总结

leveldb的价值

每一类组件，都有它特定擅长的应用场景。在leveldb出世之前，我们对于nosql下的kv存储，我们有redis方案存储。然而redis数据存储的上限，即是机器内存。内存在目前阶段，算是比较昂贵。而leveldb的出现，提供了一个可以以机器磁盘为容量上限，支持持久化的写操作的同时，做到写速度较快，读速度也不慢的一个解决方案。

leveldb如何解决问题

leveldb面对的问题

作为一个支持持久化KV系统，核心就这么几个。CURD
1）持久化
2）写操作
3）读操作
4）查找
5）删除

解决方案

方案一

需要支持持久化，则我们一般会用WAL技术，即是先写日志。只要日志写成功，那么数据就算持久化到磁盘中了。
这个方案能够满足1）持久化和2）写操作的要求

存在问题：
但是对于读操作不友好。只写日志需要比较好的查询。

方案二

基于上面的思路，我能否增加一块内存来缓存数据，即是我写完日志之后，我把数据在内存中写一份。内存中维护一份KV的内存表。
如果数据量在比较小的情况下，那这个方案能够比较好的满足以上要求。
但是，数据量大的时候无法工作。

存在问题：
当数据量比较大的时候，内存无法支撑时，需要到日志中去查找数据，读操作会显得力不所心。

方案三

方案二的问题，在于数据量较大的情况下。
1）如果查找数据在内存中，则直接返回数据。
2）如果查找数据不在内存中，而在磁盘中，则需要想办法解决这个场景的问题。
如果我们在磁盘中的日志，也能够存储的时候保证key有序，查找的时候，能够通过比较快的定位磁盘文件，并能够找到具体的文件来找具体的key，通过二分搜索，则能够比较快的完成查找工作。

基于上面的分析，leveldb的主体设计思路已经呈现出来。

leveldb解决方案

写操作

1. WAL写到日志，再更新到memtable中。
2. 如果memtable超过一定的size之后，则转换成imm memtable，imm内存块与磁盘中的sstable进行合并落盘。
3. 磁盘中的sstable根据新旧进行分层。上层比下层要新，数据量要少。
   

读操作

1. 在memtable中查找数据。
2. 在imm内存块中查找数据。
3. 在level0、level1、…levelN中进行查找数据
   以上操作，每一步骤如果找到则返回，如果未找到则继续往下一步骤执行。
   

待续。。。