論文地址：https://www.ixueshu.com/document/9cd210e04def3c2b318947a18e7f9386.html
硬件背景：
傳統的HDD盤具有高數據密度，價格低廉，持久化穩定的優點，但也無法擺脫機械盤尋道帶來的開銷，而且順序訪問和隨機訪問的性能差異巨大。
SSD相比HDD來說具備更加好的讀寫性能，其讀寫時延相比HDD來說低3個數量級。但針對DBMS系統來說，SSD也存在三個問題：
- 僅支持面向block的訪問模式
- SSD的NAND只有固定的擦寫次數，存在壽命問題
- SSD的成本過於高昂，每GB的價格是HDD的3-10倍
SSD/HDD的讀寫速度限制了使用它們來存儲log的DBMS系統的性能，主要是因爲DRAM和SSD/HDD存在巨大的隨機與順序訪問延遲差異，以及兩者的數據訪問粒度也存在差異（即粗粒度的面向塊的訪問模式，細粒度的面向字節的訪問模式）。
新生的NVM技術，如PCM，STT-MRAM以及RRAM，提供更快的讀寫訪問速度，且提供細粒度的面向字節的訪問模式。與使用SATA接口的SSD/HDD相比，NVM設備可以插入DIMM插槽，通過PCIE接口進行訪問，爲CPU提供了更高的帶寬和更低的訪問時延。且如下圖所示，NVM設備的順序訪問和隨機訪問的差異相對SSD/HDD來說非常小。
如圖所示，分別是基於WBL和WAL的DBMS的性能統計，由圖可得，WBL在吞吐，故障恢復延遲，以及log存儲空間佔用方面，都遠遠處於優勢，尤其是在DBMS故障恢復時，WBL具有非常快的恢復速度。
提升了DBMS系統事務吞吐大約1.3倍，其故障恢復速度提升了2個數量級，並在同樣的NVM設備上，節省了大約1.5倍的空間。
WBL 流程
WBL機制完美利用了NVM設備的高讀寫性能，按字節存儲等優點，WBL的特點是在數據成功flush到持久化存儲設備之後，才記錄一條log。相比於WAL，WBL具備更好的寫入性能和更快的故障恢復速度，主要原因有：
- NVM設備的寫入帶寬相比SSD/HDD來說高出了數量級的差距
- 相比SDD/HDD來說，NVM設備的隨機訪問能力和順序訪問能力間的差距很小
- NVM設備提供了按字節存儲的特性，這使得CPU可以直接訪問NVM設備中的字節，從而不需要將數據組織成page或通過IO系統訪問。
Runtime Operation
WBL相比WAL來說有很多方面的不同之處，最主要的是WBL不會在log中記錄數據庫元組的修改信息，因爲在記錄log的時候，事務已經完成了提交，且對數據庫的更改都已經全部同步到了持久化存儲設備中。當一個事務去修改數據庫中的值時，DBMS會將其寫入到一個dirty tuple table (DTT) 中去追蹤這個事務的執行過程，每一條在DTT中的記錄都包含了事務ID，類型等數據，類似於WAL中log中記錄的數據。對於Insert和Delete操作，DTT中的記錄會包含插入和刪除的tuple的位置，針對Update操作，需要包含新值和舊值的位置，但DTT中的記錄從來不會包含after-images的tuple。在事務提交時，會將DTT中的數據進行清空，DTT中的數據都在內存中，從來都不會寫入到NVM或者其他持久化存儲設備中。
在事務執行過程中，WBL中主要完成了：
- 執行事務操作
- 將對數據庫的修改寫入到內存中
- 將數據修改記錄寫入到DTT中，且一定不包含after-images的tuple
Commit Protocol
WBL放寬了數據寫入到持久化存儲設備中的順序，即先將修改後的數據寫入到持久化存儲，再記錄log的模式，會使得WBL的事務提交和故障恢復變得很複雜。DBMS在故障恢復過程中，必須要確定在故障的那一刻，哪些事務的數據是需要redo操作來進行回放的，而哪些數據又是需要undo操作來進行丟棄的。而在WBL的模式下，很可能會因爲數據刷寫到了持久化存儲設備，但還未有對應的log來記錄這一操作而導致數據的回放無法正確的辨識這些修改，故而在回放過程中可能需要掃描整個數據庫來鑑別哪些數據是正確的，這對於DBMS的故障恢復來說是不可承受的。
即WBL場景下，Log的作用只剩下undo操作，redo操作的功能由NVM實現了。
在事務Commit階段，爲了解決如何通過log去記錄從DRAM中將事務對數據庫的修改flush到持久化存儲設備的過程，設計了新的WBL的log entry結構，並且通過兩個事務提交的時間戳來記錄對數據修改的tuple的可見性，log entry結構如下圖所示：
LSN：唯一的日誌序列號
Log Record Type：當前log的操作類型（Insert，Update或者Delete）
Persisted Commit Timestamp(Cp)：最後一條事務提交的時間戳
Dirty Commit Timestamp(Cd)：DBMS分配給當次事務提交時，所產生的最大事務提交時間戳
在WBL中，也是採用group commit的模式來flush數據，在當前事務提交時，實際可能已經有很多個事務的數據已經flush到持久化存儲設備中了，因此選取最後一個提交事務的提交時間戳作爲Cp，表示在Cp這個時間戳以前的數據都是有效修改，都已經持久化在了存儲設備中。同時，DBMS會分配出一個在此次事務提交完成之前的一個時間戳作爲Cd，DBMS保證了當前所有flush到持久化存儲設備中的數據所對應的事務的提交時間戳都小於Cd。即當前早於Cp的數據是已經確定可見了，故障恢復時不需要清理這些數據，處於(Cp,Cd)之間的數據是不可見的，故障恢復時需要將這些數據進行清理，且DBMS保證在此次事務提交完成之前，不可能產生比Cd還大的事務提交時間戳。只有事務提交時間戳早於Cp的事務纔會通知應用程序爲事務提交完成，而處於(Cp,Cd)之間的的事務提交，還需要等待下一輪的group commit來完成。
事務在commit階段的過程：
- DBMS檢查DTT中的條目，確定事務所關聯的所有修改後的髒tuple
- 爲本次group commit計算Cp和Cd
- 執行sync操作將DRAM中修改之後的髒數據塊flush到持久化存儲設備中
- 執行sync操作將包含Cp和Cd的log flush到NVM設備中
- 通知worker線程進行group commit
- 通知應用程序commit完成
在事務group commit過程中，可能會存在有些長事務，即可能在本次group commit完成時，還會有事務沒有完成提交，這些未完成提交事務的時間戳會被記錄在下一輪group commit的log中，私以爲將這種事務的時間戳稱之爲Cl，則實際log中需要記錄的事務提交窗口爲(Cl,(Cp,Cd))，直到這個長事務提交完成後，纔將Cl不記錄在下一輪的group commit的log中。
在事務group commit過程中，可能會出現一個事務中修改的數據處於兩個不同的Table中，即刷寫到持久化存儲設備中的tuple的位置實際上並不連續，這樣一來如果使用NVM設備作爲持久化存儲設備，可以充分利用NVM設備的高性能隨機訪問能力。
對於那些未完成提交的事務，即中止的事務，會依據在DRAM中的DTT中記錄的信息，完成這些事務對數據修改的撤銷操作。
如上圖所示，WBL的寫入模式爲先寫入DRAM中的Table Heap，在其中完成對數據庫數據的修改和索引信息，在事務提交時，DBMS會將內存中的所有此事務關聯的數據全部flush到持久化存儲設備中，最後在NVM設備中記錄log。
Recovery Protocol
在WBL中，故障恢復過程只需要Undo操作。作者設計了commit timestamp gap的一種數據結構來控制在故障恢復階段的數據處理，即在上文中所提到的(Cp,Cd)。在恢復過程中，針對事務提交時間戳位於(Cp,Cd)中的數據，都會視爲事務未提交完成，即對這些數據進行清理，DBMS有專門的垃圾收集器線程去掃描處於(Cp,Cd)的tuple的數據修改，並將其撤銷，當垃圾收集器完成對所有處於(Cp,Cd)的tuple數據的修改撤銷，頁會把這條log也做清除處理。
使用WBL機制時，不需要定期構建類似於WAL的Checkpoint機制來加快故障恢復速度，因爲每個WBL log中已經包含了所有故障恢復所需要的數據，即commit timestamp gap (Cp,Cd)，和長時間未提交完成的事務提交時間戳Cl，即提交窗口(Cl,(Cp,Cd))，在故障恢復過程中，只需要對處於這個間隔的數據進行undo操作即可，並且在每次log最新紀錄時，既可以刪除以前較老的log，以保證log實際的大小永遠都很小，這極大的加快了故障恢復的速度。