前面學習了一下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的