Flag Commit:Supporting Efficient Transaction Recovery in Flash-Based DBMSs

Flag Commit:Supporting Efficient Transaction Recovery in Flash-Based DBMSs


0. Abstract

  • 研究在SLC閃存中運(yùn)行的DBMSs如何高效得完成事務(wù)的恢復(fù)。
  • 在傳統(tǒng)的shadow-paging方式的基礎(chǔ)上,提出了新的提交協(xié)議flagcommit,能利用flash的快速隨機(jī)訪問、異地更新、局部頁編程的特性。
  • 利用事務(wù)提交標(biāo)志鏈內(nèi)嵌事務(wù)狀態(tài)到閃存頁中以減少寫log記錄的需求。
  • 設(shè)計了兩種恢復(fù)協(xié)議:commit-based flag commit(CFC)和abort-based flag commit(AFC)。滿足不同的性能需求。
  • 基于TPC-C標(biāo)準(zhǔn)的測試,評估CFC和AFC性能優(yōu)于已有的恢復(fù)協(xié)議。

1. Introduction

  • Flash以其優(yōu)良特性備受關(guān)注,本文研究在事務(wù)恢復(fù)中如何利用SLC的優(yōu)點(diǎn)以提高基于閃存的DBMSs的性能。
  • 事務(wù)恢復(fù)作用:保證原子性(一系列動作要么全部完成,要么都不完成)和持久性(提交的寫得到保證)。事務(wù)恢復(fù)已有實(shí)現(xiàn):WAL和Shadow Paging。WAL:以日志的方式持久化舊數(shù)據(jù),再原地更新,寫操作太頻繁。SP:以磁盤上的shadow-page對數(shù)據(jù)頁做異地更新,系統(tǒng)維護(hù)一張page ID到disk address的映射表,性能問題使它在磁盤中表現(xiàn)不佳,但是在閃存中確是可取的。
  • 循環(huán)提交(cyclic commit)是一種根據(jù)影子頁提出的提交機(jī)制。為提交的事務(wù)的每一個頁維護(hù)一個循環(huán)鏈表,通過檢查這個表的存在與否確定該事務(wù)是否提交。根據(jù)這一思想產(chǎn)生兩種提交協(xié)議:SCC(simple cyclic commit)& BPCC(back pointer cyclic commit)。但是應(yīng)用中存在一些問題,如高并發(fā)等。
  • 本文提出一種新的基于影子頁的提交機(jī)制flagcommit,利用閃存頁局部可編程特性保持對事務(wù)狀態(tài)的追蹤,在每個shadow page中存儲事務(wù)的狀態(tài)標(biāo)志。基于這種思想本文提出兩種提交協(xié)議:CFC(commit-based flag commit)& AFC(abort-based flag commit)。它們適用與不同負(fù)載、具有不同性能。
  • 本文主要工作:
    • 首次提出基于閃存的DBMSs快速高效事務(wù)恢復(fù)機(jī)制,flagcommit。
    • 根據(jù)flagcommit提出兩種事務(wù)恢復(fù)協(xié)議,以及每個協(xié)議針對事務(wù)處理、垃圾回收、恢復(fù)的算法。
    • 擴(kuò)展上文提出的兩種協(xié)議對通用DBMS的支持。
    • 對本文提出的協(xié)議做性能評估,結(jié)果顯示性能提升量巨大。

2. Background

本節(jié)主要內(nèi)容:研究背景、閃存特性、閃存轉(zhuǎn)換層FTL

2.1 閃存特性

  • 物理特性:片-塊(128k+4k)-頁(2k+64byte),塊為擦除單位,頁為讀寫單位
  • IO特性:高效隨機(jī)訪問、先塊擦后頁寫、塊擦除次數(shù)有限(故在FTL中實(shí)現(xiàn)異地更新)

2.2 閃存轉(zhuǎn)換層FTL

  • FTL的核心是在內(nèi)存中維護(hù)一張邏輯地址到物理地址的映射表,閃存頁的OOB區(qū)存儲其邏輯地址,用以在啟動時在FTL建立正向的映射表。
  • 通過維護(hù)映射表實(shí)現(xiàn)異地更新。
  • 維護(hù)一張空間表,擁有垃圾回收模塊回收廢棄的頁。回收頁:觸發(fā)垃圾回收(如根據(jù)塊中的廢棄頁數(shù)量)- 將塊中有效頁復(fù)制到空閑塊中 - 擦除塊 - 將該塊掛接到空閑塊表中。
  • 利用分散寫和擦除實(shí)現(xiàn)閃存的磨損均衡,以延長使用壽命。

3. Basic Flag Commit Protocols

為了系統(tǒng)恢復(fù)時確定事務(wù)該重做還是丟棄,需要保持對數(shù)據(jù)庫的更新狀態(tài)以及事務(wù)狀態(tài)的跟蹤。shadow paging利用日志進(jìn)行異地更新以記錄事務(wù)狀態(tài)。本文提出的flagcommit基于shadowpaging的方法和循環(huán)提交的思想。

flagcommit在每個影子頁的OOB區(qū)存儲一個指向?qū)儆谕粋€事務(wù)的之前一個flash page的指針,同時存儲狀態(tài)標(biāo)志、頁版本、事務(wù)ID,通過這個鏈可以找到屬于該事務(wù)的所有頁,通過頁中的狀態(tài)標(biāo)志可以檢查該事務(wù)的提交狀態(tài)。

3.1 Commit-Based Flag Commit

CFC協(xié)議采用標(biāo)志指示已提交的事務(wù),默認(rèn)情況下頁的事務(wù)標(biāo)志置FALSE,當(dāng)事務(wù)提交時,屬于該事務(wù)的頁鏈的最后一個頁的事務(wù)標(biāo)識被更新為TRUE。

  • CFC中當(dāng)且僅當(dāng)影子頁中至少有一個頁的事務(wù)標(biāo)志為TRUE時,該事務(wù)為已提交事務(wù)。
  • 若更新該頁的事務(wù)已提交,那么該頁就是已提交頁。

In-memory Tables

  • 事務(wù)表Transaction Table:該表只維護(hù)正在執(zhí)行或中止的事務(wù)。表屬性包括事務(wù)ID、狀態(tài)、頁數(shù)、最后頁指針。
  • 臟頁表Dirty Page Table:保持對正在執(zhí)行的事務(wù)更新造成的每個臟頁的物理地址的跟蹤。
  • 地址映射表Direct Mapping Table:維護(hù)邏輯地址到物理地址的映射關(guān)系。

Normal Processing

  • 更新頁:
    • 事務(wù)T提出要更新邏輯頁P(yáng)
    • FlashDisk分配影子頁P(yáng)',并在該影子頁的OOB中初始化LBA、Ver、Link、XID、CommitFlag。
    • 更新事務(wù)表Transaction Table,NPage加一、LastPage指向P'。
    • P頁添加入臟頁表Dirty Table。
    • 更新地址映射表。
  • 提交事務(wù):
    • 事務(wù)提交請求。
    • 在事務(wù)表中找到該事務(wù)表項,獲得其最后一個影子頁,更新其狀態(tài)標(biāo)志為TRUE。
    • 將該事務(wù)從事務(wù)表中刪除。
    • 該事務(wù)更新的頁從臟頁表中刪除,且其指向的上一個頁標(biāo)記為廢棄頁。(PS:事務(wù)T要更新頁P(yáng),實(shí)際更新的是影子頁P(yáng)',此時臟頁表記錄的是事務(wù)ID-T、LBA-P'、LastLBA-P,一旦事務(wù)T提交,影子頁P(yáng)'“扶正”,原頁P(yáng)標(biāo)記為廢棄)
  • 事務(wù)中止:
    • 事務(wù)T中止
    • 撤銷T造成的更新,將其更新的頁P(yáng)'標(biāo)記為廢棄頁
    • 檢查臟頁表,找到P'的上一個頁P(yáng),通過修改映射表恢復(fù)P頁

Garbage Collection

垃圾回收通過空閑空間的閾值自動觸發(fā)。回收廢棄頁或過時的已提交的頁。被標(biāo)記為廢棄的頁被回收時,其所屬的事務(wù)還未提交的話,該事務(wù)的事務(wù)表項的NPage屬性要減一。

回收廢棄頁不足為道,此處關(guān)注一下回收過時的已提交頁,可能存在兩種情況。

  • 需要被回收的頁是該事務(wù)的最后一個頁P(yáng),即其事務(wù)狀態(tài)標(biāo)志為TRUE,則在回收前,通過其Link指針找到前一個頁P(yáng)1,然后置P1的狀態(tài)標(biāo)志為TRUE,再回收P,保證提交的事務(wù)的影子頁鏈中至少存在一個頁的事務(wù)狀態(tài)為TRUE
  • 需要被回收頁是該事務(wù)的影子頁鏈中間的頁P(yáng),則在回收前,需要將P的前一個頁P(yáng)1的狀態(tài)置為TRUE,這樣回收P后,會出現(xiàn)兩條影子頁鏈,此時視這兩條鏈屬于兩個事務(wù),保證這兩個事務(wù)的影子頁鏈中都至少有一個頁的事務(wù)狀態(tài)為TRUE。

Recovery

通過掃描全部的頁,根據(jù)頁的 元數(shù)據(jù),可以檢測到事務(wù)是否提交、哪些頁屬于某一個影子頁鏈(屬于某一個事務(wù))、哪些頁是事務(wù)的最后一個頁。根據(jù)這些信息,做事務(wù)的恢復(fù)。

由于影子頁鏈采用的是物理頁地址的鏈接指針,垃圾回收會導(dǎo)致一個事務(wù)的影子頁鏈斷裂成兩個或多個子鏈。事務(wù)提交的時候這多個子鏈的最后一個頁的事務(wù)狀態(tài)標(biāo)志都會被置TRUE,若是此時系統(tǒng)崩潰,會造成事務(wù)狀態(tài)不一致,同原屬于一個事務(wù)的子鏈有部分表現(xiàn)為事務(wù)已提交,有部分表現(xiàn)為未提交,此時需要恢復(fù)程序做相應(yīng)的針對處理。一旦檢測到上述情況(同一事務(wù)ID存在多個影子頁鏈,且提交屬性不同),判定此事務(wù)未提交(聯(lián)系子鏈產(chǎn)生的規(guī)則,若事務(wù)提交,則影子頁子鏈必定都是表現(xiàn)為已提交)。

3.2 Abord-Based Flag Commit

實(shí)際中,事務(wù)提交比率高于中止率,故在影子頁中維護(hù)提交標(biāo)志需要過多開銷,若改用中止標(biāo)志,則會減少開銷。這就是AFC協(xié)議。兩種協(xié)議互相彌補(bǔ)根據(jù)具體的事務(wù)中止率選用。

AFC協(xié)議中,當(dāng)且僅當(dāng)所有影子頁狀態(tài)標(biāo)志為TRUE時,事務(wù)狀態(tài)判定為已提交。(即狀態(tài)標(biāo)志意味著“未中止”,一旦出現(xiàn)一個頁的“未中止標(biāo)志”值為FALSE,則該事務(wù)狀態(tài)未終止。注:此處標(biāo)志意義不能定義為“已提交標(biāo)志”,“已提交”的TRUE或FALSE狀態(tài)不等同于“未中止”的TRUE和FALSE狀態(tài))

與CFC不同,AFC協(xié)議中,事務(wù)狀態(tài)通過對影子頁鏈的第一個頁的狀態(tài)來決定,初始為FALSE,表示中止,一旦提交,首頁狀態(tài)改為TRUE,則沒有一個頁為FALSE(除了首頁,所有頁狀態(tài)初始化為TRUE),表示此事務(wù)已提交。且即使垃圾回收將該鏈分?jǐn)酁槎鄠€部分,依然保持該狀態(tài)。

在事務(wù)恢復(fù)時,CFC比AFC具有更好性能,取決于判定事務(wù)狀態(tài)的方式不同。CFC不完全遍歷影子頁鏈,一旦出現(xiàn)TRUE表示該事務(wù)已提交。而AFC需要完全遍歷影子頁鏈,直到所有頁標(biāo)志都是TRUE(“未中止”標(biāo)志)才判定該事務(wù)為已提交。

3.3 A Discussion Of CFC and AFC

  • 通過公式分析AFC&CFC的IO開銷:與abort ratio有關(guān)。
  • 兩者的其他兩個區(qū)別:1)標(biāo)志位,AFC需要兩位標(biāo)志狀態(tài),空間開銷更大。2)AFC維護(hù)影子頁鏈?zhǔn)祝聞?wù)狀態(tài)改變時對首頁的修改不可避免,而CFC維護(hù)影子頁鏈尾,事務(wù)狀態(tài)改變時,最后一頁可能存在與main memory buffer中,故可節(jié)省一次重編程改寫標(biāo)志操作。

3.4 Block-Based Flag Technique

基于塊的標(biāo)志技術(shù)的提出是為了在特定情況下節(jié)省頁的重編程操作。通常情況下垃圾回收時需要對相應(yīng)的頁的狀態(tài)標(biāo)志做修改,需要在該頁上重新編程。但是當(dāng)需要被重編程的這個頁正好處在當(dāng)前需要被回收的塊上時,可以采用本節(jié)提出的基于塊的標(biāo)志技術(shù),節(jié)省頁的重編程操作,直接在新塊上修改標(biāo)志。

4. Advanced Flagcommit Protocols

擴(kuò)展Flagcommit協(xié)議,以支持采用no-force策略(事務(wù)可隨時提交,更多的committed事務(wù))的buffer管理,以及高并發(fā)控制。

4.1 Supporting No-Force Buffer Management

No-Force策略下,事務(wù)提交時,沒必要立即將buffer中的影子頁flush到storage中,因?yàn)镹o-Force策略允許任意commit,若立即flush,會造成寫入阻塞,降低事務(wù)響應(yīng)時間和系統(tǒng)吞吐量。(風(fēng)險是:此時系統(tǒng)奔潰,無法重做已提交的事務(wù),應(yīng)該committed page沒有被持久化到storage中)

為解決上述問題,可以采用將flagcommit協(xié)議聯(lián)合重做日志機(jī)制(redo logging scheme)。

工作流程:

  • 數(shù)據(jù)更新前,產(chǎn)生一個redo log record并存入log buffer中。log中保存事務(wù)ID、頁ID、log記錄ID、操作碼(更新、刪除、插入)、操作數(shù)據(jù)Data、本事務(wù)的前一個log記錄的指針PrevLN。
  • 當(dāng)影子頁從memory持久化到flash disk時,其對應(yīng)的log record被移除。
  • 當(dāng)事務(wù)提交時,若該事務(wù)更新的pages還只是緩存在memory中,那么追加一條commit log record到log buffer中,然后將log buffer內(nèi)容持久化到flash disk中。
  • 事務(wù)中止時,回滾memory中被它更新的頁,同時移除log record

4.2 Supporting Record-Level Concurrency Control

。。。。。。

4.3 Putting All Together

4.1與4.2的方案的結(jié)合

更新算法、中止算法、提交算法、垃圾回收、事務(wù)恢復(fù)(恢復(fù)算法)

。。。。。。

5. Performance Evaluation

基于TPC-C標(biāo)準(zhǔn)對flagcommit協(xié)議做性能測試,對比cyclic commit協(xié)議和WAL-Based commit協(xié)議。

5.1 Experiment Setup

  • 實(shí)驗(yàn)標(biāo)準(zhǔn):TPC-C
  • 實(shí)驗(yàn)平臺:windows xp + intel Quad CPU + SSD simulator + ...
  • 實(shí)驗(yàn)對象:CFC\AFC(with block-based flag technique and their extensions)、SCC\BPCC(cyclic commit protocol)、WAL-based commit protocol
  • 測量數(shù)據(jù):throughtput、transaction execution time、commit response time、recovery cost、garbage collection overhead
  • 實(shí)驗(yàn)時常:30m預(yù)熱模擬器+4h實(shí)際評估時間

5.2 Comparison with Cyclic Commit Protocols

CFC & AFC VS SCC & BPCC :相同環(huán)境設(shè)置(采用force緩沖管理及頁級的并發(fā)控制)

  1. 相同中止率(低中止率,通常情況下),對比4種協(xié)議。
    • 事務(wù)吞吐率:AFC>CFC >> BPCC>SCC
    • 事務(wù)執(zhí)行時間:AFC<CFC << BPCC<SCC,執(zhí)行時間越短,造成的事務(wù)阻塞可能性越小,事務(wù)通過率越高。
    • 垃圾回收開銷:AFC<CFC << BPCC<SCC
    • 恢復(fù)時間:CFC ≈ BPCC ≈ SCC << AFC,AFC需要訪問遍歷每一個標(biāo)志確定該頁的狀態(tài),而CFC僅需判斷頭也是否是TRUE標(biāo)志
  2. 不同中止率對吞吐率和平均GC時間對比。
    • 吞吐率:CFC\AFC在不同中止率下吞吐量都大于BPCC\SCC
    • 平均GC時間:AFC\CFC明顯小于BPCC\SCC,且對中止率不敏感
  3. 內(nèi)存消耗:CFC ≈ AFC ≈ SCC << BPCC

5.3 Evaluation of Advanced flagcommit Protocols

CFC_ex & AFC_ex VS WAL-based commit protocol :相同環(huán)境設(shè)置(采用no-force緩沖管理及記錄級的并發(fā)控制)

  1. 部分編程等級(可同時通過編程方式修改page的狀態(tài)標(biāo)志的數(shù)量)的影響:部分編程等級造成同一時間更新的頁更多,因此,可處理的事務(wù)更多,因沖突引起的事務(wù)重新開始更少。但超過2或3就會引起吞吐量下降。
  2. 與WAL-based commit protocol對比:
    • 吞吐量
    • 事務(wù)提交響應(yīng)時間
    • 存儲空間消耗
    • 垃圾回收時間開銷
  3. 事務(wù)大小(平均一個事務(wù)寫入的頁數(shù)量)的影響:
    • 吞吐量
    • GC時間
  4. 緩沖池大小的影響:
    • 吞吐量
    • GC時間

6. Related Work

閃存方面數(shù)據(jù)訪問技術(shù)的介紹。

結(jié)論:在閃存事務(wù)方面的研究較少,本文的研究在基于閃存的DBMSs的事務(wù)恢復(fù)方面具有填補(bǔ)空白的作用。

7. Conclusions And Future Work

為基于閃存的DBMS提出兩種新穎的flagcommit協(xié)議,CFC&AFC,充分利用閃存的快速隨機(jī)訪問、異地更新、頁元數(shù)據(jù)區(qū)、部分可編程的特性。通過使用影子頁的提交標(biāo)志保證了事務(wù)的原子性和持久性。且CFC致力于快速恢復(fù),AFC側(cè)重與更高的事務(wù)性能。并對兩種協(xié)議做了全面的評估測試。

進(jìn)一步工作:1)擴(kuò)展該flagcommit到MLC及其他的非易失性存儲器中。需要克服如MLC不支持部分編程能力等問題。2)對flagcommit協(xié)議做進(jìn)一步優(yōu)化,以減少額外開銷。3)在真正的閃存中具體實(shí)現(xiàn)該協(xié)議。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,030評論 6 531
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 98,310評論 3 415
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 175,951評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經(jīng)常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,796評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當(dāng)我...
    茶點(diǎn)故事閱讀 71,566評論 6 407
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 55,055評論 1 322
  • 那天,我揣著相機(jī)與錄音,去河邊找鬼。 笑死,一個胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,142評論 3 440
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 42,303評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 48,799評論 1 333
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 40,683評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 42,899評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,409評論 5 358
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 44,135評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,520評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,757評論 1 282
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,528評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 47,844評論 2 372

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