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，读取性能很高

但是随机读需要每次都查找然后从磁盘中读取数据，所以性能相对一般

答案有了，下一步是看代码查看具体实现