LevelDB介绍-随笔
https://blog.csdn.net/linuxheik/article/details/52768223
刚刚看到这篇文章，介绍的比上一篇详细：
https://blog.csdn.net/charles1e/article/details/52966776
LevelDB是google开源的KV（key-value，存储的数据都是kv的形式）单机数据库，官方版本是C++，比特币使用的是c++版本：
https://github.com/google/leveldb
以太坊使用的是go语言版本：
https://github.com/syndtr/goleveldb
性能方面：号称顺序写、随机写速度快，顺序读快，随机读性能一般，
所以想了解下为什么性能是这样的。读了上面的博客和其他一些文章，大致有了答案。
LevelDB写数据的流程，写数据的时候依次写入
1 Log文件（用来系统崩溃后恢复数据，防止丢失数据），存储的数据是Key无序的，写入的时候顺序写入
2 memtable文件（内存，使用Skiplist实现），Key有序
当memtable满足一定条件（写满了之后，默认是4M大小，以太坊设置的是192M）改变为immutable memtable同时触发执行minor compaction（leveldb实现了minor compaction和major compaction）写文件到level 0的文件（Key有序，但是不同的level 0文件可能存在key重叠，level 0 之上的level 1...N不会存在key重叠）
有另外一个线程监测是否需要major compaction，当level i（0-N)的文件满足一定条件（会计算一个score，level 0达到4个文件限制、level 0以上根据文件的总大小）会触发major compaction，选出level i的某个文件与level i+1的某些文件进行合并生成新的level i+1文件（这里有几个问题待回答：
1 是合并成一个level i+1的文件还是根据文件大小限制切分成几个文件
2 。。。怎么忽然忘记了什么问题）
每层文件的数据量大小限制是上一层文件的10倍，这种分层的结构也是leveldb的由来
所以我们知道了顺序写和随机写为什么性能高了：
因为随机写和顺序写是一样的，都只是顺序写入log文件和memtable，所以性能就是写log文件的性能，
因为写log文件对磁盘来说是顺序写入，所以性能还是很高的。
LevelDB的读数据流程，读数据的时候依次查询：
1 memtable和immutable memtable
2 cache（有table cache和block cache）
3 根据bloom filter依次从level 0开始查找（bloom filter怎么使用的需要再看下代码，是每个db文件查还是每个level的db一起查）
4 如果是从level中查找到了，会将block读入cache供后续读取
所以我们也知道了为什么顺序读性能高，随机读性能一般
顺序读的时候除了第一次需要查找到key的位置，后续读的时候依赖于key有序和cache，读取性能很高
但是随机读需要每次都查找然后从磁盘中读取数据，所以性能相对一般
答案有了，下一步是看代码查看具体实现
可查看这篇文章：
https://blog.csdn.net/csds319/article/details/80361450