SAP HANA 和非易失性存儲

一種新硬件產品的推廣，必然需要有配套的軟件產品來助陣。SAP HANA 作為一款著名的企 業級內存數據庫產品，正是持久化內存最合適的場景之一。所以，SAP 和 Intel 二者很早 就開始相關產品的研發合作，這是一件再自然不過的事情了。SAP HANA 是市場上第一個針 對 DCPMM（即Optane數據中心持久化內存）優化過的主流數據庫產品，SAP HANA 2.0 SPS 03 就已經支持 DCPMM 了1。

SAP HANA 的架構

SAP HANA 本質上是一個內存數據庫，它也是最早提出 HTAP 的企業級數據庫產品。因此， SAP HANA 給人的第一印象就是需要很多的內存，例如好幾個 TiB。因此，云廠商的超大內 存規格就是為了 SAP HANA 這樣的產品準備的。這也是為什么 DCPMM 作為一種新介質，很 早就吸引了 SAP HANA 的研發投入。

內存數據庫的操作是以內存為中心的，而不是像磁盤數據庫那樣將內存作為磁盤的緩存。為 了保證數據的持久化，它仍然要依賴 WAL 機制先寫日志，也需要依賴檢查點等機制將數據 持久化。磁盤數據庫遇到重啟的時候，需要執行崩潰恢復過程，才能提供服務；內存數據庫 也不例外，不過它的操作以內存為中心，還需要將大量數據加載到內存才可以工作。加速重 啟的恢復過程也是企業級數據庫一個很重要的優化。從內存和外存的角度看，SAP HANA 的 宏觀結構如下2：

為了在 OLAP 和 OLTP 類訪問中獲得平衡，SAP HANA 在列存和壓縮的基礎上，將每列數據 分為兩個部分：Main 和 Delta。前者主要是只讀的，為 OLAP 類訪問優化；后者為寫服務， 為 OLTP 類訪問優化。為了支持并發訪問，這兩部分都實現了 MVCC 。大致的架構如下：

實際的系統結構遠比這個結構圖要復雜，畢竟 SAP HANA 是一個完備的產品，也實現了很多 內存數據庫、列存引擎的經典特性。更多的資料請移步 SAP HANA 官網3。

SAP HANA 的優化思路

在其他的文章中我已經分析過 DCPMM 之類介質的特點，例如帶寬要稍遜于 DRAM，讀寫速度 不對稱等。SAP HANA 也對介質的特點做了仔細的考量，結合 Main 內存的訪問特點（例如 容量大、讀多寫少等），很自然的，先把 DCPMM 當做字節尋址的持久化介質用于 Main 內 存的優化。為了做到務實的架構設計，SAP 不可能對 HANA 大動干戈，為了 DCPMM 做全面 的改造，畢竟系統的備份、恢復、復制等都存在依賴。這也是寫 PAPER，做原型和在產品上 做改進的重要區別。

SAP HANA 的優化結果

原型系統2中討論較多場景下的性能改進，例如簡單的 INSERT、SELECT、類 TPC-H 查詢、系統恢復時間等。但是需要注意的是，數據都是用 DRAM 附加延遲等模擬出來的， 不能代表實際的系統數據。產品1的性能給出的主要是系統恢復時間的減少， 以及 DCPMM 帶來的相對 DRAM 的增加。

從圖中可以看出，系統啟動的時間從 50 分鐘下降到了 4 分鐘，可以大大減少系統的停機 時間。

SAP HANA 的啟示

一種新硬件產品的推廣從來都不是凌空出世的，它需要很多年研究和開發的積累。與此同時， 硬件還需要操作系統等基礎軟件環境的支撐，才可能被更上層的應用軟件所用。此外，硬件 要被廣泛采用，必須要獲得 Killer Application 的支持。DCPMM 之類的新硬件，因為它獨 特的特性，存在很多種用法。至于實際的系統中應該采用哪種用法，就是應用軟件各顯神通 之處了。

SAP HANA 產品中對新存儲介質的引入必然是慎重的。首先是企業的預研部門對新介質的用 法做出評估，并在以原型等形式予以實現和驗證，其次才是真正的在產品中引入。最后，改 進后的產品要真正發布給客戶并在實際系統中應用。

Footnotes

1 https://blogs.saphana.com/2018/11/29/sap-hana-persistent-memory/

2 http://www.vldb.org/pvldb/vol10/p1754-andrei.pdf

3 https://www.sap.com/products/hana.html