編者薦語：

數(shù)據(jù)壓縮，我想經(jīng)常做數(shù)據(jù)庫內(nèi)核開發(fā)的同學并不陌生，像StoneDB就采用了多種智能壓縮算法，平均可提供10倍左右的壓縮比，在部分生產(chǎn)環(huán)境中可以達到30倍的壓縮效果，本文來自石原子科技合伙人祁國輝老師，給大家介紹數(shù)據(jù)壓縮的相關(guān)技術(shù)，推薦閱讀。

以下文章來源于ITPUB?，作者祁國輝

談到數(shù)據(jù)倉庫， 必然都會涉及海量歷史數(shù)據(jù)， 但是對于歷史數(shù)據(jù)有個共識， 就是越近的數(shù)據(jù)訪問頻率越高， 越久遠的數(shù)據(jù)訪問頻率越低。

作者?|?祁國輝

編輯&設計 | 宇亭

責編?|?韓?? 楠

當歷史數(shù)據(jù)訪問頻率低到一定程度，我們就會發(fā)現(xiàn)數(shù)據(jù)的存儲成本和收益開始倒掛， 存儲數(shù)據(jù)有點得不償失。

這個時候解決的思路，有兩個方向。

第一，把歷史數(shù)據(jù)從系統(tǒng)中遷移出去， 搬遷到更加廉價的存儲平臺上， 比如Hadoop， 比如對象存儲。第二，考慮使用數(shù)據(jù)壓縮技術(shù)， 提升硬盤的利用率， 從而降低數(shù)據(jù)存儲成本。這兩種方式可以單獨實施， 也可以結(jié)合使用， 建立起一整套的數(shù)據(jù)生命周期管理流程。

首先看看數(shù)據(jù)庫壓縮中的符號表

說到數(shù)據(jù)壓縮， 大家一定都很熟悉， 首先是最常用的ZIP 和RAR；

另外，我們的圖像壓縮JPG和MPG，都是大家耳熟能詳?shù)募夹g(shù)。

但是這些都是文件壓縮算法， 一般而言， 一個文件在使用的時候， 都是需要全文件裝載的， 所以壓縮和解壓縮都是全文件進行的?？墒菍τ跀?shù)據(jù)庫來說，使用場景有所不同， 由于我們對于數(shù)據(jù)庫的訪問， 絕大多數(shù)都是訪問數(shù)據(jù)庫中的一部分， 因此壓縮和解壓縮沒必要 也不可能動輒就全表操作，所以數(shù)據(jù)庫的壓縮是有不同技術(shù)的。

所有數(shù)據(jù)壓縮，都會涉及獨有的壓縮和解壓縮的算法。一般而言， 壓縮和解壓縮的算法，需要有三個方面的指標，進行評估：

??第一，壓縮率。我們希望壓縮率盡量高；

??第二，算法復雜度， 即壓縮和解壓縮時的CPU消耗，我們是希望對CPU的消耗盡量小；

??第三，速度， 即壓縮和解壓縮的速度，我們的目標是速度盡量快，對用戶無感是最高要求。

但是這仨指標很難同時達到， 所以不同的算法都是在這幾個指標之間折衷，尋找最佳的平衡點。

不過本文中， 我們不討論具體的算法， 而是側(cè)重討論一下數(shù)據(jù)庫壓縮當中的一些基本概念，希望對大家在選用數(shù)據(jù)庫壓縮技術(shù)的時候，能夠有所幫助。

數(shù)據(jù)庫壓縮中最常用的一個概念，就是符號表， 那么符號表是干什么的呢？

我們簡單講述一下數(shù)據(jù)庫壓縮的原理， 當數(shù)據(jù)庫寫入一行數(shù)據(jù)的時候，首先檢查一下符號表， 然后根據(jù)符號表來把實際數(shù)據(jù)轉(zhuǎn)換成為符號表中的符號存儲在磁盤上；反之， 數(shù)據(jù)庫讀一行數(shù)據(jù)的時候，磁盤返回的是一行符號， 需要根據(jù)符號表的映射， 再解釋成為真實的數(shù)據(jù)。

那么符號表和真實數(shù)據(jù)的映射和轉(zhuǎn)換過程，就表現(xiàn)為壓縮和解壓縮過程。

下面看看靜態(tài)符號表和動態(tài)符號表， 在數(shù)據(jù)庫最早引入壓縮算法的時候， 很多廠商采用的是靜態(tài)符號表， 意思是在數(shù)據(jù)庫的表壓縮之前， 首先掃描一下全表數(shù)據(jù)， 然后建議一個全局的符號表， 那么之后的數(shù)據(jù)壓縮和解壓縮都可以基于這個全局符號表。小錄

這種全局符號表的優(yōu)勢是速度會快， 但是有一個小問題， 如果這個表中出現(xiàn)壓縮之前沒有出現(xiàn)的數(shù)據(jù)， 那么這個數(shù)據(jù)就沒有辦法壓縮。

所以這種壓縮算法，只適合一些特殊的場合。

很快就被動態(tài)符號表的技術(shù)淘汰了。動態(tài)符號表的原理是這樣， 數(shù)據(jù)入庫的時候， 當一個數(shù)據(jù)首次出現(xiàn)， 系統(tǒng)就會給一個符號，當數(shù)據(jù)再次出現(xiàn)， 系統(tǒng)就會直接引用之前的符號。這樣一來，所有的數(shù)據(jù)都會被壓縮。但是缺點在于復雜度有所上升。不過因為它的使用場景比較廣泛，所以大多數(shù)廠商都會選擇動態(tài)符號表。

行壓縮、列壓縮和混合壓縮中的壓縮比

了解了符號表的原理， 那么我們就可以簡要地分析一下，不同數(shù)據(jù)存儲方式帶來的不同的壓縮方法， 因為壓縮之后的數(shù)據(jù)是基于數(shù)據(jù)庫進行存儲的， 所以壓縮和數(shù)據(jù)存儲格式有很大的關(guān)系。

首先最簡單的是行壓縮， 這是大多數(shù)傳統(tǒng)數(shù)據(jù)庫采用的方式， 數(shù)據(jù)庫存儲數(shù)據(jù)是以行的方式進行存儲的，而數(shù)據(jù)是存儲在數(shù)據(jù)塊中。那么一般情況下，動態(tài)符號表就保存在每個數(shù)據(jù)塊中， 只負責本數(shù)據(jù)塊內(nèi)的數(shù)據(jù)的映射和轉(zhuǎn)換。

一個簡單的原理， 符號表中一個符號引用的次數(shù)越多， 那么數(shù)據(jù)壓縮的壓縮比就越高， 因為每引用一次符號，就代表數(shù)據(jù)塊中使用較短的符號，來取代了原來較長的數(shù)據(jù)的次數(shù)越多。

所以想提高行壓縮的壓縮比，就是盡量把相同的數(shù)據(jù)保存在一起， 方法有下面這幾種：

??數(shù)據(jù)塊越大， 數(shù)據(jù)重復的幾率越高， 所以， 盡量采用大數(shù)據(jù)塊；

??表寬度要小， 因為表太寬， 一個數(shù)據(jù)塊中相同的數(shù)據(jù)都可能出現(xiàn)不了幾次；

??盡量在入庫前按照重復率高的大字段進行排序， 這樣相同的數(shù)據(jù)就可以出現(xiàn)在相鄰的位置。

接下來，我們看看列壓縮， 大家都知道列式數(shù)據(jù)庫的一個很大的優(yōu)勢就是，數(shù)據(jù)按照列進行存儲， 而一般而言，數(shù)據(jù)庫中的同一個列中數(shù)據(jù)重復的幾率很高， 更別提某些比如性別、省份這樣的屬性列， 即使數(shù)據(jù)庫中有上千萬條記錄， 這個列上的不同數(shù)據(jù)也是很小的幾種。

這樣的數(shù)據(jù)進行壓縮的時候， 壓縮比就會特別高， 但是我們也知道， 對于這種列式數(shù)據(jù)庫， 如果需要對壓縮數(shù)據(jù)進行update或者刪除， 那么很有可能代價會特別大， 有可能會影響到所有的行， 所以列式數(shù)據(jù)庫的數(shù)據(jù)壓縮，適合一些不需要進行數(shù)據(jù)修改的場合。

但是，如果啟用了列式壓縮， 那么壓縮比是所有數(shù)據(jù)庫中最大的， 而且某些數(shù)據(jù)庫還可以只針對特定的列進行壓縮， 靈活性又有了更大的提高。

下面我們看一下Oracle的混合列壓縮（HCC）， 混合列壓縮目前只在Exadata上可用， 它可以提供目前行式數(shù)據(jù)庫中最高的壓縮比。?我們可以簡要了解一下：

混合列壓縮， 顧名思義，首先它采用了列壓縮的模式， 其次它是一種混合模式， 怎么理解呢？

這里需要引入一個新的概念 CU（壓縮單元）， 就是在數(shù)據(jù)塊之上，進一步劃分出一層邏輯概念， 叫做壓縮單元。

在一個壓縮單元內(nèi)， 數(shù)據(jù)庫使用列壓縮的模式， 提高壓縮比， 但是當數(shù)據(jù)需要修改和更新的時候， 會把影響限制在一個壓縮單元之內(nèi)， 這樣一來就可以既享受列壓縮的高壓縮比， 又盡量減少列壓縮中數(shù)據(jù)更改帶來的全局影響。

和前面討論的一樣， 壓縮單元越大， 數(shù)據(jù)重復率越高， 當然存取效率的影響也越大， 所以對于不更改的歸檔數(shù)據(jù)， 就可以采用大的壓縮單元，對于一些訪問比較頻繁的數(shù)據(jù)， 則采用較小的壓縮單元。

另外， 目前流行的MPP分析數(shù)據(jù)庫， 也都采用了一種類似Parquet 或者ORC的存儲格式，來實現(xiàn)數(shù)據(jù)的行列混存。要點如下：行組(Row Group)：按照行將數(shù)據(jù)物理上劃分為多個單元，每一個行組包含一定的行數(shù)列塊(Column Chunk)：在一個行組中每一列保存在一個列塊中，行組中的所有列連續(xù)的存儲在這個行組文件中。不同的列塊可能使用不同的算法進行壓縮。

所以， 這樣一來， 大家可以看出來，MPP的行列混存， 壓縮的時候是和Oracle的HCC是一樣的。

數(shù)據(jù)壓縮帶來的不止空間節(jié)省

每次談到數(shù)據(jù)壓縮， 大家都在看的是數(shù)據(jù)壓縮后，節(jié)省了大量的空間， 這樣同等大小的磁盤就可以存儲更多的數(shù)據(jù)， 進而降低數(shù)據(jù)存儲的成本。但是我們在實際生產(chǎn)中， 除了節(jié)省空間之外， 還會有另外一種收益， 就是海量數(shù)據(jù)查詢時的性能提升。

這個乍一聽， 感覺有點匪夷所思， 但是我們仔細分析之后，發(fā)現(xiàn)原理很簡單。

來，我們舉個例子，假設我們的查詢需要掃描1T的數(shù)據(jù)， 一般情況下， 數(shù)據(jù)塊從磁盤到內(nèi)存的事件是最長的， 為了容易理解，我們假設需要10秒， 而SQL解析和結(jié)果生成的時間， 幾乎可以忽略不計。

當數(shù)據(jù)壓縮之后， 我們用比較普遍的壓縮比來看， 假設數(shù)據(jù)壓縮之后，壓縮為原來的1/3， 這樣以來，數(shù)據(jù)塊就會減少到原來的1/3 ， 自然數(shù)據(jù)塊到內(nèi)存的時間也縮短到原來的1/3，大約3秒多。

但是因為數(shù)據(jù)是壓縮的， 需要增加一個解壓縮的過程，不過這個過程是在內(nèi)存里實現(xiàn)的， 所以解壓縮時間一定用不了6秒， 最多不會超過2秒，剩下的過程和不壓縮沒什么區(qū)別。

這樣一來， 我們看看， 壓縮之后SQL執(zhí)行時間大約5秒的時長， 對比一下，我們發(fā)現(xiàn)數(shù)據(jù)壓縮之后，SQL執(zhí)行反而會比未壓縮更快。

不過，我們知道， 數(shù)據(jù)壓縮會增加數(shù)據(jù)庫的入庫時間， 但是對于數(shù)據(jù)倉庫的海量歷史數(shù)據(jù)，一般都是一次入庫， 多次讀取， 與其每次查詢都浪費大量時間， 不如在入庫的時候一次性增加少量入庫時間， 帶來將來的高效率查詢。

其他與數(shù)據(jù)壓縮相關(guān)的場景

看完上面的內(nèi)容，相信大家對于數(shù)據(jù)庫的壓縮有了一定的了解， 那么我們接下來看看其他的一些場景。

◆?OLTP與延遲壓縮

我們都知道數(shù)據(jù)壓縮在OLAP場景下， 一次性的入庫損耗和多次的查詢性能提升，是比較好做選擇的。但是有時候難免會碰到一些罕見的場景， 比如某個應用系統(tǒng)， 每天入庫的數(shù)據(jù)量巨大， 造成存儲成本居高不下， 需要進行數(shù)據(jù)壓縮的采用， 那么這個時候就必須考慮數(shù)據(jù)壓縮了。

但是對于OLTP來說說， 入庫效率是也是至關(guān)重要的指標， 這個時候怎么才能兩全其美呢？?這里介紹兩種方法， 大家可以參考。

1.數(shù)據(jù)庫表分區(qū)，或者分表， 原則上， 當天的數(shù)據(jù)不壓縮，兩天后，一周內(nèi)的數(shù)據(jù)輕量壓縮， 一周以上一月之內(nèi)的數(shù)據(jù)，可以考慮更高壓縮比的壓縮方法， 三個月以上的數(shù)據(jù)甚至可以歸檔離線。

在各個不同壓縮策略之間， 采用自動腳本， 在業(yè)務閑時定期進行遷移。這就是一個簡單的數(shù)據(jù)生命周期管理的思路。

2.OLTP壓縮， 目前不少數(shù)據(jù)庫都可以支持這種OLTP壓縮，或者成為延時壓縮， 原理是， 新入庫的數(shù)據(jù)不壓縮， 這樣對入庫效率完全沒有影響， 當達到某個時間閥值，或者新數(shù)據(jù)量達到某個閥值的時候， 數(shù)據(jù)庫后臺會自動對新的數(shù)據(jù)進行異步壓縮。

根據(jù)LRU原則， 最新的數(shù)據(jù)容易被頻繁訪問， 那么這些容易被頻繁訪問的數(shù)據(jù)就暫時不壓縮，等到過一段時間， 這些數(shù)據(jù)的訪問頻率降下來之后，再進行壓縮；這樣一來，就可以即不影響入庫效率， 又能夠提升磁盤使用效率。

◆?什么場景不能壓縮

我們前面了解了數(shù)據(jù)庫壓縮的一些使用場景， 但是這里還是要給大家說一下， 什么場景下， 不能采用壓縮， 如果采用了， 反而會造成空間膨脹和大幅度性能下降。

我們在生產(chǎn)中，經(jīng)常會在表設計里存在這樣的設計， 某個大的備注字段， 缺省為空， 后面會根據(jù)實際情況進行更新， 添加大量的描述性信息。

這種情況下，如果采用壓縮，尤其是數(shù)據(jù)庫壓縮之后，出現(xiàn)大量的update來補充信息， 那么對數(shù)據(jù)庫的壓縮，就會帶來災難性的結(jié)果。

因為原來的數(shù)據(jù)塊在壓縮之后， 數(shù)據(jù)塊內(nèi)數(shù)據(jù)已經(jīng)充滿， NULL 會用符號代替， 但是當新的數(shù)據(jù)需要寫入的時候，數(shù)據(jù)庫就不得不把新數(shù)據(jù)寫在一個新的數(shù)據(jù)塊中， 同時在原來的位置，使用指針來指向更新后的數(shù)據(jù)， 這就造成了DBA 最不愿意看到的行遷移，會造成數(shù)據(jù)庫性能的嚴重下降。

所以對于壓縮數(shù)據(jù)， 最不希望看到的就是update大量數(shù)據(jù)， 如果真的需要， 請解壓之后update， 完成之后再次壓縮。

寫在最后

數(shù)據(jù)倉庫中的數(shù)據(jù)壓縮，使用越來越廣泛， 除了能夠降低存儲成本之外， 同時還可以在某些場景下大幅提高查詢性能。

當然由于數(shù)據(jù)庫的空間變小了，因此數(shù)據(jù)庫的災難恢復時間也會縮短，實屬數(shù)據(jù)倉庫中比較熱門的技術(shù)。

隨著越來越多的智能設備的接入， 企業(yè)數(shù)倉的數(shù)據(jù)規(guī)模越來越大， 已經(jīng)從TB跨越PB直達EB級別， 數(shù)據(jù)壓縮在未來會有越來越多的用武之地。

關(guān)于數(shù)據(jù)庫壓縮， 今天就談這么多， 如果大家有什么想要討論的， 請不吝賜教。

▼

作者介紹

祁國輝

前 Oracle 云平臺事業(yè)部電信行業(yè)技術(shù)總監(jiān)現(xiàn)就職于杭州石原子科技有限公司

【作者介紹】網(wǎng)名"atiger"，前 Oracle 云平臺事業(yè)部電信行業(yè)技術(shù)總監(jiān)。擁有超過25年數(shù)據(jù)庫和數(shù)據(jù)倉庫HK經(jīng)驗。曾創(chuàng)辦著名數(shù)據(jù)倉庫網(wǎng)站：?(數(shù)據(jù)倉庫之路）。