前面學習了一下rocksdb，這個db是對leveldb的一個改進，是基於leveldb1.5的版本上的改進，並且leveldb1.5之後也在不斷的優化，下面從寫入性能對二者進行對比。函數
前言
比較的leveldb的版本是1.18，rocksdb的版本是3.10.1.post
在比較的時候須要將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共用一個進程atom
場景1
每一個key 8byte，沒有valuespa
這個場景在關係鏈系統裏面很是常見，由於關係鏈系統是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的