?

Rocksdb的優(yōu)劣及應(yīng)用場景分析?

Rocksdb也是一樣，也有它的優(yōu)勢劣勢及特定的適用場景。今天我就從設(shè)計的角度來分析一下。

基礎(chǔ)架構(gòu)

? ? ? ?上圖就是Rocksdb的基礎(chǔ)架構(gòu)。Rocksdb中引入了ColumnFamily(列族, CF)的概念，所謂列族也就是一系列kv組成的數(shù)據(jù)集。所有的讀寫操作都需要先指定列族。寫操作先寫WAL，再寫memtable，memtable達(dá)到一定閾值后切換為Immutable Memtable，只能讀不能寫。后臺Flush線程負(fù)責(zé)按照時間順序?qū)mmu Memtable刷盤，生成level0層的有序文件(SST)。后臺合并線程負(fù)責(zé)將上層的SST合并生成下層的SST。Manifest負(fù)責(zé)記錄系統(tǒng)某個時刻SST文件的視圖，Current文件記錄當(dāng)前最新的Manifest文件名。 ?每個ColumnFamily有自己的Memtable， SST文件，所有ColumnFamily共享WAL、Current、Manifest文件。

架構(gòu)分析

? ? ? ?整個系統(tǒng)的設(shè)計思路很好理解，這種設(shè)計的優(yōu)勢很明顯，主要有以下幾點：

? ? ? 1.所有的刷盤操作都采用append方式，這種方式對磁盤和SSD是相當(dāng)有誘惑力的；

? ? ? 2.寫操作寫完WAL和Memtable就立即返回，寫效率非常高。 ?

? ? ? ?3.由于最終的數(shù)據(jù)是存儲在離散的SST中，SST文件的大小可以根據(jù)kv的大小自由配置， ? ? ? ? ? ?因此很適合做變長存儲。

? ? ? 但是這種設(shè)計也帶來了很多其他的問題：

? ? ? ?1.為了支持批量和事務(wù)以及上電恢復(fù)操作，WAL是多個CF共享的，導(dǎo)致了WAL的單線程寫 ? ? ? ?模式，不能充分發(fā)揮高速設(shè)備的性能優(yōu)勢（這是相對介質(zhì)講，相對B樹等其他結(jié)構(gòu)還是有優(yōu) ? ? ? ?勢）；

? ? ? ?2.讀寫操作都需要對Memtable進(jìn)行互斥訪問，在多線程并發(fā)寫及讀寫混合的場景下容易形 ? ? ? ?成瓶頸。

? ? ? 3.由于Level0層的文件是按照時間順序刷盤的，而不是根據(jù)key的范圍做劃分，所以導(dǎo)致各 ? ? ? ? 個文件之間范圍有重疊，再加上文件自上向下的合并，讀的時候有可能需要查找level0層的 ? ? ? ? ?多個文件及其他層的文件，這也造成了很大的讀放大。尤其是當(dāng)純隨機寫入后，讀幾乎是 ? ? ? ? ?要查詢level0層的所有文件，導(dǎo)致了讀操作的低效。

? ? ? 4.針對第三點問題，Rocksdb中依據(jù)level0層文件的個數(shù)來做前臺寫流控及后臺合并觸發(fā)， ? ? ? ? ?以此來平衡讀寫的性能。這又導(dǎo)致了性能抖動及不能發(fā)揮高速介質(zhì)性能的問題。 ?

? ? ?5.合并流程難以控制，容易造成性能抖動及寫放大。尤其是寫放大問題，在筆者的使用過程中實際測試的寫放大經(jīng)常達(dá)到二十倍左右。這是不可接受的，當(dāng)前我們也沒有找到合適的解決辦法，只是暫時采用大value分離存儲的方式來將寫放大盡量控制在小數(shù)據(jù)。

適用場景

? ? ? ?1.對寫性能要求很高，同時有較大內(nèi)存來緩存SST塊以提供快速讀的場景；

? ? ? ?2.SSD等對寫放大比較敏感以及磁盤等對隨機寫比較敏感的場景；

? ? ? 3.需要變長kv存儲的場景； ?

? ? ? 4.小規(guī)模元數(shù)據(jù)的存取；

不適合場景

? ? ? ?1.大value的場景，需要做kv分離；

? ? ? ?2.大規(guī)模數(shù)據(jù)的存取

作者：從此啟航
鏈接：https://www.jianshu.com/p/73fa1d4e4273
來源：簡書
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。

總結(jié)

以上是生活随笔為你收集整理的Rocksdb的优劣及应用场景分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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