CrimsonDB系列(二) compaction優(yōu)化

本文為哈佛大學(xué)DASLab自研的CrimsonDB存儲系列文章第二篇,完整的系列文章列表見http://daslab.seas.harvard.edu/projects/crimsondb-demo/#publications

CrimsonDB第一篇 Monkey: Optimal Navigable KeyValue Store

與第一篇類似上枕,本文在 Monkey的數(shù)學(xué)基礎(chǔ)之上烁兰,通過建模的方式對LSM 的時間復(fù)雜度和寫放大度進行了建模分析拨扶,通過權(quán)衡時間復(fù)雜度和寫放大割坠,提出了lazy compaction的設(shè)計方案蕴侧。本文的核心啟發(fā)來源于最底層的數(shù)據(jù)量最多,因此主要得查詢開銷來自與最底層涤妒。第一篇文章提到上層的數(shù)據(jù)需要的bloom filter內(nèi)存空間很小渣触,因此上層的數(shù)據(jù)查詢大部分可以通過bloom filter進行優(yōu)化。那么是否可以通過降低上層的compaction來減少io放大呢蟋字,延時上層compact會由于overloap帶來部分的查詢放大稿蹲,但是這些放大和降低io的開銷相比起來某些時候是可以忽略的,因此可以通過動態(tài)調(diào)節(jié)compaction來達到時間復(fù)雜度和io寫放大的平衡鹊奖。

空間放大

在分析空間放大之前苛聘,再次簡單介紹下tiering compaction和leveling compaction。level層內(nèi)部不存在overlap忠聚,tiering層內(nèi)部則可能存在overlap设哗。因此對于tiering,極端情況下 如果每一個run之間都存在overlap两蟀,那么空間放大為O(T),网梢。對于leveling,由于層內(nèi)部不存在overlap垫竞,層級之間的數(shù)據(jù)層T倍增長澎粟,因此極端情況下L(n-1)的數(shù)據(jù)都被更新了,此時leveling的空間放大為N(1/T).

IO 放大

通過對點查和scan進行建模復(fù)雜度分析欢瞪,發(fā)現(xiàn)主要的查詢開銷來自于最底層活烙。因為最底層的entry數(shù)量最多,同時基于第一篇提到的遣鼓,上層的run可以通過設(shè)置bloom filter來優(yōu)化查詢啸盏,因此可以通過延時上層run的compaction來減少io的開銷,通過犧牲一定的查詢開銷來大幅降低merge io骑祟,上層的查詢開銷大部分可以被 bloom filter所處理因此相比于減小IO放大帶來的收益這個開銷可以忽略不計回懦。

通過delay compaction來降低merge的IO 開銷,其實就是在tiering與leveling兩種策略之間進行權(quán)衡次企。rocksdb默認(rèn)的compaction策略是L0 使用了tiering怯晕,其他level使用了leveling。本文則更近一步缸棵,在除掉最底層level的層級進行進行compaction策略的權(quán)衡舟茶。

Lazy leveling

lazy leveling的思想是在1到L-1層使用tiering ,在L層使用leveling堵第。通過該策略可以保證在1到L-1層每層之內(nèi)最多包含T-1個run吧凉,在L層最多包含1個run,因此空間放大依然是O(1/T). 與第一篇提到的一樣踏志,Dostoevsky 每一層的FPR也是指數(shù)遞增的阀捅。

通過下面的建模分析可以發(fā)現(xiàn),lazy leveling在降低merge IO的同時并不會給查詢帶來額外大的開銷

Fluid LSM-Tree

lazy leveling的思想是L 層使用leveling针余,其他層使用tiering饲鄙。將該模式進行抽象可以得出如下通用式子,其中K 表示1到L-1 層的run數(shù)量, Z 表示L層的run數(shù)量.

  • K = 1 and Z = 1 give leveling.
  • K = T ? 1 and Z = T ? 1 give tiering.
  • K = T ? 1 and Z = 1 give Lazy Leveling

通過該式子盡心建脑惭悖可以得出如下的復(fù)雜度分析

具體哪一層如何選擇K和Z 則需要根據(jù)具體的負(fù)載進行計算權(quán)衡傍妒。

總結(jié)

在所有的領(lǐng)域都不可能存在完美的方案,每一個方案都是對不同功能點之間的取舍摸柄。功能點之間的關(guān)聯(lián)幾乎都可以抽象成類似存儲CAP的選擇颤练。本文的核心在于根據(jù)實際建模分析,在不同功能點之間抽象出通用模型驱负,并根據(jù)負(fù)載特征對模型進行迭代選擇最優(yōu)的參數(shù)解嗦玖。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市跃脊,隨后出現(xiàn)的幾起案子宇挫,更是在濱河造成了極大的恐慌,老刑警劉巖酪术,帶你破解...
    沈念sama閱讀 210,978評論 6 490
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件器瘪,死亡現(xiàn)場離奇詭異翠储,居然都是意外死亡,警方通過查閱死者的電腦和手機橡疼,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 89,954評論 2 384
  • 文/潘曉璐 我一進店門援所,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人欣除,你說我怎么就攤上這事住拭。” “怎么了历帚?”我有些...
    開封第一講書人閱讀 156,623評論 0 345
  • 文/不壞的土叔 我叫張陵滔岳,是天一觀的道長。 經(jīng)常有香客問我挽牢,道長谱煤,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 56,324評論 1 282
  • 正文 為了忘掉前任禽拔,我火速辦了婚禮趴俘,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘奏赘。我一直安慰自己寥闪,他們只是感情好,可當(dāng)我...
    茶點故事閱讀 65,390評論 5 384
  • 文/花漫 我一把揭開白布磨淌。 她就那樣靜靜地躺著疲憋,像睡著了一般。 火紅的嫁衣襯著肌膚如雪梁只。 梳的紋絲不亂的頭發(fā)上缚柳,一...
    開封第一講書人閱讀 49,741評論 1 289
  • 那天,我揣著相機與錄音搪锣,去河邊找鬼秋忙。 笑死,一個胖子當(dāng)著我的面吹牛构舟,可吹牛的內(nèi)容都是我干的灰追。 我是一名探鬼主播,決...
    沈念sama閱讀 38,892評論 3 405
  • 文/蒼蘭香墨 我猛地睜開眼狗超,長吁一口氣:“原來是場噩夢啊……” “哼弹澎!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起努咐,我...
    開封第一講書人閱讀 37,655評論 0 266
  • 序言:老撾萬榮一對情侶失蹤苦蒿,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后渗稍,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體佩迟,經(jīng)...
    沈念sama閱讀 44,104評論 1 303
  • 正文 獨居荒郊野嶺守林人離奇死亡团滥,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 36,451評論 2 325
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了报强。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片灸姊。...
    茶點故事閱讀 38,569評論 1 340
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖躺涝,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情扼雏,我是刑警寧澤坚嗜,帶...
    沈念sama閱讀 34,254評論 4 328
  • 正文 年R本政府宣布,位于F島的核電站诗充,受9級特大地震影響苍蔬,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜蝴蜓,卻給世界環(huán)境...
    茶點故事閱讀 39,834評論 3 312
  • 文/蒙蒙 一碟绑、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧茎匠,春花似錦格仲、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,725評論 0 21
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至汽馋,卻和暖如春侮东,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背豹芯。 一陣腳步聲響...
    開封第一講書人閱讀 31,950評論 1 264
  • 我被黑心中介騙來泰國打工悄雅, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人铁蹈。 一個月前我還...
    沈念sama閱讀 46,260評論 2 360
  • 正文 我出身青樓宽闲,卻偏偏與公主長得像,于是被迫代替她去往敵國和親握牧。 傳聞我的和親對象是個殘疾皇子便锨,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 43,446評論 2 348

推薦閱讀更多精彩內(nèi)容