GaussDB技術解讀系列：高級壓縮之OLTP表壓縮

第14屆中國資料庫技術大會（DTCC2023）上，華為雲資料庫GaussDB首席架構師馮柯對華為雲GaussDB資料庫的高級壓縮技術進行了詳細的解讀。 ...

本文分享自華為雲社區《DTCC 2023專家解讀 | GaussDB技術解讀系列：高級壓縮之OLTP表壓縮》，作者：GaussDB 資料庫。

8月16日，第14屆中國資料庫技術大會（DTCC2023）在北京國際會議中心順利舉行。在GaussDB“五高兩易”核心技術，給世界一個更優選擇的專場，華為雲資料庫GaussDB首席架構師馮柯對華為雲GaussDB資料庫的高級壓縮技術進行了詳細的解讀。

以下為演講實錄：

各位嘉賓，大家下午好！很高興由我開始給大家帶來今年GaussDB一系列新特性的技術解讀。我解讀的是第一個特性，高級壓縮。

GaussDB高級壓縮全景

高級壓縮是面向業務全場景的資料庫壓縮解決方案，適用的場景主要分兩類。第一類是存儲類，主要為業務提供容量控制，減少業務擴容的概率和成本；第二類是傳輸類，主要是面向跨Region、跨AZ的業務場景如何去匹配業務的網路帶寬的現實條件，為業務提供更穩定的SLA保證。這裡面又有很多細分的場景，TP、AP都有。

這裡面有非常多的挑戰，一是壓縮演算法怎麼設計，二是怎麼做冷熱判定。我們在整個存儲類的壓縮里用的都是選擇性壓縮，基於系統自動發現數據的冷熱，只壓縮業務中相對比較冷的數據，不去碰相對熱的數據。包括實現業務的零侵入、和存儲引擎的結合，有很多技術挑戰。

典型場景和目標設計

不同的場景對於壓縮演算法，包括壓縮率、業務影響、業務侵入容忍度是不一樣的。這裡要介紹的，是我們第一個發佈的OLTP表壓縮的技術細節。講這個之前，先講一下OLTP表壓縮究竟解決的是什麼樣的客戶場景，這決定了我們整個技術目標。

有兩個典型場景是我們在真實業務中碰到的。第一個場景，客戶的業務來自於IBM小機，整個單庫容量達到幾十個TB，容量比較大。業務如果遷移到開放平臺，比較大的問題是單體容量太大，整個運維視窗的時間比較長。我們有不同的選擇，可以選擇大家說的拆庫，也就是分表分庫，但拆庫意味著需要做整個分散式改造，對有些業務來講是很多年的存量的關鍵業務，這種改造方式整個風險是非常高的。第二個選擇可以用壓縮，壓縮可以減少容量，但客戶在業務設計的開始並沒有做冷熱分離，比如沒有把用戶的數據基於時間維度做分片，如果用壓縮，客戶首要的訴求是能否做到壓縮對業務的影響足夠低，其次才是壓縮率，這是第一個典型場景。

第二個典型場景，客戶業務基於分散式集群部署，容量增長得非常快，已經超過一個PB，並且還在不斷增長。對於客戶來講，這是非常大的問題，需要定期做擴容。使用壓縮同樣可以幫助客戶減少擴容的頻率、變更的風險。但問題是一樣的，客戶數據同樣沒有做冷熱分離，是面向擴展性來設計的，比如基於用戶ID號進行分片，讓不同用戶的負載能夠平均分配給不同的數據節點。由於沒有做冷熱分離，如果要用壓縮，能否做到壓縮對於業務的影響足夠低，其次才是壓縮率。這也是我們看到的非常典型的OLTP壓縮的場景。

我們對這兩個場景進行了分析，推導出三個基本的設計目標。首先，整個壓縮方案必須是零侵入的，不能假設業務的已有數據分佈，不能說建一個分區，數據一定能區分冷熱，因為業務沒有這樣的條件。不能對業務的數據分佈、邏輯模型有任何的假設，方案必須是零侵入的。第二，如果業務開啟壓縮，對業務的影響應該是極低的，我們定義至少10%，甚至5%，這是非常重要的。第三才是合理的壓縮率，2：1或3：1，如果沒有壓縮率，做這些事情的價值就不存在了。這三個基本目標也決定了我們後面整個技術方案的設計和工程落地。

關鍵挑戰一：如何判定業務的冷熱數據？

確定完目標，有三個比較關鍵的問題需要解決。一是怎麼判定業務的冷熱數據，二是判定完之後怎麼和現有的壓縮引擎結合，對壓縮後的數據有效地存儲，第三點才是怎麼實現有競爭力的壓縮演算法。

我們做冷熱判定，首先是確定判定的粒度。可以按照表、分區、塊來判定，也可以按照行來判定。判定的粒度越細，意味著對業務的侵入越低，對業務整個數據分佈沒有任何假設，當然實現的挑戰也越大。基於我們定義的技術目標，在做OLTP表壓縮時，第一個目標就是冷熱判定必須是行級別的，這樣對業務的侵入是最小的。

我們利用了GaussDB現有存儲引擎已有的機制。GaussDB現在的存儲引擎和其他引擎一樣，在整個數據上除了存放用戶數據之外還存放元數據，元數據里有事務信息，這個事務信息通常是用來實現事務的可見性，裡面記錄了最後一次修改的事務ID號。當這個事務ID號足夠老，對於當前所有事務都可見，這個時候我們把事務ID號替換成物理時間戳，這個物理時間戳可以用來表達這行數據最後一次修改的時間是什麼時候，如果這個時間足夠早、足夠老，真正達到了冷的條件，那麼我們就可以對它進行壓縮，用戶可以用非常簡單的邏輯實現冷熱的判定。

第二個例子是，用戶可以自定義冷熱條件，這個行如果長時間沒有做任何修改，系統就可以把它壓縮掉，否則不要碰，這是一個非常簡單的策略。如果客戶業務中有一些欄位有非常清楚的冷熱屬性，比如交易的時間、交易的完成狀態，那可以指定這個欄位進行冷熱判定。或者客戶大部分的交易數據都滿足3個月前的交易是冷數據，但其中某些特殊類型的交易，像擔保交易，可能沒有辦法滿足這個約束，這時候也可以自定義冷熱條件。比如交易狀態必須是完結的，或者交易類型不能是特定類型，通過自定義條件和最近修改時間的組合，可以靈活地定義什麼樣的數據應該壓縮。這是第一點，怎麼做冷熱判定。

關鍵挑戰二：如何對壓縮後的數據有效地存儲？

第二點，壓縮後的目標數據怎麼存。根據總體設計目標，我們希望做到對業務的侵入越低越好。我們選擇了直接做塊內的壓縮：把一個塊內所有滿足冷熱判定的行一次性壓縮完，把壓縮後的數據包就存放在當前數據塊內。這樣做從壓縮率上講並不是最優選擇，但從對業務的影響上講是一個更好的選擇。因為業務即使定義了冷熱判定條件，我們仍有一定的概率會訪問冷數據，我們希望通過塊內壓縮的實現來保證訪問冷數據的代價有一個確定性的上限，這是塊內壓縮的基本思考。

關鍵挑戰三：如何實現有競爭力的壓縮演算法？

為什麼做選擇性壓縮？很簡單，沒有任何一個壓縮演算法能做到數據壓縮之後對業務沒有影響，今天沒有這樣的黑科技，這是我們基本的技術判斷，所以要去平衡壓縮率和對業務的影響。我們首先做的是選擇性壓縮，業務數據分佈滿足典型的80-20分佈政策，80%的數據占有80%的存儲容量，但只消耗了20%的算力。比如銀行交易，隨著時間的推移，整個訂單的訪問頻率會迅速降低，這是非常典型的滿足冷熱特征的業務。

如果做選擇性壓縮，那麼只壓縮那些占用80%存儲容量，但只消耗20%算力的冷數據，就意味著我們在節省存儲成本方面達成了80%的目標；而不去壓縮那些只占用20%的存儲容量，但卻消耗80%算力的熱數據，就意味著我們在降低對用戶的業務影響方面達成了80%的目標，這是非常簡單的技術選擇。

壓縮演算法我們也看了一些，比如LZ4是現在性能最好的演算法，我們一開始用的就是這個演算法，但比較大的問題是壓縮率相對較低。如果仔細去分析演算法原理，LZ4是基於LZ77演算法的一種實現，是把壓縮的數據看成一個連續的位元組流，從當前開始尋找匹配的字元串，找到字元串長度和偏移進行編碼來代替被匹配的字元串，從而實現壓縮的效果。LZ77演算法從原理上講非常適合於長文本，相對不太適合像結構化數據這樣的，裡面有大量的數值類型和短文本，這是資料庫的特征。

我們做了很多優化，比如對數值類型做了差值編碼，所以壓縮框架實際上有兩層，第一層對數據做編碼，第二層用LZ77演算法。原生LZ77演算法有很多優化是面向長文本的，包括3位元組的編碼，我們做了非常多的工程優化，使它更容易面向短文本，比如兩位元組短編碼，包括內置行邊界。這裡我們無法給出很多細節，主要的優化背景其實就兩個：一個是通用壓縮演算法並不特別適合於關係型資料庫結構化數據的場景，二是我們所做的這些工程優化，從通用的壓縮場景來講，並不一定是最優的，但它們是特別適合關係型數據的。

競爭力評估

最後有一個簡單的評估，是通過TPCC和TPCH測試對目前的商用資料庫O*進行的壓縮率評估。O*和我們的GaussDB一樣，也提供了完整的冷熱判定能力，但由於發展原因，它實際上先做了數據壓縮，再做冷熱判定，所以整個壓縮演算法的壓縮率是比較低的；我們使用了標準的TPCH的數據，測試表明我們的壓縮率相對於O*平均提高了50%，這些數據可以被直接驗證。

其他的一些廠商，像開源資料庫，還有國內的廠商都提供了壓縮的解決方案，但共同問題是沒有做冷熱判定，對用戶來講可以指定一個表或一個分區，裡面的數據要麼都被壓縮，要麼都不壓縮。壓縮意味著存儲成本節省，但性能會下降，不壓縮則是另外一個選擇。這個看上去簡單的選擇對客戶來講反而是最難的，這也是為什麼我們看到今天有很多壓縮的解決方案，但用戶卻不會去用，因為誰也不知道開啟壓縮之後有什麼後果，這是比較大的問題。

這裡我們也做了一個標準的TPCC的測試評估，基於GaussDB單機版本進行選擇性壓縮。根據TPCC的語義，所有已經配送完成的訂單就不會再變更，但仍有一定的概率被訪問到，這是非常貼近於真實業務場景的訪問模型。所以，我們的壓縮演算法選擇了壓縮流水類數據，比如訂單數據，而一些狀態類的數據，比如庫存、賬戶等沒有去壓縮，在流水數據里，我們也只壓縮已經配送完成的訂單，不壓縮沒有配送完成的訂單。從最後的結果看，整個壓縮之後對於業務的影響在1.5%左右。我們相信我們是業內第一個在150萬tpmC性能峰值仍然能夠開啟壓縮並且性能基本不下降的產品。

下一步計劃：語義壓縮

我們已經打破了數據編碼和壓縮演算法的邊界，但對壓縮演算法的使用本質上沒有變化，即把整個數據看成是一維的位元組流。但關係數據是兩維的、結構化的數據，所以在數據的行與行之間、列與列之間存在非常豐富的關聯。這種關聯主要來自兩種場景，一種是業務本身在做建模時引入的關聯，比如為了消除連接，數據模型設計成扁平化或低範式化，這會引入非常常見的關聯。第二種是業務服務化改造進行服務的分層，數據在不同的服務分層之間被不斷傳遞而造成的一種關聯。我們通過一些演算法自動發現這種結構化數據之間的關聯，發現這些關聯不是用於商品推薦或者服務治理，而是希望通過消除這些關聯達到壓縮的目的。在很多場景里，這種基於語義的關聯消除技術會比通用演算法提供更好的壓縮效能，這是我們後面會重點去構建競爭力的地方。