rocksdb和leveldb性能比較——寫性能

前面學習了一下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
資料量	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會嚴重影響性能），猜測的原因可能是：

1. leveldb的skiplist的原子指針用的是memory barrier實作的，而rocksdb使用的atomic實作的。
2. rocksdb采用了很多虛函數的地方，性能有可能比leveldb要差一些。

場景2

每個key 8byte，value 1000byte。

	rocksdb(flush和compaction共用線程)	rocksdb(flush和compaction分開線程)
	1000000
	1G
	70	138	125
	14.62857143	7.420289855	8.192
	14285.71429	7246.376812	8000
	是

結論仍然是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的