SanssouciDB應用列式存儲和內存數據管理研究

摘? 要：內存數據管理和列式存儲與內存數據庫的結合是解決海量數據實時查詢的可行方案之一，其代表之一是SAP的HANA內存數據庫。SanssouciDB作為HANA的原型內存數據庫是一個很好的研究對象。文章將從內存數據管理、內存中數據存儲布局（包括行式和列式存儲布局）、日志機制等方面研究SanssouciDB如何實現存儲優化，查詢優化。文章還將通過計算來對比列式和行式掃描的性能。最后分享實際工作中使用內存數據庫所遇到的問題。

關鍵詞：內存數據庫;內存數據管理;列式存儲

中圖分類號：TP311? 文獻標識碼：A 文章編號：2096-4706（2021）18-0013-05

Abstract： The combination of memory data management， column storage and memory database is one of the feasible solutions to solve the real-time query of massive data. One of its representatives is SAPs HANA memory database. As the prototype memory database of HANA， SanssouciDB is a good research object. This paper will study how SanssouciDB realizes storage optimization and query optimization from the aspects of in memory data management， in memory data storage layout （including row and column storage layout）， logging mechanism and so on. It will also compare the performance of column and row scanning through calculation. Finally， the problems encountered in using memory database in practical work are shared.

Keywords： memory database; memory data management; column storage

0? 引? 言

傳統數據庫已經無法應付實時分析和海量數據的這對矛盾，尤其是大型制造業。雖然市面上有不少解決方案如ApacheHive，Spark SQL，這類方案依賴底層的分布式系統，其本質不是分布式數據庫，數據分析的能力有限。另一種是基于MPP搭建的數據。SanssouciDB作為內存數據庫在設計階段就已經包括了要通過列式存儲和內存數據管理來加速查詢，目標是能達到企業對于海量數據的實時處理和查詢的需求。

1? 現代企業計算的新需求

傳統OLTP系統是數據積累和企業電子化的基礎。隨著時間的推移，數據變得越來越大，對于現代企業來說如何有效的利用他們變成了新的挑戰。需求則從“積累數據”變為“數據導向”。傳統數據庫雖然在性能上一直在努力的追趕，但現代企業更需要創新性產品在原理和架構上重構。從而對現有的數據庫提出二大需求：

（1）整合：將不同數據源的數據整合到單一的數據庫管理系統中。

（2）快速：越來越多的數據需要實時采集、分析，更快更全面的給予決策者支持。

SanssouciDB是具有統一分析和事務處理的原型數據庫系統。接下來我將逐一介紹其內存數據管理，內存中的數據布局，日志機制以及基于內存數據庫的應用開發最佳實踐。

2? 內存數據管理

對于傳統數據庫，持久化層是硬盤。而內存數據庫則將主存作為持久化層，同時CPU能夠從內存直接讀取數據并計算，大大降低了磁盤訪問量。由于內存不像磁盤可以幾乎無限的擴展，內存大小是新的瓶頸。SanssouciDB[1]所要面對的就是如何更高效的使用內存從而處理更大的數據量。SanssouciDB使用了字典編碼、壓縮、差分緩沖區等。由于內存大小是個繞不來的坎，我們首先可以通過訪問盡量少的列的數據，只有需要的屬性才會被查詢。另一個方法是通過減少表示數據的位數。從而同時減少對內存的消耗和訪問內存的次數。第一個辦法通過列式存儲來解決，下一節我會重點介紹。而另一個則可以通過字典編碼來解決。

2.1? 字典編碼

主要作用是通過長字節的值用簡短的整數值來進行表示。一個列被拆分為字典和屬性向量，如圖1所示。

每一個字典存儲著所有不同的值和他們對應的位置信息。這樣的設計會帶來2個好處。第一，所有操作都是通過屬性向量完成，而屬性向量僅包含整數，CPU最擅長處理數字而非字符。第二，由于企業數據的熵一般比較低，也就是列數據重復度大。在原始列數據中員工B和員工C出現了2次。在ValueID中我們可以看到有2個2和3，從而為壓縮打下了好基礎。舉例，有一張包含80億條記錄的人口表，其中“性別”列只有2個值（m和f），占用1字節。在沒有壓縮前大小80億×1 byte=7.45 GB。壓縮后該列只需要1 bit，大小為80億×1 bit=0.93 GB，字典額外需要2 bytes?？偞笮】s小近8倍。

字典編碼是另外壓縮技術的基礎。對于屬性向量，我們可以使用Prefix encoding、Sparse encoding、Run length encoding、Indirect encoding、Cluster encoding。gzslib202204051047

2.2? 差分緩沖區和在線合并

我們知道列存儲和字典編碼對于DML不是很友好。如插入一個元組，整個表將被強制重組;如果出現一個新的屬性值，那么字典將被重新排序，這將大大影響性能。差異緩存的概念是將數據庫分為主存和差異緩存。所有的DML都將先在差異緩存中進行，最后再合并到主存。由于差異緩存的大小遠遠小于主存，因此對于讀性能產生的影響非常小。執行查詢時，數據再邏輯上被分割為壓縮主存區和差異緩存區，需要獲取二部分的結果后再合并成一個整體結果反饋給用戶。

在差異緩存中，我們始終保留面向列存儲和字典壓縮。目的是提高寫入性能，但是字典沒有排序，并且值存儲依舊按照插入的順序排列，所以在差異緩存中不會觸發重新排序。

在差異緩存實現中，首先，我們需要保持一個列表中所有出現的數值和CSB+樹，用于查詢唯一值。而唯一值并不是按照特定順序排序，因為它是在壓縮的主分區中存儲;CSB+樹可以定義屬性的排序準則，以執行在屬性上的快速搜索。但是需要額外的空間用于存儲樹結構。由于讀性能是企業應用的關鍵KPI，我們要確保差異緩存的大小始終保持盡可能的小。為此，SanssouciDB使用在線重組過程，周期性的將差異緩存中的數據合并到壓縮的主存儲區，從而形成一個新的壓縮分區，既合并處理。

合并處理有二個顯而易見的好處。首先，所有差異緩存中未被壓縮的數據被合并到主存儲并壓縮，可以較少內存的消耗。其次，由于讀優化的主存儲中字典是排序的，因此合并二個數據結構可以提高整體的讀性能。在企業應用中，合并處理有很多的挑戰，可以歸結為以下3點：

（1）異步執行。

（2）降低對于其它操作的影響。

（3）不能妨礙任何OLTP或OLAP的事務。

SanssouciDB[1]實現了異步在線合并，如圖2所示。該模型通過在合并階段引入第二個差異緩存，支持在合并階段也能對數據做修改，但是為了保證數據的一致性，需要在切換數據存儲的開始和結束之間加鎖。例如在合并處理期間，針對有效元組的修改。在合并處理的最后一步，數據庫會保存新主存儲的一份快照，同時也就定義了發生故障時做日志重演的開始結點。

合并的過程由三個階段組成：準備合并，屬性合并，提交合并，如表1所示。

3? 內存中的數據布局

關系型數據庫的表是二維的，但主存是一維的。內存地址從0呈線性增長。傳統的數據庫在內存中用行式來解決。在SanssouciDB中，我們有行式、列式、混合布局。

3.1? 步幅

在介紹數據布局前我想先討論下內存訪問中的步幅。參考《內存數據管理》[2]中8.1.1的步幅實驗，我們可知內存訪問開銷和TLB之間的聯系。內存的訪問開銷步幅正相關。當步幅小于64字節的時候，多個鏈表的元素位于同一個緩存中，所以加載多個元素的開銷是線性的。當大于64字節時，隨著步幅變大，也就意味著數組在內存中跨多頁的概率變大，更多的TLB失效發生。

3.2? 行式布局和列式布局

假設有如表2所示的一張數據表。

對應的行式布局和列式布局如表3所示。

3.3? 列式的優點

使用列式可以利用每列中數據的本地化來采用更適用的壓縮技術。它利用存儲在每列中數據的相似性進行高效壓縮。在《基于SAPHANA的內存數據庫應用研究》[3]中，實驗驗證了列數值的離散程度和壓縮比有強關聯。離散程度越平均，不一樣的數值越少則壓縮比越高。列式布局還可以快速的進行列數據掃描，順序訪問效率非常高，是實現實時在線聚合計算的基礎。

3.4? 混合布局

混合布局結合了二者的優點，屬性將通過列式存儲和行式布局相結合來存儲。優化組合依賴于現實的數據庫負載，可以通過布局算法來進行混合。但是混合布局也有新的問題，比如對于給定的負載如何找到一個合適且優化的布局，或者如何應對變化的負載需求。

3.5? 列式和行式掃描的性能對比

在本節我將通過3個場景來比對列示存儲和行式存儲的性能。假設有數據表，其記錄全世界人的基本信息，包括名字，性別等。共80億條元組，元組大小為200字節，數據表的總容量為80億×200字節=1.6 TB，表的屬性字段都是固定長度，主存讀取的性能為2 MB/毫秒/核，高速緩存行的大小為64字節，掃描操作時只考慮使用單核CPU。通過計算在不同的3個場景下計算該表中所有女性的數量。3個場景分別為行式布局中的全表掃描，行式布局中對選擇的屬性字段進行步長訪問，列式布局中的全列掃描。

在場景1中，要計算出女性的數量，需要逐條掃描所有行記錄并讀取性別字段。CPU會從主存讀取1.6 TB的數據，則全表掃描的響應時間為800秒。

在場景2中，不再是掃描整個表，而是直接訪問需要的那部分字段。CPU每訪問一個元組，都會讀取64字節的數據。因此，在整個掃描過程中，從主存讀取的數據總量為80億×64字節=512 GB，單核處理的響應時間為256秒。上述結果相比場景1有所提升，但是響應時間仍然需要幾分鐘。

在場景3中，根據之前介紹的字典編碼我們知道只需要一個數值位就可以實現對性別m和f的編碼。所以，CPU從主存中需要讀取的總數量為80億×1比特=1 GB，單核處理的響應時間為0.5秒。場景3相比前2個場景有了數量級的提升。我們來分析下為什么同樣的查詢在不同的布局下會有如此大的區別。

當使用列式布局，同一屬性的數據將被存儲在主存中的一塊連續區域。由于是連續存放，可以利用有效壓縮算法來減少主存中的容量，相應地減少主存與CPU之間的傳輸量。綜上所述，即只掃描目標字段和讀取壓縮后的值。從這方面入手可以減少CPU和主存間的傳輸量從而大大降低響應時間。在次基礎上再考慮多核實現并行化的掃描操作，那么我們就可以進一步加速。gzslib202204051047

4? SanssouciDB的日志機制

企業級應用需要提供持久性的保障，即ACID。同時系統要具備容錯能力和高可用性。對于災難或硬件故障發生時，系統可以從故障中恢復。日志是保障數據庫可以恢復的標準做法。在日志和恢復機制的協作下，數據庫可以恢復到故障前的最后穩定狀態。談到日志，一個關鍵的KPI就是性能。這不僅僅是日志的寫入，還包括恢復時日志寫回內存。

4.1? SanssouciDB日志的架構

從圖3中我們可以看到寫道磁盤的日志數據由主存儲快照、值日志、字典日志。檢查點（checkpoint）將在數據處于一致狀態的某個時間點時創建數據庫快照。由于時一致狀態，其中包含了已提交的所有事務的處理結果?？煺諘r讀優化的主存儲的拷貝，并會定期寫到磁盤上。使用檢查點的目的就是為了加快恢復處理的速度，因為只需要重演快照生成后的日志條目。由于快照不包括差異緩存區中的數據，這部分數據修改會記錄在值日志和字典日志中。一旦事務提交，首先是字典緩存寫入磁盤。這是為了避免引用這些值標識符的值日志無法恢復。然后，值日志寫磁盤。最后，提交的事務日志會寫入磁盤。值日志和事務日志存放在同一個日志緩沖區。

4.2? SanssouciDB日志架構的特性

和傳統數據庫不同，有以下特性：

（1）快照的格式：在每個檢查點，主存儲的快照以二進制格式寫入磁盤，后續恢復時可以直接還原，快速且簡單。

（2）檢查點的觸發：發起檢查點的理想時機是差異緩存區相對主存儲相對小的時候，即合并剛剛完成。

（3）存儲元數據：為了加速恢復處理，會寫入額外的元數據。在這些元數據可以告知數據庫在加載前預先分配所需的內存空間?？梢员苊夂臅r的內存空間重新分配和數據的移動。

（4）值日志和字典日志的拆分：下節會詳細討論。

4.3? 邏輯日志與字典編碼日志

對于記錄數據的更改，最直接的是邏輯日志。日志只是簡單的在磁盤上寫入SQL語句以及參數，如圖4所示。

但是，邏輯日志有2個缺點。第一，日志和恢復無法并行。第二，邏輯日志直接寫在磁盤上沒有利用SanssouciDB[1]壓縮機制，數據量會非常大。SanssouciDB[1]使用日志結構，將編碼過的字典數據從事務的上下文分離，稱為字典編碼的日志。這種方法允許并行恢復，并允許以任意的順序來重演日志項。此外，由于使用了字典壓縮，大大減少了日志占用的存儲空間同時提高恢復的速度。

5? 實際工作中使用HANA內存數據庫遇到的問題和建議

HANA作為SanssouciDB的商業版本已經被眾多企業肯定。在本節，我將分享在實際工作中使用HANA內存數據庫所遇到的一些問題和解決方法：

（1）OLAP和OLTP混合使用下遇到的性能問題：曾多次在OLAP/OLTP混合使用的系統中遇到?，F象是當有高負載的事務并疊加大的報表生成的時候，數據庫性能會急劇下降，DML的時間會成倍增加。經過分析，主要原始是高負載的OLTP事務會對某些表造成很高的負載并且delta merge store會急速增加，當delta store和main store合并時再疊加save point就會造成巨量的IO和CPU的高負載。針對此類問題我們可以通過分析數據庫的負載和業務人員的溝通可以獲得系統的負載分布情況，通過調整業務作業的運行時間盡量避免OLTP和OLAP雙高峰的重疊。同時，參考HANA維護手冊[4]對相關大表進行分析并和業務充分溝通后找出適當的字段來對表進行分區用以提升delta merge的效率。

（2）單表條目數的限制問題：對于超過10億條記錄的大表，一定要盡快進行分析并通過分區或歸檔數據來控制。

（3）謹慎使用select…for update語句：select…for update語句使用不當會造成大量的Block Transaction.我們在SAP開發程序的時候一定要謹慎使用。

（4）在開發時要牢記確定最小數據集原則避免使用select *語句。

（5）上海交大研發的NVHT[5]和中科院研發的HiKV[6]都實現了利用DRAM和NVM混合存儲并取得優異的性能。HANA在最近的版本也已經開始部分支持NVM，單限制較多，希望能在不久的將來提供更具性價比的架構和解決方案。

6? 結? 論

綜上所述，SanssouciDB對于推進內存數據庫的發展有著很大的作用，其中內存數據管理、列式存儲功能的實現造就了HANA的成功，也讓我們體驗到了實時分析的魅力。但是內存數據庫也有著明顯的確定，比如嚴重依賴內存容量，仍然需要將數據和日志寫回磁盤。近些年NVM硬件的出現讓我們看到了突破口。相比DRAM，NVM可以方便的提高內存數據庫容量的上限，NVM還可以替代磁盤/SSD作為數據庫的持久化層。

參考文獻：

[1] PLATTNER H. A Course in In-MemoryData Management The Inner Mechanics of In-Memory Databases [M].Berlin：Springer，2013.

[2] 哈索.內存數據管理教程 [M].程志國，曹乃剛，譯.北京：清華大學出版社，2014.

[3] 莊辰弘.基于SAP HANA的內存數據庫應用研究 [D].上海：上海交通大學，2013.

[4] BREMER R，BREDDEMANN L. SAP HANA Administration [M].Germany：Rheinwerk，2015.

[5] ZHOU J，SHEN Y，LI S，et al. NVHT：an efficient key-value storage library for non-volatile memory [C]//BDCAT '16：Proceedings of the 3rd IEEE/ACM International Conference on Big Data Computing，Applications and Technologies.New York：ACM，2016：227-236.

[6] XIA F，JIANG D J，XIONG J，et al. HiKV：a hybrid index key-value store for DRAM-NVM memory systems [C]//USENIX ATC '17：Proceedings of the 2017 USENIX Conference on Usenix Annual Technical Conference.Berkeley：USENIX Association，2017：349-362.