內(nèi)存數(shù)據(jù)庫實現(xiàn)原理探討

黃偉梅

摘要：該文對內(nèi)存數(shù)據(jù)庫的實現(xiàn)原理進(jìn)行探討，以實際數(shù)據(jù)為樣本進(jìn)行統(tǒng)計分析，對數(shù)據(jù)存儲結(jié)構(gòu)、數(shù)據(jù)字典、數(shù)據(jù)壓縮、消除冗余等技術(shù)進(jìn)行了探討。同時比對了傳統(tǒng)數(shù)據(jù)庫和內(nèi)存數(shù)據(jù)庫之間的優(yōu)勢和劣勢。

關(guān)鍵詞：內(nèi)存數(shù)據(jù)庫；列式存儲；數(shù)據(jù)字典；數(shù)據(jù)壓縮；消除冗余

中圖分類號：TP391 文獻(xiàn)標(biāo)識碼：A 文章編號：1009-3044（2018）15-0010-04

1 引言

學(xué)生面臨著這樣一種困境，在校學(xué)的都是傳統(tǒng)的數(shù)據(jù)庫，可一旦出來社會就業(yè)，卻面對著各種各樣的新數(shù)據(jù)庫技術(shù)，尤其是最新的內(nèi)存數(shù)據(jù)庫技術(shù)，未免顯得有點措手不及，跟不上潮流。作為一名職業(yè)技術(shù)教育的教師，完成課本教學(xué)是前提，但遠(yuǎn)遠(yuǎn)不夠，在技術(shù)更新?lián)Q代的關(guān)鍵時間點，必須做好充分技術(shù)準(zhǔn)備，才能給學(xué)生做好就業(yè)準(zhǔn)備。本文對當(dāng)前較新的數(shù)據(jù)庫技術(shù)——內(nèi)存數(shù)據(jù)庫進(jìn)行研究和探討，并以企業(yè)的一個實際應(yīng)用作為實例。

對于大多數(shù)企業(yè)而言，在越來越激烈的競爭當(dāng)中生存下來將變得更加困難，甚至可能在幾年內(nèi)就面臨破產(chǎn)。相對而言，收集數(shù)據(jù)已經(jīng)不是第一要務(wù)，更重要的是如何把數(shù)據(jù)迅速地轉(zhuǎn)化為業(yè)務(wù)分析結(jié)果，搶先于競爭對手，在激烈的市場競爭中尋找到更多商機(jī)，留住或者挖掘出更多優(yōu)質(zhì)客戶，為企業(yè)決策提供重要數(shù)據(jù)支持。

決策者為了達(dá)到公司盈利增長的目標(biāo)，迅速地做出企業(yè)決策，需要更快速地分析財務(wù)和績效數(shù)據(jù)，這一切都表明企業(yè)對報表快速分析的需求在不斷增長。

同時，企業(yè)對其他數(shù)據(jù)的分析需求，特別是非結(jié)構(gòu)化數(shù)據(jù)的分析需求不斷增長，比如圖片、音頻、視頻數(shù)據(jù)。只有更好地提供前瞻性的預(yù)測分析，才能完成盈利增長的目標(biāo)。

但是傳統(tǒng)數(shù)據(jù)庫已經(jīng)不能很好滿足目前的應(yīng)用，快速分析高度依賴高速數(shù)據(jù)庫，而內(nèi)存數(shù)據(jù)庫恰恰滿足了這一需求。

隨著硬件的不斷發(fā)展，內(nèi)存數(shù)據(jù)庫的處理效率大幅提升，發(fā)展趨勢是聯(lián)機(jī)事務(wù)處理OLTP（on-line transaction processing）和聯(lián)機(jī)分析處理OLAP（on-line analytical processing）的區(qū)別得以消滅。

目前市面上也有不少內(nèi)存數(shù)據(jù)庫產(chǎn)品，下面以SAP ERP的內(nèi)存數(shù)據(jù)庫管理系統(tǒng)為例，對內(nèi)存數(shù)據(jù)庫的實現(xiàn)原理進(jìn)行研究。其他主流數(shù)據(jù)庫廠商，如Oracle也采用類似的內(nèi)存數(shù)據(jù)庫技術(shù)。

2 內(nèi)存數(shù)據(jù)庫存儲方式

內(nèi)存數(shù)據(jù)庫管理系統(tǒng)，本質(zhì)上是一種完全運行在內(nèi)存上的大規(guī)模并行數(shù)據(jù)庫管理系統(tǒng)（DBMS）。傳統(tǒng)數(shù)據(jù)庫受限于硬件性能，會在存儲設(shè)備和CPU之間不斷傳輸數(shù)據(jù)，所以傳統(tǒng)數(shù)據(jù)庫更多地關(guān)注計算算法的優(yōu)化，著重優(yōu)化硬盤的輸入輸出。而內(nèi)存數(shù)據(jù)庫擁有大量內(nèi)存，硬件性能已經(jīng)不是瓶頸，著力于優(yōu)化CPU緩存和內(nèi)存之間的數(shù)據(jù)交換。

2.1 內(nèi)存中保存數(shù)據(jù)

傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)存儲在硬盤里，但數(shù)據(jù)最終還是要傳輸?shù)紺PU寄存器中進(jìn)行運算的。硬盤價格便宜，但速度較慢。這里考慮兩個速度因素，一個是存儲介質(zhì)的物理速度。第二個是延遲，也就是把數(shù)據(jù)從存儲介質(zhì)傳輸?shù)紺PU寄存器的速度。

而僅次于CPU寄存器速度的存儲介質(zhì)是內(nèi)存。內(nèi)存數(shù)據(jù)庫把數(shù)據(jù)存放在內(nèi)存中，速度得到了極大的提升。

2.2 數(shù)據(jù)持久性

內(nèi)存本身是一種易失性存儲介質(zhì)，一旦斷電，數(shù)據(jù)就會丟失。解決這個問題需要借助數(shù)據(jù)庫的ACID概念，即原子性、一致性、隔離性、持久性來保證數(shù)據(jù)庫事務(wù)的可靠。

SAP內(nèi)存數(shù)據(jù)庫在持久層采用了預(yù)先寫入日志、影子分頁、數(shù)據(jù)保存點等技術(shù)來保證數(shù)據(jù)修改是持久的。而日志和數(shù)據(jù)保存點保存在非易失性存儲介質(zhì)中，一旦發(fā)生數(shù)據(jù)丟失，SAP內(nèi)存數(shù)據(jù)庫可以向傳統(tǒng)數(shù)據(jù)庫一樣恢復(fù)數(shù)據(jù)。技術(shù)上它首先按照最后一次數(shù)據(jù)保存點恢復(fù)，然后按照數(shù)據(jù)庫日志執(zhí)行沒有包含的數(shù)據(jù)修改，保證數(shù)據(jù)和丟失前一致。

2.3 數(shù)據(jù)結(jié)構(gòu)

關(guān)系型數(shù)據(jù)庫使用二維表結(jié)構(gòu)來體現(xiàn)數(shù)據(jù)，一張數(shù)據(jù)庫表有一組垂直列，以及水平記錄來表示。而計算機(jī)內(nèi)存則是線性一維的，為了能夠在內(nèi)存存儲數(shù)據(jù)，就需要把二維的數(shù)據(jù)庫表結(jié)構(gòu)映射到線性的內(nèi)存地址上。

有兩個方案，第一個是基于行的結(jié)構(gòu)，把數(shù)據(jù)庫表的每一行鏈接起來，組成一個序列，保存到線性內(nèi)存地址上。另外一種方式是基于數(shù)據(jù)庫表的列，把各列數(shù)據(jù)組成一個序列，每一列數(shù)據(jù)一起存儲在線性內(nèi)存上。下面以表1的示例表進(jìn)行解析。

在實際ERP應(yīng)用中，采用列式存儲技術(shù)可以獲得更好的數(shù)據(jù)庫性能，這說明企業(yè)數(shù)據(jù)庫中的大部分操作都是讀操作和集合操作[1]。日常大多數(shù)數(shù)據(jù)庫操作都是針對數(shù)據(jù)庫表少數(shù)幾列進(jìn)行的。實際企業(yè)應(yīng)用場景中，采用列式數(shù)據(jù)存儲更加有利。

3 數(shù)據(jù)編碼和壓縮

實際的企業(yè)應(yīng)用中，數(shù)據(jù)庫大到幾個T到幾百個T，單靠有限的內(nèi)存直接存放全部數(shù)據(jù)庫表顯得不現(xiàn)實，需要采取數(shù)據(jù)壓縮技術(shù)，減少內(nèi)存中數(shù)據(jù)量，這樣可以降低硬件費用。

3.1字典編碼及壓縮

字典編碼是最基本的數(shù)據(jù)壓縮技術(shù)。字典編碼以列為單元進(jìn)行操作，通過簡單的轉(zhuǎn)換把列中的不同數(shù)據(jù)用不同的整數(shù)值（短整數(shù)優(yōu)先）替代，將長文本值壓縮為短整數(shù)值，因此并沒有改變表的規(guī)模。通常情況下，企業(yè)數(shù)據(jù)的熵較低，即數(shù)據(jù)的重復(fù)度大，壓縮效果較好。同一列里面數(shù)據(jù)重復(fù)越多，字段編碼的作用越明顯。實際商業(yè)數(shù)據(jù)庫應(yīng)用中，大部分列數(shù)據(jù)都只是由少量不同的值構(gòu)成，比如國家代碼、貨幣代碼、大量的配置表等。以SAP ERP數(shù)據(jù)庫表BPKF為例，選取前10條，見表2。我們通過圖3、圖4、圖5、圖6，看看如何將原始的數(shù)據(jù)翻譯成整數(shù)編碼，大幅提高效率。BKPF存儲的是財務(wù)會計憑證頭部信息。

我們對“公司”建立壓縮列（compressed column），其他列的壓縮列同理，略。

我們繼續(xù)對“公司”建立倒序索引（inverted index），其他列的倒序索引同理，略。

經(jīng)過統(tǒng)計，一個商業(yè)運行了5年的數(shù)據(jù)庫表BKPF，其主要字段的重復(fù)率統(tǒng)計如下。

可以看到，經(jīng)過5年的運行，表BKPF一共有63，688，313條行記錄，主要列的重復(fù)率很高，見表3。

相比行記錄的數(shù)量，很多列僅僅保存很少的不同值，字典編碼技術(shù)可以對列數(shù)據(jù)進(jìn)行很好的壓縮。

3.2數(shù)據(jù)壓縮

內(nèi)存數(shù)據(jù)庫一般還會采用了其他數(shù)據(jù)壓縮方法，比如前綴編碼（Prefix Encoding）、行程長度編碼（Run-length Encoding）、族編碼（Cluster Encoding）、間接編碼（Indirect Encoding）、增量編碼（Delta Encoding），雖然編碼和解碼需要耗用CPU資源，但相對于提高的數(shù)據(jù)存儲效率來說，還是相當(dāng)有利，可節(jié)省大量內(nèi)存。編碼后數(shù)據(jù)小了，處理速度也會相應(yīng)提高。

4 消除冗余

1970年Codd首次提出了關(guān)系模型，它奠定了今天數(shù)據(jù)庫系統(tǒng)的基礎(chǔ)[2]。為了減少冗余，人們發(fā)明了關(guān)系數(shù)據(jù)庫模型和數(shù)據(jù)標(biāo)準(zhǔn)化技術(shù)，比如范式[3]。傳統(tǒng)數(shù)據(jù)庫是空間換時間，把從數(shù)據(jù)庫其他地方衍生出來的數(shù)據(jù)存儲起來，這些數(shù)據(jù)是可以從系統(tǒng)的其他數(shù)據(jù)推導(dǎo)出來的，叫冗余數(shù)據(jù)，允許冗余數(shù)據(jù)最終達(dá)到節(jié)省計算時間的目的。但也有不利因素，我們需要維護(hù)這些數(shù)據(jù)之間的一致性，才能保證數(shù)據(jù)庫的完整性，維護(hù)成本比較高。

4.1數(shù)據(jù)冗余

目前存在的數(shù)據(jù)冗余，比如，物化視圖；物化匯總表；重疊造成的冗余；物化結(jié)果集。

我們以傳統(tǒng)數(shù)據(jù)庫舉例，SAP ERP ECC6.0的表BKPF和BSEG，BKPF存儲的是會計憑證的頭部信息，BSEG存儲的是會計憑證的分錄信息。在實際應(yīng)用中，兩張表數(shù)量巨大，記錄數(shù)據(jù)動輒上億。為了提高查詢速度，系統(tǒng)會物理化存儲他們的匯總表信息，形成物理匯總表GLT0和FAGLFLEXT。否則每次匯總計算都得等待幾十秒到數(shù)分鐘不等。下圖是一個實際投入商業(yè)運行5年的SAP系統(tǒng)，數(shù)據(jù)庫是Oracle 11.2.0.3.0，為了提高速度，存儲了兩個匯總表，一個12萬行，一個一百多萬行。

4.2內(nèi)存計算和消除冗余帶來的優(yōu)勢

得益于本文上面描述的列式存儲方式，內(nèi)存速度的提升，可以重新設(shè)計一個沒有冗余的系統(tǒng)，把所有的表屬性都?xì)w入一個統(tǒng)一表里，一個表含有所有表的字段，不再有其他單獨的物化表。

在以前磁盤數(shù)據(jù)庫和行式存儲沒有大量壓縮的情況下是無法實現(xiàn)的，但列式存儲和內(nèi)存計算下可以實現(xiàn)，而且還有很多好處。

以往解決用戶問題圍繞著物理化存儲的表，或者依賴低效的實時計算。如果基于沒有冗余和內(nèi)存計算的高速度，幾乎可以解決任何用戶問題，非常適合高性能要求的應(yīng)用，比如大數(shù)據(jù)分析、交互實時要求高的在線交易系統(tǒng)等。

5 結(jié)語

隨著技術(shù)的進(jìn)步，移動互聯(lián)網(wǎng)應(yīng)用的飛速發(fā)展，各種數(shù)據(jù)應(yīng)用變得越來越廣泛和深入，對數(shù)據(jù)的響應(yīng)速度要求越來越高，尤其以大數(shù)據(jù)為基礎(chǔ)的應(yīng)用為甚。內(nèi)存計算是解決讀寫性能的重要手段，技術(shù)的革新取決于人類生產(chǎn)與生存的需求，如果需求持續(xù)，得益于硬件技術(shù)的飛速發(fā)展，內(nèi)存越來越便宜，加上列式存儲技術(shù)和壓縮技術(shù)的應(yīng)用，內(nèi)存數(shù)據(jù)庫技術(shù)將會得到蓬勃發(fā)展。

參考文獻(xiàn)：

[1] Jens Krueger. Fast Updates on Read-Optimized Databases Using Multi-Core CPUs，2011.

[2] Edgar Codd. A Relational Model of Data for Large Shared Data Banks. Communication of the Association for Computing Machinery，1970.

[3]Edgar Codd. Further Normalization of the Data Base Relational Model.IBM Research Report Rj909，1971.