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

以下為演講實錄：

各位嘉賓，大家下午好！很高興由我開始給大家?guī)斫衲闓aussDB一系列新特性的技術解讀。我解讀的是第一個特性，高級壓縮。

GaussDB高級壓縮全景

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

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

典型場景和目標設計

不同的場景對于壓縮算法，包括壓縮率、業(yè)務影響、業(yè)務侵入容忍度是不一樣的。這里要介紹的，是我們第一個發(fā)布的OLTP表壓縮的技術細節(jié)。講這個之前，先講一下OLTP表壓縮究竟解決的是什么樣的客戶場景，這決定了我們整個技術目標。

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

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

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

關鍵挑戰(zhàn)一：如何判定業(yè)務的冷熱數據？

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

我們做冷熱判定，首先是確定判定的粒度?？梢园凑毡?、分區(qū)、塊來判定，也可以按照行來判定。判定的粒度越細，意味著對業(yè)務的侵入越低，對業(yè)務整個數據分布沒有任何假設，當然實現的挑戰(zhàn)也越大?；谖覀兌x的技術目標，在做OLTP表壓縮時，第一個目標就是冷熱判定必須是行級別的，這樣對業(yè)務的侵入是最小的。

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

第二個例子是，用戶可以自定義冷熱條件，這個行如果長時間沒有做任何修改，系統(tǒng)就可以把它壓縮掉，否則不要碰，這是一個非常簡單的策略。如果客戶業(yè)務中有一些字段有非常清楚的冷熱屬性，比如交易的時間、交易的完成狀態(tài)，那可以指定這個字段進行冷熱判定?；蛘呖蛻舸蟛糠值慕灰讛祿紳M足3個月前的交易是冷數據，但其中某些特殊類型的交易，像擔保交易，可能沒有辦法滿足這個約束，這時候也可以自定義冷熱條件。比如交易狀態(tài)必須是完結的，或者交易類型不能是特定類型，通過自定義條件和最近修改時間的組合，可以靈活地定義什么樣的數據應該壓縮。這是第一點，怎么做冷熱判定。

關鍵挑戰(zhàn)二：如何對壓縮后的數據有效地存儲？

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

關鍵挑戰(zhàn)三：如何實現有競爭力的壓縮算法？

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

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

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

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

競爭力評估

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

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

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

下一步計劃：語義壓縮

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

小結

為什么做高級壓縮的特性？因為我們希望在三個領域實現業(yè)內領先。

• 一是在性能敏感場景，在提供合理的壓縮率的前提下，對業(yè)務的影響（越小越好）實現業(yè)內領先。

• 二是在成本敏感的場景，在提供合理的壓縮解壓性能的前提下，壓縮率（越高越好）實現業(yè)內領先。

• 第三，大家可能注意到，冷熱判定本身不僅可以做數據壓縮，還可以做很多別的工作，比如多存儲介質、負載的感知，我們希望對于整個冷熱判定，包括模型及方法，在能夠支持的業(yè)務領域的廣度方面，能夠做到業(yè)內領先，這是我們做高級壓縮特性的一個基本目的。