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

轉載于:https://www.cnblogs.com/jfwang/p/4460191.html

總結

以上是生活随笔為你收集整理的rocksdb和leveldb性能比较——写性能的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。