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

關(guān)鍵詞：內(nèi)存數(shù)據(jù)庫;內(nèi)存數(shù)據(jù)管理;列式存儲(chǔ)

中圖分類號(hào)：TP311? 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：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? 引? 言

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

1? 現(xiàn)代企業(yè)計(jì)算的新需求

傳統(tǒng)OLTP系統(tǒng)是數(shù)據(jù)積累和企業(yè)電子化的基礎(chǔ)。隨著時(shí)間的推移，數(shù)據(jù)變得越來越大，對(duì)于現(xiàn)代企業(yè)來說如何有效的利用他們變成了新的挑戰(zhàn)。需求則從“積累數(shù)據(jù)”變?yōu)椤皵?shù)據(jù)導(dǎo)向”。傳統(tǒng)數(shù)據(jù)庫雖然在性能上一直在努力的追趕，但現(xiàn)代企業(yè)更需要?jiǎng)?chuàng)新性產(chǎn)品在原理和架構(gòu)上重構(gòu)。從而對(duì)現(xiàn)有的數(shù)據(jù)庫提出二大需求：

（1）整合：將不同數(shù)據(jù)源的數(shù)據(jù)整合到單一的數(shù)據(jù)庫管理系統(tǒng)中。

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

SanssouciDB是具有統(tǒng)一分析和事務(wù)處理的原型數(shù)據(jù)庫系統(tǒng)。接下來我將逐一介紹其內(nèi)存數(shù)據(jù)管理，內(nèi)存中的數(shù)據(jù)布局，日志機(jī)制以及基于內(nèi)存數(shù)據(jù)庫的應(yīng)用開發(fā)最佳實(shí)踐。

2? 內(nèi)存數(shù)據(jù)管理

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

2.1? 字典編碼

主要作用是通過長(zhǎng)字節(jié)的值用簡(jiǎn)短的整數(shù)值來進(jìn)行表示。一個(gè)列被拆分為字典和屬性向量，如圖1所示。

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

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

2.2? 差分緩沖區(qū)和在線合并

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

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

在差異緩存實(shí)現(xiàn)中，首先，我們需要保持一個(gè)列表中所有出現(xiàn)的數(shù)值和CSB+樹，用于查詢唯一值。而唯一值并不是按照特定順序排序，因?yàn)樗窃趬嚎s的主分區(qū)中存儲(chǔ);CSB+樹可以定義屬性的排序準(zhǔn)則，以執(zhí)行在屬性上的快速搜索。但是需要額外的空間用于存儲(chǔ)樹結(jié)構(gòu)。由于讀性能是企業(yè)應(yīng)用的關(guān)鍵KPI，我們要確保差異緩存的大小始終保持盡可能的小。為此，SanssouciDB使用在線重組過程，周期性的將差異緩存中的數(shù)據(jù)合并到壓縮的主存儲(chǔ)區(qū)，從而形成一個(gè)新的壓縮分區(qū)，既合并處理。

合并處理有二個(gè)顯而易見的好處。首先，所有差異緩存中未被壓縮的數(shù)據(jù)被合并到主存儲(chǔ)并壓縮，可以較少內(nèi)存的消耗。其次，由于讀優(yōu)化的主存儲(chǔ)中字典是排序的，因此合并二個(gè)數(shù)據(jù)結(jié)構(gòu)可以提高整體的讀性能。在企業(yè)應(yīng)用中，合并處理有很多的挑戰(zhàn)，可以歸結(jié)為以下3點(diǎn)：

（1）異步執(zhí)行。

（2）降低對(duì)于其它操作的影響。

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

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

合并的過程由三個(gè)階段組成：準(zhǔn)備合并，屬性合并，提交合并，如表1所示。

3? 內(nèi)存中的數(shù)據(jù)布局

關(guān)系型數(shù)據(jù)庫的表是二維的，但主存是一維的。內(nèi)存地址從0呈線性增長(zhǎng)。傳統(tǒng)的數(shù)據(jù)庫在內(nèi)存中用行式來解決。在SanssouciDB中，我們有行式、列式、混合布局。

3.1? 步幅

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

3.2? 行式布局和列式布局

假設(shè)有如表2所示的一張數(shù)據(jù)表。

對(duì)應(yīng)的行式布局和列式布局如表3所示。

3.3? 列式的優(yōu)點(diǎn)

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

3.4? 混合布局

混合布局結(jié)合了二者的優(yōu)點(diǎn)，屬性將通過列式存儲(chǔ)和行式布局相結(jié)合來存儲(chǔ)。優(yōu)化組合依賴于現(xiàn)實(shí)的數(shù)據(jù)庫負(fù)載，可以通過布局算法來進(jìn)行混合。但是混合布局也有新的問題，比如對(duì)于給定的負(fù)載如何找到一個(gè)合適且優(yōu)化的布局，或者如何應(yīng)對(duì)變化的負(fù)載需求。

3.5? 列式和行式掃描的性能對(duì)比

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

在場(chǎng)景1中，要計(jì)算出女性的數(shù)量，需要逐條掃描所有行記錄并讀取性別字段。CPU會(huì)從主存讀取1.6 TB的數(shù)據(jù)，則全表掃描的響應(yīng)時(shí)間為800秒。

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

在場(chǎng)景3中，根據(jù)之前介紹的字典編碼我們知道只需要一個(gè)數(shù)值位就可以實(shí)現(xiàn)對(duì)性別m和f的編碼。所以，CPU從主存中需要讀取的總數(shù)量為80億×1比特=1 GB，單核處理的響應(yīng)時(shí)間為0.5秒。場(chǎng)景3相比前2個(gè)場(chǎng)景有了數(shù)量級(jí)的提升。我們來分析下為什么同樣的查詢?cè)诓煌牟季窒聲?huì)有如此大的區(qū)別。

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

4? SanssouciDB的日志機(jī)制

企業(yè)級(jí)應(yīng)用需要提供持久性的保障，即ACID。同時(shí)系統(tǒng)要具備容錯(cuò)能力和高可用性。對(duì)于災(zāi)難或硬件故障發(fā)生時(shí)，系統(tǒng)可以從故障中恢復(fù)。日志是保障數(shù)據(jù)庫可以恢復(fù)的標(biāo)準(zhǔn)做法。在日志和恢復(fù)機(jī)制的協(xié)作下，數(shù)據(jù)庫可以恢復(fù)到故障前的最后穩(wěn)定狀態(tài)。談到日志，一個(gè)關(guān)鍵的KPI就是性能。這不僅僅是日志的寫入，還包括恢復(fù)時(shí)日志寫回內(nèi)存。

4.1? SanssouciDB日志的架構(gòu)

從圖3中我們可以看到寫道磁盤的日志數(shù)據(jù)由主存儲(chǔ)快照、值日志、字典日志。檢查點(diǎn)（checkpoint）將在數(shù)據(jù)處于一致狀態(tài)的某個(gè)時(shí)間點(diǎn)時(shí)創(chuàng)建數(shù)據(jù)庫快照。由于時(shí)一致狀態(tài)，其中包含了已提交的所有事務(wù)的處理結(jié)果。快照時(shí)讀優(yōu)化的主存儲(chǔ)的拷貝，并會(huì)定期寫到磁盤上。使用檢查點(diǎn)的目的就是為了加快恢復(fù)處理的速度，因?yàn)橹恍枰匮菘煺丈珊蟮娜罩緱l目。由于快照不包括差異緩存區(qū)中的數(shù)據(jù)，這部分?jǐn)?shù)據(jù)修改會(huì)記錄在值日志和字典日志中。一旦事務(wù)提交，首先是字典緩存寫入磁盤。這是為了避免引用這些值標(biāo)識(shí)符的值日志無法恢復(fù)。然后，值日志寫磁盤。最后，提交的事務(wù)日志會(huì)寫入磁盤。值日志和事務(wù)日志存放在同一個(gè)日志緩沖區(qū)。

4.2? SanssouciDB日志架構(gòu)的特性

和傳統(tǒng)數(shù)據(jù)庫不同，有以下特性：

（1）快照的格式：在每個(gè)檢查點(diǎn)，主存儲(chǔ)的快照以二進(jìn)制格式寫入磁盤，后續(xù)恢復(fù)時(shí)可以直接還原，快速且簡(jiǎn)單。

（2）檢查點(diǎn)的觸發(fā)：發(fā)起檢查點(diǎn)的理想時(shí)機(jī)是差異緩存區(qū)相對(duì)主存儲(chǔ)相對(duì)小的時(shí)候，即合并剛剛完成。

（3）存儲(chǔ)元數(shù)據(jù)：為了加速恢復(fù)處理，會(huì)寫入額外的元數(shù)據(jù)。在這些元數(shù)據(jù)可以告知數(shù)據(jù)庫在加載前預(yù)先分配所需的內(nèi)存空間。可以避免耗時(shí)的內(nèi)存空間重新分配和數(shù)據(jù)的移動(dòng)。

（4）值日志和字典日志的拆分：下節(jié)會(huì)詳細(xì)討論。

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

對(duì)于記錄數(shù)據(jù)的更改，最直接的是邏輯日志。日志只是簡(jiǎn)單的在磁盤上寫入SQL語句以及參數(shù)，如圖4所示。

但是，邏輯日志有2個(gè)缺點(diǎn)。第一，日志和恢復(fù)無法并行。第二，邏輯日志直接寫在磁盤上沒有利用SanssouciDB[1]壓縮機(jī)制，數(shù)據(jù)量會(huì)非常大。SanssouciDB[1]使用日志結(jié)構(gòu)，將編碼過的字典數(shù)據(jù)從事務(wù)的上下文分離，稱為字典編碼的日志。這種方法允許并行恢復(fù)，并允許以任意的順序來重演日志項(xiàng)。此外，由于使用了字典壓縮，大大減少了日志占用的存儲(chǔ)空間同時(shí)提高恢復(fù)的速度。

5? 實(shí)際工作中使用HANA內(nèi)存數(shù)據(jù)庫遇到的問題和建議

HANA作為SanssouciDB的商業(yè)版本已經(jīng)被眾多企業(yè)肯定。在本節(jié)，我將分享在實(shí)際工作中使用HANA內(nèi)存數(shù)據(jù)庫所遇到的一些問題和解決方法：

（1）OLAP和OLTP混合使用下遇到的性能問題：曾多次在OLAP/OLTP混合使用的系統(tǒng)中遇到。現(xiàn)象是當(dāng)有高負(fù)載的事務(wù)并疊加大的報(bào)表生成的時(shí)候，數(shù)據(jù)庫性能會(huì)急劇下降，DML的時(shí)間會(huì)成倍增加。經(jīng)過分析，主要原始是高負(fù)載的OLTP事務(wù)會(huì)對(duì)某些表造成很高的負(fù)載并且delta merge store會(huì)急速增加，當(dāng)delta store和main store合并時(shí)再疊加save point就會(huì)造成巨量的IO和CPU的高負(fù)載。針對(duì)此類問題我們可以通過分析數(shù)據(jù)庫的負(fù)載和業(yè)務(wù)人員的溝通可以獲得系統(tǒng)的負(fù)載分布情況，通過調(diào)整業(yè)務(wù)作業(yè)的運(yùn)行時(shí)間盡量避免OLTP和OLAP雙高峰的重疊。同時(shí)，參考HANA維護(hù)手冊(cè)[4]對(duì)相關(guān)大表進(jìn)行分析并和業(yè)務(wù)充分溝通后找出適當(dāng)?shù)淖侄蝸韺?duì)表進(jìn)行分區(qū)用以提升delta merge的效率。

（2）單表?xiàng)l目數(shù)的限制問題：對(duì)于超過10億條記錄的大表，一定要盡快進(jìn)行分析并通過分區(qū)或歸檔數(shù)據(jù)來控制。

（3）謹(jǐn)慎使用select…for update語句：select…for update語句使用不當(dāng)會(huì)造成大量的Block Transaction.我們?cè)赟AP開發(fā)程序的時(shí)候一定要謹(jǐn)慎使用。

（4）在開發(fā)時(shí)要牢記確定最小數(shù)據(jù)集原則避免使用select *語句。

（5）上海交大研發(fā)的NVHT[5]和中科院研發(fā)的HiKV[6]都實(shí)現(xiàn)了利用DRAM和NVM混合存儲(chǔ)并取得優(yōu)異的性能。HANA在最近的版本也已經(jīng)開始部分支持NVM，單限制較多，希望能在不久的將來提供更具性價(jià)比的架構(gòu)和解決方案。

6? 結(jié)? 論

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

參考文獻(xiàn)：

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

[2] 哈索.內(nèi)存數(shù)據(jù)管理教程 [M].程志國(guó)，曹乃剛，譯.北京：清華大學(xué)出版社，2014.

[3] 莊辰弘.基于SAP HANA的內(nèi)存數(shù)據(jù)庫應(yīng)用研究 [D].上海：上海交通大學(xué)，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.