前面學(xué)習(xí)了一下rocksdb，這個(gè)db是對(duì)leveldb的一個(gè)改進(jìn)，是基于leveldb1.5的版本上的改進(jìn)，而且leveldb1.5以后也在不斷的優(yōu)化，下面從寫入性能對(duì)兩者進(jìn)行對(duì)比。

?

前言

比較的leveldb的版本是1.18，rocksdb的版本是3.10.1.

在比較的時(shí)候需要將leveldb和rocksdb的參數(shù)調(diào)成一樣的，本文的參數(shù)為，

memtable 4M，最多2個(gè)memtable

level0_slowdown_writes_trigger=8，level0_stop_writes_trigger=12，level0_file_num_compaction_trigger=4，

flush和compaction共用一個(gè)進(jìn)程

leveldb和rocksdb在后臺(tái)進(jìn)程管理的默認(rèn)配置也是不一樣的，leveldb默認(rèn)只能有一個(gè)后臺(tái)進(jìn)程用于flush和compaction，而rocksdb flush和compaction都會(huì)有一個(gè)進(jìn)程，本文特殊沒有說明的rocksdb就是和leveldb一樣的，flush和compaction共用一個(gè)進(jìn)程

場(chǎng)景1

每個(gè)key 8byte，沒有value

這個(gè)場(chǎng)景在關(guān)系鏈系統(tǒng)里面非常常見，因?yàn)殛P(guān)系鏈系統(tǒng)是key-list，使用leveldb類似系統(tǒng)實(shí)現(xiàn)的時(shí)候，需要將list中的id提到key里面

得到的測(cè)試結(jié)果如下：

?	leveldb	rocksdb
請(qǐng)求數(shù)	10000000	10000000
數(shù)據(jù)量	80M	80M
耗時(shí)s	56	73
吞吐量(Mps)	1.428571429	1.095890411
qps	178571.4286	136986.3014
是否發(fā)生stall	否	否

結(jié)論是leveldb比rocksdb要略勝一籌，由于value為空，整個(gè)的吞吐量和磁盤的吞吐量（100Mps到150Mps）還相差比較遠(yuǎn)，所以并沒有發(fā)生寫stall的情況。因?yàn)闆]有發(fā)生stall，所以性能對(duì)比完全是內(nèi)存操作的性能的對(duì)比。

這個(gè)場(chǎng)景比的主要是內(nèi)存的寫操作速度，可以看出leveldb要好一些。

因?yàn)橹饕莾?nèi)存操作，內(nèi)存操作沒有l(wèi)og，（加上log會(huì)嚴(yán)重影響性能），猜測(cè)的原因可能是：

leveldb的skiplist的原子指針用的是memory barrier實(shí)現(xiàn)的，而rocksdb使用的atomic實(shí)現(xiàn)的。

rocksdb采用了很多虛函數(shù)的地方，性能有可能比leveldb要差一些。

?

場(chǎng)景2

每個(gè)key 8byte，value 1000byte。

?	leveldb	rocksdb(flush和compaction共用線程)	rocksdb(flush和compaction分開線程)
請(qǐng)求數(shù)	1000000	1000000	1000000
數(shù)據(jù)量	1G	1G	1G
耗時(shí)s	70	138	125
吞吐量(Mps)	14.62857143	7.420289855	8.192
qps	14285.71429	7246.376812	8000
是否發(fā)生stall	是	是	是

結(jié)論仍然是leveldb要更好一些，具體查看LOG文件，可以看出端倪，rocksdb的最后的level分布是：[6 359 148 0 0 0 0]，level1文件嚴(yán)重超出范圍，這樣level0的文件并到level1上的時(shí)候就需要讀入非常多的文件。咋

其中一次8個(gè)level0的319個(gè)level1的文件進(jìn)行一次compaction，花費(fèi)的時(shí)間可想而知。

那么為什么會(huì)這樣呢？因?yàn)閞ocksdb在挑選compaction的時(shí)候，如果level0的文件數(shù)目超出level0_slowdown_writes_trigger的時(shí)候得分異常高，所以會(huì)一直發(fā)生level0向level1轉(zhuǎn)移的情況，沒有機(jī)會(huì)level1向level2轉(zhuǎn)移。在這種情況下rocksdb就走向了深淵。。。。leveldb挑選compaction的時(shí)候，level0的分值是文件數(shù)目除以kL0_CompactionTrigger，其他level的分值是該level的總文件大小除以這個(gè)level的最大byte

?

當(dāng)rocksdb的flush和compaction分為兩個(gè)進(jìn)程的時(shí)候時(shí)間稍有減少，可以看出效果很不明顯。這個(gè)原因是磁盤是瓶頸，分為兩個(gè)進(jìn)程并不能提高磁盤的吞吐量。

?

結(jié)論

從這個(gè)比較中可以看出，在寫量非常大的時(shí)候，leveldb的性能還是要優(yōu)于rocksdb的

轉(zhuǎn)載于:https://www.cnblogs.com/jfwang/p/4460191.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。