GaussDB技術(shù)解讀

【背景介紹】

數(shù)據(jù)壓縮與關(guān)系數(shù)據(jù)庫的結(jié)合，早已不是一個(gè)新鮮的話題，當(dāng)前我們已經(jīng)看到了各種各樣數(shù)據(jù)庫壓縮的產(chǎn)品和解決方案。對(duì)于 GaussDB 來說，在今天引入數(shù)據(jù)壓縮，究竟能夠給客戶帶來什么不一樣的價(jià)值，是過去一段時(shí)間我們一直在思考的問題。 為了回答這個(gè)問題，我們首先對(duì)各種通用壓縮算法進(jìn)行了廣泛的測(cè)試，從性能最好的 LZ4/Snappy，到性能與壓縮率均衡的 Zstd/Zlib，再到強(qiáng)調(diào)壓縮率的 LZMA/BZip。我們發(fā)現(xiàn)：即使是性能最好的壓縮算法，仍然無法做到對(duì)一個(gè)在線數(shù)據(jù)庫的性能不產(chǎn)生顯著影響。我們也調(diào)研了數(shù)據(jù)庫領(lǐng)域的各種編碼方法，包括近幾年學(xué)術(shù)界發(fā)布的一些基于預(yù)測(cè)和線性擬合的編碼方法，從研究發(fā)布的測(cè)試結(jié)果及實(shí)測(cè)來看，數(shù)據(jù)庫編碼用于解決特定數(shù)值分布的可壓縮性問題，與壓縮算法的成熟度相比，當(dāng)前并沒有一種通用的數(shù)據(jù)庫編碼方法，能夠在大多數(shù)真實(shí)數(shù)據(jù)集中的場(chǎng)景下提供穩(wěn)定的壓縮率。

這是我們對(duì)于數(shù)據(jù)庫壓縮這個(gè)領(lǐng)域的一個(gè)基本技術(shù)判斷。過去的產(chǎn)品實(shí)踐也驗(yàn)證了這一點(diǎn)，我們看到很多商業(yè)數(shù)據(jù)庫和開源數(shù)據(jù)庫都提供了對(duì)于壓縮的支持，絕大多數(shù)時(shí)候，留給客戶的選擇就是決定要不要在特定的表上開啟壓縮。開啟壓縮意味著空間節(jié)省，但同時(shí)意味著性能下降，這個(gè)看似簡(jiǎn)單的選擇恰恰是客戶最難做的。這也是為什么有了這么多數(shù)據(jù)庫壓縮的產(chǎn)品，我們卻很少能看到數(shù)據(jù)壓縮真正廣泛應(yīng)用在數(shù)據(jù)庫在線業(yè)務(wù)中的根本原因。 這給了我們更多的啟示。我們相信，真正可被應(yīng)用的數(shù)據(jù)庫壓縮技術(shù)，能夠去兼顧壓縮率與業(yè)務(wù)影響的平衡，應(yīng)該是選擇性的。即我們能夠基于技術(shù)去判定數(shù)據(jù)的溫度，并基于這樣的判定，去選擇性地壓縮業(yè)務(wù)中相對(duì)較冷的數(shù)據(jù)，而不去碰那些相對(duì)較熱的數(shù)據(jù)。 這樣的技術(shù)選擇意味著我們無法去滿足所有業(yè)務(wù)場(chǎng)景，我們要求業(yè)務(wù)的數(shù)據(jù)溫度分布，必須滿足 80-20 分布規(guī)則。即我們?nèi)嚎s那些占用 80% 存儲(chǔ)需求、但只占用 20% 計(jì)算需求的冷數(shù)據(jù)，而不去碰那些只占用 20% 存儲(chǔ)需求、但卻占用 80% 計(jì)算需求的熱數(shù)據(jù)。幸運(yùn)的是，我們發(fā)現(xiàn)絕大多數(shù)對(duì)于容量控制有需求的業(yè)務(wù)，都具備這樣的特征。

【場(chǎng)景及目標(biāo)選擇】

通過對(duì)大量業(yè)務(wù)場(chǎng)景的分析，我們發(fā)現(xiàn)業(yè)務(wù)對(duì)于數(shù)據(jù)庫壓縮技術(shù)的需求是多元化的，有在線交易業(yè)務(wù)（OLTP）存儲(chǔ)壓縮的場(chǎng)景，有分析業(yè)務(wù)（OLAP）存儲(chǔ)壓縮的場(chǎng)景，有歷史業(yè)務(wù)存儲(chǔ)壓縮的場(chǎng)景，也有容災(zāi)業(yè)務(wù)傳輸壓縮的場(chǎng)景。不同的場(chǎng)景，對(duì)于壓縮技術(shù)的訴求，如果從壓縮性能、壓縮率、解壓性能的三維指標(biāo)去看，從對(duì)業(yè)務(wù)侵入的容忍度去看，是完全不同的。 這意味著如果我們想要打造一個(gè)全場(chǎng)景的 GaussDB 高級(jí)壓縮特性，它應(yīng)該是多個(gè)技術(shù)的組合，包括不同的壓縮算法、不同的冷熱判定模型及方法、不同的數(shù)據(jù)存儲(chǔ)組織等，通過不同的技術(shù)組合及應(yīng)用去滿足不同的場(chǎng)景需求。 這同時(shí)意味著我們?cè)诓煌瑝嚎s適用場(chǎng)景的支持上需要有個(gè)優(yōu)先級(jí)的取舍。我們的答案是選擇去優(yōu)先支持 OLTP 存儲(chǔ)壓縮場(chǎng)景，這是我們認(rèn)為數(shù)據(jù)庫壓縮技術(shù)最有價(jià)值的業(yè)務(wù)領(lǐng)域，當(dāng)然也是技術(shù)挑戰(zhàn)最大的領(lǐng)域。

確定場(chǎng)景之后，接下來是確定技術(shù)目標(biāo)，我們面向這個(gè)場(chǎng)景，究竟要打造什么樣的核心競(jìng)爭(zhēng)力，這取決于我們對(duì)于典型客戶場(chǎng)景的分析。我們識(shí)別了兩類典型客戶場(chǎng)景： 場(chǎng)景 A：客戶業(yè)務(wù)來自于 IBM 小機(jī)，單庫容量 50TB，遷移到開放平臺(tái)后，面臨容量過大和運(yùn)維窗口過長(zhǎng)問題。選擇拆庫意味著分布式改造，對(duì)于一個(gè)已經(jīng)穩(wěn)定運(yùn)行許多年的存量關(guān)鍵業(yè)務(wù)來說，這種技術(shù)選擇風(fēng)險(xiǎn)過高。選擇壓縮可以顯著降低容量風(fēng)險(xiǎn)，但業(yè)務(wù)最初的設(shè)計(jì)并沒有考慮冷熱分離（比如基于時(shí)間維度建立分區(qū)），需要一種零侵入的壓縮技術(shù)支持，同時(shí)對(duì)業(yè)務(wù)性能影響足夠低。 場(chǎng)景 B：客戶業(yè)務(wù)基于分布式集群部署，單集群容量已經(jīng)超過 1PB，并且仍在快速增長(zhǎng)，需要定期擴(kuò)容。選擇壓縮可以降低擴(kuò)容頻率，顯著降低業(yè)務(wù)的軟硬件成本，并減少變更風(fēng)險(xiǎn)。但業(yè)務(wù)的數(shù)據(jù)分布設(shè)計(jì)是面向擴(kuò)展性的（比如基于用戶維度建立分區(qū)），沒有考慮冷熱分離，因此同樣的，業(yè)務(wù)需要一種零侵入的壓縮技術(shù)支持，同時(shí)對(duì)性能影響足夠低。 通過對(duì)客戶典型場(chǎng)景的需求梳理，我們確定了 GaussDB OLTP 存儲(chǔ)壓縮的基本設(shè)計(jì)目標(biāo)：1）冷熱判定對(duì)業(yè)務(wù)應(yīng)該是零侵入的，不應(yīng)對(duì)業(yè)務(wù)的已有數(shù)據(jù)分布、邏輯模型有任何依賴；2）對(duì)業(yè)務(wù)影響必須足夠低，我們定義目標(biāo)低于 10%，并挑戰(zhàn) 5%；3）提供合理的壓縮率，我們定義目標(biāo)不低于 2：1?；驹O(shè)計(jì)目標(biāo)的定義，使得我們能夠?qū)⒑罄m(xù)每個(gè)具體場(chǎng)景中的技術(shù)選擇都變成一個(gè)確定性問題。

【冷熱判定】

確定設(shè)計(jì)目標(biāo)后，我們開始進(jìn)行工程落地。有三個(gè)問題需要解決：1）如何實(shí)現(xiàn)對(duì)數(shù)據(jù)的冷熱判定；2）如何實(shí)現(xiàn)壓縮后數(shù)據(jù)的存儲(chǔ)組織；3）如何實(shí)現(xiàn)有競(jìng)爭(zhēng)力的壓縮算法。 對(duì)于冷熱判定，首先要確定判定的粒度。數(shù)據(jù)的冷熱判定可以基于不同粒度實(shí)現(xiàn)，行級(jí)、塊級(jí)或表 / 分區(qū)級(jí)，粒度越粗，實(shí)現(xiàn)的復(fù)雜度越低，但對(duì)業(yè)務(wù)的侵入也越大?；谠O(shè)計(jì)目標(biāo)，很自然的，我們選擇行級(jí)的冷熱判定，這是對(duì)業(yè)務(wù)數(shù)據(jù)分布依賴最小的方案，我們需要解決的，是如何控制引入冷熱判定的代價(jià)。 我們利用 GaussDB 存儲(chǔ)引擎已有的機(jī)制巧妙地解決了這一問題。具體來說，GaussDB 存儲(chǔ)引擎在每行數(shù)據(jù)的元數(shù)據(jù) Meta 中記錄了最近一次修改該行的事務(wù) ID（XID），該信息被用來支持事務(wù)的可見性判定，從而實(shí)現(xiàn)多版本并發(fā)控制（MVCC）。對(duì)于特定行來說，如果其 XID 足夠 “老”，老到它對(duì)所有當(dāng)前已經(jīng)活躍的事務(wù)都可見，那么這時(shí)候我們實(shí)際上已經(jīng)不關(guān)注 XID 的具體值，我們可以通過引入一個(gè)特定的標(biāo)志位（FLG）來記錄這一點(diǎn)，而原來 XID 中填充的值可以被一個(gè)物理時(shí)間來代替，這個(gè)物理時(shí)間就表征了其所屬行最后一次修改時(shí)間的上限（LMT，Last Modified Time）。很顯然，LMT 可以用來支持冷熱判定（具體見圖 1）：



圖 1：行級(jí)冷熱判定 上述方案的好處是引入 LMT 并沒有增加額外開銷，對(duì)業(yè)務(wù)的邏輯模型也沒有任何依賴，在大多數(shù)時(shí)候，如果不是特別嚴(yán)格要求，業(yè)務(wù)可以定義一個(gè)簡(jiǎn)單的規(guī)則來實(shí)現(xiàn)冷熱判定，比如：

AFTER 3 MONTHS OF NO MODIFICATION

此時(shí)系統(tǒng)會(huì)掃描目標(biāo)表，對(duì)于所有滿足當(dāng)前時(shí)間減去 LMT 超過 3 個(gè)月的行進(jìn)行壓縮。 注意在上述方案中，我們實(shí)際上只識(shí)別了行的寫熱點(diǎn)，但并沒有識(shí)別行的讀熱點(diǎn)，我們只知道滿足條件的行 3 個(gè)月內(nèi)未發(fā)生任何更新，但我們無法確認(rèn)這些行在 3 個(gè)月內(nèi)是否被頻繁讀取。維護(hù)行的讀熱點(diǎn)，目前從技術(shù)上沒有低成本的解決方案。對(duì)于像訂單明細(xì)這樣的流水類業(yè)務(wù)，這個(gè)方案可以很好地工作，因?yàn)閿?shù)據(jù)的讀和寫呈現(xiàn)出相同的溫度特征，其訪問頻率隨著未修改時(shí)間的增加不斷衰減。但對(duì)于像手機(jī)相冊(cè)這樣的收藏類業(yè)務(wù)，僅識(shí)別寫可能是不夠的，因?yàn)橐粋€(gè)很早建立的收藏關(guān)系仍然可能被頻繁訪問。 這意味著，即使系統(tǒng)進(jìn)行了冷熱判定，我們?nèi)匀恍枰?yōu)化業(yè)務(wù)可能訪問壓縮數(shù)據(jù)的場(chǎng)景，我們把這個(gè)問題留給了存儲(chǔ)組織和壓縮算法，對(duì)于壓縮算法來說，我們更關(guān)注其解壓性能。 另一個(gè)問題是在某些場(chǎng)景下，使用默認(rèn)的冷熱判定可能是不夠的，比如對(duì)于某些類型的交易而言，其產(chǎn)生的訂單明細(xì)可能在 3 個(gè)月內(nèi)確實(shí)不會(huì)被修改，但會(huì)在達(dá)到一個(gè)特定的觸發(fā)條件后被更新（比如解凍擔(dān)保交易）。這種場(chǎng)景在實(shí)際業(yè)務(wù)中并不常見，但如果業(yè)務(wù)確實(shí)關(guān)注性能，那么我們支持在默認(rèn)的冷熱判定規(guī)則以外，允許業(yè)務(wù)自定義規(guī)則，比如：

AFTER 3 MONTHS OF NO MODIFICATION ON (order_status = "finished")

此時(shí)系統(tǒng)會(huì)僅壓縮 3 個(gè)月未修改、且訂單狀態(tài)已經(jīng)完結(jié)的數(shù)據(jù)。 當(dāng)前我們支持的自定義規(guī)則，是任意合法的行表達(dá)式，業(yè)務(wù)可以寫任意復(fù)雜的表達(dá)式來表征數(shù)據(jù)的冷熱判定規(guī)則，但表達(dá)式中所引用的任何字段，只能是目標(biāo)表上的合法字段。通過這種默認(rèn)和自定義規(guī)則的組合使用，我們提供了業(yè)務(wù)足夠低的使用門檻和更好的靈活性。

【存儲(chǔ)組織】

當(dāng)滿足冷熱判定條件的行被壓縮時(shí)，我們需要決定如何存儲(chǔ)這些壓縮后的數(shù)據(jù)，基于設(shè)計(jì)目標(biāo)，我們選擇了對(duì)業(yè)務(wù)侵入最小的存儲(chǔ)組織實(shí)現(xiàn) —— 塊內(nèi)壓縮。 我們知道關(guān)系數(shù)據(jù)庫的存儲(chǔ)組織都是基于固定長(zhǎng)度的分塊的，在 GaussDB 數(shù)據(jù)庫中，典型的數(shù)據(jù)塊大小為 8KB，選擇更大的數(shù)據(jù)塊顯然有利于壓縮，但對(duì)業(yè)務(wù)性能會(huì)造成更大的影響。所謂塊內(nèi)壓縮，是指：1）單個(gè)塊內(nèi)所有滿足冷熱判定條件的行，會(huì)作為一個(gè)整體進(jìn)行壓縮；2）壓縮后形成的數(shù)據(jù)就存放在當(dāng)前的數(shù)據(jù)塊中，存放區(qū)域稱為 BCA（Block Compressed Area），它通常位于塊的尾部。 塊內(nèi)壓縮的設(shè)計(jì)意味著解壓任何數(shù)據(jù)只依賴于當(dāng)前塊，而不需要訪問其它的數(shù)據(jù)塊，從壓縮率的視角看，這樣的設(shè)計(jì)并不是最友好的，但它非常有利于控制業(yè)務(wù)影響。注意在我們前面的討論中，即使業(yè)務(wù)定義了冷熱判定條件，仍然存在一定的概率會(huì)訪問壓縮數(shù)據(jù)，我們希望這個(gè)訪問代價(jià)能夠有一個(gè)確定性的上限。 圖 2 給出了塊內(nèi)壓縮的詳細(xì)流程：首先，當(dāng)壓縮被觸發(fā)時(shí)，系統(tǒng)掃描數(shù)據(jù)塊中的所有行，根據(jù)指定的冷熱判定條件，識(shí)別出 R1 和 R3 是冷數(shù)據(jù)（圖 2 (a)）；接著，系統(tǒng)將 R1 和 R3 作為一個(gè)整體進(jìn)行壓縮，將壓縮后的數(shù)據(jù)就存放在該數(shù)據(jù)塊的 BCA 中（圖 2 (b)）；如果業(yè)務(wù)后續(xù)需要更新 R1，那么系統(tǒng)會(huì)為更新后的數(shù)據(jù)生成一個(gè)新的拷貝 R4，并標(biāo)識(shí) BCA 中的 R1 已經(jīng)被刪除（如圖 2 (c)）；最后，當(dāng)系統(tǒng)在該數(shù)據(jù)塊上需要更多空間時(shí)，可以回收 BCA 中屬于 R1 的空間（圖 2 (d)）。



圖 2：塊內(nèi)壓縮 在整個(gè)設(shè)計(jì)中有兩點(diǎn)需要注意：1）我們實(shí)際上只壓縮了用戶數(shù)據(jù) Data，并沒有壓縮相應(yīng)的元數(shù)據(jù) Meta，后者通常用來支持事務(wù)的可見性；2）我們支持將冷數(shù)據(jù)重新變?yōu)闊釘?shù)據(jù)，以消除因?yàn)槔錈嵴`判而帶來的影響。同樣地，從壓縮率的視角，這樣的設(shè)計(jì)并不是最友好的，但它極大地減少了對(duì)業(yè)務(wù)的侵入。簡(jiǎn)單來說，業(yè)務(wù)對(duì)于壓縮數(shù)據(jù)的訪問，與正常數(shù)據(jù)完全相同，在功能上沒有任何限制，在事務(wù)語義上也沒有任何差別。這是非常重要的原則：我們的 OLTP 存儲(chǔ)壓縮對(duì)于業(yè)務(wù)是完全透明的，這是當(dāng)前這個(gè)特性，以及后續(xù) GaussDB 高級(jí)壓縮系列所有特性都將遵循的基本原則。

【壓縮算法】

基于設(shè)計(jì)目標(biāo)，如果從壓縮率、壓縮性能、解壓性能的三維指標(biāo)來看，我們實(shí)際上需要的是一個(gè)能夠提供合理的壓縮率、合理的壓縮性能、但是極致的解壓性能的壓縮算法，這是我們壓縮算法設(shè)計(jì)的基礎(chǔ)。 我們首先測(cè)試了直接使用 LZ4 進(jìn)行壓縮，LZ4 是目前已知的壓縮性能和解壓性能最好的開源三方庫，從實(shí)測(cè)結(jié)果看，LZ4 的壓縮率是偏低的。我們仔細(xì)分析了其算法原理，LZ4 是基于 LZ77 算法的一種實(shí)現(xiàn)，LZ77 算法的思想非常簡(jiǎn)單，就是把要壓縮的數(shù)據(jù)看成一個(gè)字節(jié)流，算法從字節(jié)流的當(dāng)前位置開始，前向?qū)ふ液彤?dāng)前位置相同的匹配字符串，然后用匹配到的字符串的長(zhǎng)度以及與當(dāng)前位置的偏移，用來表示被匹配的字符串，從而達(dá)到壓縮的效果。從算法原理上看，LZ77 算法對(duì)于長(zhǎng)文本會(huì)有比較好的壓縮效果，但是對(duì)于結(jié)構(gòu)化數(shù)據(jù)中大量的短文本以及數(shù)值類型，效果就有限，我們實(shí)際的測(cè)試也驗(yàn)證了這一點(diǎn)。

接下來，我們將壓縮算法分為了兩層：第一層，我們按列對(duì)一些數(shù)值類型進(jìn)行了編碼，我們選擇了簡(jiǎn)單的差值編碼，這種編碼足夠輕量級(jí)，解壓特定字段不需要依賴其它字段的值；第二層，我們將編碼后的數(shù)據(jù)再調(diào)用 LZ4 進(jìn)行壓縮。注意在第一層中，我們實(shí)際上是按列編碼、按行存儲(chǔ)，這和業(yè)界的一般實(shí)現(xiàn)（按列編碼并存儲(chǔ)）有很大不同，按列存儲(chǔ)對(duì)壓縮率會(huì)更加友好，但是按列存儲(chǔ)意味著同一行的數(shù)據(jù)會(huì)被分散到 BCA 的不同區(qū)域，這種傳統(tǒng)的設(shè)計(jì)無法支持我們后續(xù)希望實(shí)現(xiàn)的部分解壓，我們將在結(jié)束語中更詳細(xì)地說明這一問題。 通過實(shí)測(cè)，我們發(fā)現(xiàn)這種列編碼 + 通用壓縮的實(shí)現(xiàn)方式有效地提升了壓縮率，同時(shí)控制了業(yè)務(wù)影響的明顯增加，但兩層實(shí)現(xiàn)之間是松耦合的，這引入了許多額外的開銷。因此我們?cè)谧屑?xì)權(quán)衡之后，決定放棄 LZ4，而是完全基于 LZ77 算法，重新實(shí)現(xiàn)一個(gè)緊耦合的壓縮算法。

這在當(dāng)時(shí)看來是一個(gè)非常冒險(xiǎn)的嘗試，事實(shí)上，在我們之前，還沒有任何數(shù)據(jù)庫內(nèi)核團(tuán)隊(duì)，會(huì)選擇自己去實(shí)現(xiàn)一個(gè)通用壓縮算法。但從最后取得的收益來看，我們實(shí)際上是打開了一扇全新的大門。當(dāng)列編碼與 LZ77 算法之間的邊界被打破時(shí)，我們引入了一系列的優(yōu)化創(chuàng)新，考慮篇幅原因，我們無法展現(xiàn)全部技術(shù)細(xì)節(jié)，在這里，我們只介紹兩個(gè)小的優(yōu)化： 第一個(gè)優(yōu)化是內(nèi)置行邊界。我們發(fā)現(xiàn)，當(dāng)系統(tǒng)采用兩層壓縮算法后，我們需要額外地保存每一行數(shù)據(jù)在編碼后的長(zhǎng)度，因?yàn)槲覀冃枰?LZ77 算法解壓后找到每一行的邊界，這是一個(gè)不小的開銷。為了消除這個(gè)開銷，我們選擇在 LZ77 的編碼格式中嵌入一個(gè)行邊界的標(biāo)記，這個(gè)標(biāo)記只占用了 1 個(gè)位，其開銷較現(xiàn)有方案大幅降低。當(dāng)然，這個(gè)標(biāo)記位被占用后，LZ77 前向搜索的最大窗口長(zhǎng)度減少了一半，但在我們這個(gè)場(chǎng)景中，這并不是什么問題，因?yàn)槲覀兊牡湫晚撁骈L(zhǎng)度只有 8KB。 第二個(gè)優(yōu)化是 2 字節(jié)短編碼。原有 LZ4 的實(shí)現(xiàn)中，為了提高壓縮性能，系統(tǒng)使用 3 字節(jié)編碼來描述一個(gè)匹配，這意味著系統(tǒng)能夠識(shí)別的最短匹配為 4 字節(jié)。

但是在結(jié)構(gòu)化數(shù)據(jù)中，3 字節(jié)的匹配是非常普遍的，參考下面一個(gè)例子： A = 1 … B = 2 其中，A 和 B 是同一行數(shù)據(jù)中的兩個(gè)整數(shù)型字段，它們的值分別為 1 和 2，基于當(dāng)前的字節(jié)序，該行數(shù)據(jù)實(shí)際在內(nèi)存中存放的形式如下所示： 01 00 00 00 … 02 00 00 00 注意上面標(biāo)紅的部分，很明顯，這里面有一個(gè) 3 字節(jié)的匹配，但是它無法被 LZ4 識(shí)別。 我們通過在 LZ77 算法中額外引入 2 字節(jié)短編碼來解決這一問題，2 字節(jié)短編碼可以識(shí)別最小 3 字節(jié)的匹配，從而相對(duì) LZ4 能夠提升壓縮率。當(dāng)然，引入短編碼會(huì)有額外的開銷：1）壓縮性能會(huì)有一定程度的下降，因?yàn)槲覀冃枰蓚€(gè)獨(dú)立的 HASH 表，幸運(yùn)的是，在我們這個(gè)場(chǎng)景中，極致壓縮性能并不是我們追求的目標(biāo)；2）2 字節(jié)編碼減少了表達(dá)匹配串與被匹配串之間距離的位寬，這意味著 3 字節(jié)的匹配必須離得更近才能被識(shí)別，在我們這個(gè)場(chǎng)景中，這并不是什么問題，因?yàn)橄鄬?duì)于這個(gè)限制，一個(gè)典型數(shù)據(jù)行的長(zhǎng)度已經(jīng)是足夠小的。

【效果評(píng)估】

我們使用標(biāo)準(zhǔn)的 TPCC 測(cè)試來評(píng)估啟用 OLTP 存儲(chǔ)壓縮特性對(duì)業(yè)務(wù)的影響。TPCC 模型共包含 9 張表，其中空間會(huì)動(dòng)態(tài)增長(zhǎng)的流水表共有 3 張，在這 3 張表中，訂單明細(xì)表（Orderline 表）的空間增長(zhǎng)比其它表多一個(gè)數(shù)量級(jí)，因此我們選擇在這張表上開啟壓縮。基于 TPCC 的業(yè)務(wù)語義，每筆訂單一旦完成配送，其訂單狀態(tài)就進(jìn)入完結(jié)狀態(tài)，完結(jié)的訂單不會(huì)再被修改，但仍有一定的概率被查詢?；谶@個(gè)語義，我們選擇冷熱判定原則為只壓縮已經(jīng)完結(jié)的訂單。 我們分別測(cè)試了在不開啟壓縮和開啟壓縮狀態(tài)下系統(tǒng)的性能值，結(jié)果如圖 3 所示：



圖 3：業(yè)務(wù)影響評(píng)估 測(cè)試結(jié)果表明：在 TPCC 測(cè)試場(chǎng)景下，開啟壓縮與不開啟壓縮相比，系統(tǒng)性能大概降低了 1.5%。這是一個(gè)非常不錯(cuò)的結(jié)果，這意味著即使在超過百萬 tpmC 的業(yè)務(wù)峰值場(chǎng)景中，系統(tǒng)也可以開啟壓縮。我們不知道在此之前，業(yè)內(nèi)是否有其它數(shù)據(jù)庫產(chǎn)品也能夠達(dá)到這一水平。 我們測(cè)試了 Orderline 表的壓縮率，作為更豐富的數(shù)據(jù)集，我們同時(shí)選擇了 TPCH 模型中的 4 張表（Lineitem、Orders、Customer、Part 表）進(jìn)行測(cè)試。為了便于比較，對(duì)于每個(gè)數(shù)據(jù)集，我們同時(shí)測(cè)試了 LZ4、ZLIB 和我們的壓縮算法的壓縮率表現(xiàn)，其中 ZLIB 是強(qiáng)調(diào)壓縮解壓性能和壓縮率均衡的算法，其壓縮解壓性能較 LZ4 低了 5-10 倍。最終結(jié)果如圖 4 所示：



圖 4：壓縮率評(píng)估 測(cè)試結(jié)果與我們預(yù)期的相符，在數(shù)值型字段較多時(shí)，我們的壓縮算法的壓縮率要高于所有通用壓縮算法，但在文本型字段較多時(shí)，我們的壓縮算法的壓縮率會(huì)介于 LZ 類和 LZ + Huffman 組合類的壓縮算法之間。

【運(yùn)維 TIPS】

注意我們的壓縮方案實(shí)際上是離線的，也就是數(shù)據(jù)剛生成時(shí)必然是熱數(shù)據(jù)，它們不會(huì)觸發(fā)壓縮，業(yè)務(wù)訪問這些數(shù)據(jù)的性能也不會(huì)受任何影響；隨著時(shí)間的推移，這些數(shù)據(jù)的溫度會(huì)逐漸降低，最終被獨(dú)立的壓縮任務(wù)識(shí)別為冷數(shù)據(jù)并進(jìn)行壓縮。 選擇在業(yè)務(wù)低峰期運(yùn)行這些壓縮任務(wù)、并控制其資源消耗是運(yùn)維端需要關(guān)注的問題。在這塊我們提供了豐富的運(yùn)維手段，包括指定運(yùn)維窗口、壓縮任務(wù)的并行度、每個(gè)壓縮任務(wù)的壓縮數(shù)據(jù)量等。對(duì)于絕大多數(shù)業(yè)務(wù)來說，單位時(shí)間內(nèi)新增的數(shù)據(jù)量實(shí)際是比較有限的，因此業(yè)務(wù)也可以選擇一個(gè)特定的時(shí)間段集中完成壓縮任務(wù)，比如每個(gè)月第一天的凌晨?jī)牲c(diǎn)到四點(diǎn)，完成 3 個(gè)月前新增冷數(shù)據(jù)的壓縮。

業(yè)務(wù)在決定開啟壓縮之前，可能希望先了解開啟壓縮后的收益，并根據(jù)收益大小做出決策。為此我們提供了一個(gè)壓縮率評(píng)估工具，能夠?qū)δ繕?biāo)表的數(shù)據(jù)進(jìn)行采樣，并使用和實(shí)際壓縮過程完全相同的算法對(duì)采樣數(shù)據(jù)進(jìn)行壓縮，計(jì)算壓縮率，但不會(huì)實(shí)際生成 BCA，不會(huì)修改任何數(shù)據(jù)。 如果業(yè)務(wù)將壓縮數(shù)據(jù)遷移到另一個(gè)表，可能會(huì)導(dǎo)致所有數(shù)據(jù)從壓縮狀態(tài)變?yōu)榉菈嚎s狀態(tài)，從而導(dǎo)致空間膨脹，這并非我們的方案引入的，而是所有壓縮方案都需要解決的問題。如果冷熱判定規(guī)則非常確定，那么業(yè)務(wù)可以手動(dòng)執(zhí)行壓縮任務(wù)使壓縮立即生效；對(duì)于耗時(shí)較長(zhǎng)的大容量壓縮表的遷移，業(yè)務(wù)仍然可以選擇定期地開啟自動(dòng)壓縮任務(wù)來完成。 最后，對(duì)于壓縮的開啟和關(guān)閉，我們提供最細(xì)粒度的控制，無論是普通表、普通分區(qū)表中的單個(gè)分區(qū)，還是二級(jí)分區(qū)中的任意單個(gè)分區(qū)、子分區(qū)，業(yè)務(wù)都可以單獨(dú)開啟或關(guān)閉壓縮。這使得對(duì)于業(yè)務(wù)本身已經(jīng)對(duì)數(shù)據(jù)區(qū)分了冷熱（比如基于時(shí)間分區(qū)）的場(chǎng)景，仍然可以和我們的壓縮特性很好地配合。

【結(jié)束語】

在 OLTP 表壓縮這個(gè)特性中，我們引入了一系列的技術(shù)創(chuàng)新，包括全新的壓縮算法、細(xì)粒度的自動(dòng)冷熱判定和塊內(nèi)壓縮支持等，可以在提供合理壓縮率的同時(shí)，大幅度降低對(duì)業(yè)務(wù)的影響，我們希望這個(gè)特性能夠在支持關(guān)鍵在線業(yè)務(wù)的容量控制中發(fā)揮重要價(jià)值。 接下來我們還將在降低引入壓縮對(duì)業(yè)務(wù)的影響、部分解壓特性、OLTP 索引壓縮等方面持續(xù)創(chuàng)新迭代，我們希望能夠有開創(chuàng)性的技術(shù)突破來解決相關(guān)的問題，為業(yè)務(wù)創(chuàng)造更大價(jià)值。

審核編輯：劉清