1.寫在前面
本博客的內容是前兩篇介紹SCM內存基礎與應用的後續，主要結合兩篇論文來介紹利用SCM（Storage-Class Memory， 又稱NVM）重新實現DBMS（DataBase Management System），並針對SCM的大容量、持久存儲、可字節尋址等特性做相應的改良與優化，提升數據庫系統的整體性能。
回顧NVM的特性，如下圖所示：
關於數據庫系統的基礎部分學習，鏈接如下:
DBMS Tutorial
兩篇論文均取自CMU計算機系Joy Arulraj博士與Intel合作的數據庫系統設計項目，閱讀鏈接如下：
A Prolegomenon on OLTP Database Systems for Non-Volatile Memory, VLDB,2014
Let’s Talk About Storage & Recovery Methods for Non-Volatile Memory Database Systems, SIGMOD, 2015
2.針對DBMS的兩種NVM存儲架構嘗試
A Prolegomenon on OLTP Database Systems for Non-Volatile Memory這篇論文介紹的就是針對現有的面向內存數據庫系統與面向磁盤的數據庫系統，將其重現在包含NVM的存儲架構中。這兩種存儲架構分別是：僅有NVM（NVM-Only，即使用NVM替換掉DRAM和DISK），NVM/DRAM混合內存結構（NVM作爲與DRAM平級的內存結構，位於DISK上層作爲緩存空間）。
由於現有NVM在實際機器上的實現還乏善可陳，因此大部分研究採用模擬器（emulator）來進行實驗和性能測試。所謂模擬器模擬NVM，實際上是將DRAM切分成DRAM部分和SCM部分，然後對SCM區域配置讀/寫延遲和帶寬限制。由於SCM與DRAM對於CPU都是直接存取的，所以其他方面不需要再特殊配置。
實驗者在描述NVM硬件模擬器時提到，在NVM區域上實現了兩種接口，NUMA（非一致內存訪問）接口和PMFS文件接口。這些接口的作用是爲了能像在真正的機器上那樣訪問DRAM和SCM存儲空間。
在NVM-ONLY架構中，DBMS僅僅使用NVM來作爲存儲空間。
傳統的面向disk的DBMS利用physical logging機制來維持數據一致性並方便故障恢復,而面向內存的DBMS則使用logical logging機制。那麼，physical logging與logical logging有什麼區別呢？
簡單來說，physical logging在磁盤中記錄的是更新後的數據本身，而logical logging在磁盤中寫入的是每一個transaction執行時的動作記錄。也就是說，在故障恢復時（比如斷電重啓），physical logging需要redo the effect of a transaction，而logical logging需要redo the transaction。兩者各有代價，logical logging保證了在記錄時更加高效迅速，但恢復數據時需要更漫長的過程。
在NVM+DRAM混合架構中，一個基本假定是DRAM中放不下全部的數據（大數據時代數據集過大，而如果做分佈式計算機器間的流量開銷又太過嚴重），一個自然而然的問題是如何將數據切分，以能夠合適地分別放入DRAM和NVM中，一種容易想到的解決方案是，爲了最大限度的利用DRAM的存取速度優勢，將hot data存入DRAM中，將cold data存入NVM中。
研究者設計的兩種方案結構圖對比如下圖所示：
在所有面向內存的數據庫系統中，研究者選用H-Store作爲測試藍本；
在所有面向磁盤的數據庫系統中，研究者選用SQL作爲測試樣品。
這個研究的意義在於，將傳統的數據庫系統部署在包含NVM的兩種未來可能會大規模應用的內存架構上，可以便於討論和啓發新型的數據庫系統設計，實現大數據存儲與操作的全新變革。
研究者利用經典的YCSB和TPC-C作爲benchmark來測試兩種架構下面向內存及面向磁盤的數據庫系統的性能表現，得到測試結果如下所示：
直觀上可以看到，面向內存的數據庫系統無論是部署在NVM-Only架構還是NVM+DRAM架構上，吞吐量性能都好於面向磁盤的操作系統。
但是值得注意和警惕的是，隨着Workload skew1的降低，面向內存的數據庫系統與面向磁盤的操作系統開始聚攏，使得兩者吞吐量性能相差無幾。
這是因爲在High skew情況下，disk-oriented數據庫系統會有鎖衝突的問題，而low skew情況下，memory-oriented數據庫系統局部訪問優勢會下降。
經過研究與測試，研究者們得出結論：memory-oriented系統更適合利用NVM的優勢，表現比disk-oriented系統要更好。但是兩種系統因爲workload skew導致性能收攏的問題存在，所以都不是非常理想。因此，一個新型的數據庫管理系統成爲了發展NVM DBMS的必由之路。它應該是一個輕型的系統，且充分融合面向內存操作系統與面向磁盤操作系統兩者的優勢。
而這，也是在下目前思考及探索的一個頗具挑戰性的問題。
3.基於NVM的三種數據庫存儲引擎的討論
Let’s Talk About Storage & Recovery Methods for Non-Volatile Memory Database Systems這篇文章承襲自上一篇文章的研究，繼續討論了在NVM-Only的存儲架構下，採用不同的數據存儲與更新方式，性能與數據恢復方面有哪些不同，各自有何優劣。
這三種（所謂的存儲引擎，可以理解爲是存儲更新機制）分別是：
1、原地更新（in-place update）;
2、寫時拷貝更新（Copy-On-Write update）；
3、基於Log的更新（Log-Structured update）。
研究者提出，大容量DRAM價格昂貴，耗能嚴重；DISK存取速度緩慢，IO是性能瓶頸。兩者在處理大規模數據庫數據時都存在短板，因此引入NVM是具有潛力和前途的一項工作（這基本重複了上一部分內容的motivation）。
然而，直接將原有數據庫系統的結構和組件照搬到NVM存儲上是不合適的。對於disk-oriented DBMS而言，它們是假定存取用的是塊存儲持久設備，隨機讀取性能極差，這一假定對NVM當然是不適用的，也就不需要加入in-memory cache；對於memory-oriented DBMS而言，它們用許多機制和部件（具體研究者沒有明說，而我的知識體系尚未有能力概括這些機制）來克服DRAM的易失性，這些結構對於NVM也是多餘的。
所以，針對原有的三種存儲更新機制，對於NVM架設，要進行一番變通，以減少開銷，提高性能。
我們可以看看研究者做出的工作和努力。
原有的三種存儲引擎結構如下圖所示（原型分別是voltDB, R system, levelDB）：
針對NVM進行優化更新後的存儲引擎結構如下所示：
這裏如果對改進的原理進行展開描述，將佔用太多篇幅，且容易喪失對總體的把握（更主要地嗎，是我沒有太多時間）。
簡單歸納起來，就是：
第一，利用可字節尋址特性，減少Logging開銷（比如存指針不存數據，去掉Snapshot2機制）;
第二，利用NVM持久性，建立持久數據結構（比如persistent B+ Tree）。
在性能測試方面，結果如下圖所示：
針對上圖，有很多可以提出的有趣的問題，比如：
1、爲什麼Read-Only workload可以使得三種引擎達到最高的吞吐量？
2、爲什麼in-place update機制在三種更新機制中具有最好的表現？
3、爲什麼隨着skew的提升，三種引擎的性能表現會更好？
4、爲什麼NVM InP性能與InP相比，時而相同時而不同？
5、爲什麼隨着NVM模擬延遲增加到8倍，吞吐量的下降不是到1/8而是隻到1/3？
這些問題都是可以從原文中得到答案的，相信聰明的讀者也能憑藉自己的智慧推理出來，在此我就不贅言了。
在數據恢復方面，六種引擎的表現如下所示：
可以看到，原來的三種引擎，隨着需要恢復的transaction數目的增加，恢復時間也是呈線性增長的；而NVM引擎，則是基本不隨時間變化。
理由很簡單，NVM引擎的logging機制只有undo操作，沒有redo操作。因爲已提交的transation對數據的修改是具有持久性的（因爲NVM的持久性），因此沒有redo的必要，恢復時只需undo尚未提交的transaction來保證數據一致性就可以了。而原來的引擎建立在利用易失內存DRAM來進行更新操作這一基礎上，所以在數據恢復時既要undo沒有提交的transaction，也要redo提交過的所有transaction，因此是稱線性時間增長的。