前面学习了一下rocksdb，这个db是对leveldb的一个改进，是基于leveldb1.5的版本上的改进，而且leveldb1.5以后也在不断的优化，下面从写入性能对两者进行对比。

比较的leveldb的版本是1.18，rocksdb的版本是3.10.1.

在比较的时候需要将leveldb和rocksdb的参数调成一样的，本文的参数为，

memtable 4M，最多2个memtable

level0_slowdown_writes_trigger=8，level0_stop_writes_trigger=12，level0_file_num_compaction_trigger=4，

flush和compaction共用一个进程

leveldb和rocksdb在后台进程管理的默认配置也是不一样的，leveldb默认只能有一个后台进程用于flush和compaction，而rocksdb flush和compaction都会有一个进程，本文特殊没有说明的rocksdb就是和leveldb一样的，flush和compaction共用一个进程

每个key 8byte，没有value

这个场景在关系链系统里面非常常见，因为关系链系统是key-list，使用leveldb类似系统实现的时候，需要将list中的id提到key里面

得到的测试结果如下：

结论是leveldb比rocksdb要略胜一筹，由于value为空，整个的吞吐量和磁盘的吞吐量（100Mps到150Mps）还相差比较远，所以并没有发生写stall的情况。因为没有发生stall，所以性能对比完全是内存操作的性能的对比。

这个场景比的主要是内存的写操作速度，可以看出leveldb要好一些。

因为主要是内存操作，内存操作没有log，（加上log会严重影响性能），猜测的原因可能是：

1. leveldb的skiplist的原子指针用的是memory barrier实现的，而rocksdb使用的atomic实现的。
2. rocksdb采用了很多虚函数的地方，性能有可能比leveldb要差一些。

每个key 8byte，value 1000byte。

leveldb rocksdb(flush和compaction共用线程) rocksdb(flush和compaction分开线程) 1000000 1000000 1000000 吞吐量(Mps) 14.62857143 7.420289855 8.192 14285.71429 7246.376812 是否发生stall

结论仍然是leveldb要更好一些，具体查看LOG文件，可以看出端倪，rocksdb的最后的level分布是：[6 359 148 0 0 0 0]，level1文件严重超出范围，这样level0的文件并到level1上的时候就需要读入非常多的文件。咋

其中一次8个level0的319个level1的文件进行一次compaction，花费的时间可想而知。

那么为什么会这样呢？因为rocksdb在挑选compaction的时候，如果level0的文件数目超出level0_slowdown_writes_trigger的时候得分异常高，所以会一直发生level0向level1转移的情况，没有机会level1向level2转移。在这种情况下rocksdb就走向了深渊。。。。leveldb挑选compaction的时候，level0的分值是文件数目除以kL0_CompactionTrigger，其他level的分值是该level的总文件大小除以这个level的最大byte

当rocksdb的flush和compaction分为两个进程的时候时间稍有减少，可以看出效果很不明显。这个原因是磁盘是瓶颈，分为两个进程并不能提高磁盘的吞吐量。

从这个比较中可以看出，在写量非常大的时候，leveldb的性能还是要优于rocksdb的

前面学习了一下rocksdb，这个db是对leveldb的一个改进，是基于leveldb1.5的版本上的改进，而且leveldb1.5以后也在不断的优化，下面从写入性能对两者进行对比。

比较的leveldb的版本是1.18，rocksdb的版本是3.10.1.

在比较的时候需要将leveldb和rocksdb的参数调成一样的，本文的参数为，

memtable 4M，最多2个memtable

level0_slowdown_writes_trigger=8，level0_stop_writes_trigger=12，level0_file_num_compaction_trigger=4，

flush和compaction共用一个进程

leveldb和rocksdb在后台进程管理的默认配置也是不一样的，leveldb默认只能有一个后台进程用于flush和compaction，而rocksdb flush和compaction都会有一个进程，本文特殊没有说明的rocksdb就是和leveldb一样的，flush和compaction共用一个进程

每个key 8byte，没有value

这个场景在关系链系统里面非常常见，因为关系链系统是key-list，使用leveldb类似系统实现的时候，需要将list中的id提到key里面

得到的测试结果如下：

leveldb rocksdb 10000000 10000000 吞吐量(Mps) 1.428571429 1.095890411 178571.4286 136986.3014 是否发生stall

结论是leveldb比rocksdb要略胜一筹，由于value为空，整个的吞吐量和磁盘的吞吐量（100Mps到150Mps）还相差比较远，所以并没有发生写stall的情况。因为没有发生stall，所以性能对比完全是内存操作的性能的对比。

这个场景比的主要是内存的写操作速度，可以看出leveldb要好一些。

因为主要是内存操作，内存操作没有log，（加上log会严重影响性能），猜测的原因可能是：

1. leveldb的skiplist的原子指针用的是memory barrier实现的，而rocksdb使用的atomic实现的。
2. rocksdb采用了很多虚函数的地方，性能有可能比leveldb要差一些。

每个key 8byte，value 1000byte。

leveldb rocksdb(flush和compaction共用线程) rocksdb(flush和compaction分开线程) 1000000 1000000 1000000 吞吐量(Mps) 14.62857143 7.420289855 8.192 14285.71429 7246.376812 是否发生stall

结论仍然是leveldb要更好一些，具体查看LOG文件，可以看出端倪，rocksdb的最后的level分布是：[6 359 148 0 0 0 0]，level1文件严重超出范围，这样level0的文件并到level1上的时候就需要读入非常多的文件。咋

其中一次8个level0的319个level1的文件进行一次compaction，花费的时间可想而知。

那么为什么会这样呢？因为rocksdb在挑选compaction的时候，如果level0的文件数目超出level0_slowdown_writes_trigger的时候得分异常高，所以会一直发生level0向level1转移的情况，没有机会level1向level2转移。在这种情况下rocksdb就走向了深渊。。。。leveldb挑选compaction的时候，level0的分值是文件数目除以kL0_CompactionTrigger，其他level的分值是该level的总文件大小除以这个level的最大byte

当rocksdb的flush和compaction分为两个进程的时候时间稍有减少，可以看出效果很不明显。这个原因是磁盘是瓶颈，分为两个进程并不能提高磁盘的吞吐量。

从这个比较中可以看出，在写量非常大的时候，leveldb的性能还是要优于rocksdb的