前面学习了一下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共用一个进程
场景1
每个key 8byte，没有value
这个场景在关系链系统里面非常常见，因为关系链系统是key-list，使用leveldb类似系统实现的时候，需要将list中的id提到key里面
得到的测试结果如下：
| leveldb | rocksdb | |
| 请求数 | 10000000 | 10000000 |
| 数据量 | 80M | 80M |
| 耗时s | 56 | 73 |
| 吞吐量(Mps) | 1.428571429 | 1.095890411 |
| qps | 178571.4286 | 136986.3014 |
| 是否发生stall | 否 | 否 |
结论是leveldb比rocksdb要略胜一筹，由于value为空，整个的吞吐量和磁盘的吞吐量（100Mps到150Mps）还相差比较远，所以并没有发生写stall的情况。因为没有发生stall，所以性能对比完全是内存操作的性能的对比。
这个场景比的主要是内存的写操作速度，可以看出leveldb要好一些。
因为主要是内存操作，内存操作没有log，（加上log会严重影响性能），猜测的原因可能是：
- leveldb的skiplist的原子指针用的是memory barrier实现的，而rocksdb使用的atomic实现的。
- rocksdb采用了很多虚函数的地方，性能有可能比leveldb要差一些。
场景2
每个key 8byte，value 1000byte。
| leveldb | rocksdb(flush和compaction共用线程) | rocksdb(flush和compaction分开线程) | |
| 请求数 | 1000000 | 1000000 | 1000000 |
| 数据量 | 1G | 1G | 1G |
| 耗时s | 70 | 138 | 125 |
| 吞吐量(Mps) | 14.62857143 | 7.420289855 | 8.192 |
| qps | 14285.71429 | 7246.376812 | 8000 |
| 是否发生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的