南大通用GBase 8a數(shù)據(jù)庫（gbase database）的存儲引擎 Express 是純列存架構(gòu)，壓縮不是可選功能，而是數(shù)據(jù)寫入的標準流程。理解列存壓縮的工作原理，能幫助 DBA 和開發(fā)人員在建表時做出更好的數(shù)據(jù)類型選擇，在查詢優(yōu)化時理解 I/O 代價的構(gòu)成，在容量規(guī)劃時給出更準確的磁盤估算。本文繼續(xù)介紹GBase 8a數(shù)據(jù)庫（gbase database）在不同數(shù)據(jù)特征下的最優(yōu)選擇，并給出實際測量壓縮效果的方法。

三、影響壓縮效果的設(shè)計決策

理解了壓縮原理，就能在日常建表和查詢設(shè)計中做出更有意識的選擇，而不是把壓縮當(dāng)作黑盒。

數(shù)據(jù)類型的影響是最直接的。用?TINYINT（1 字節(jié)）存 0~255 范圍的枚舉值，遠比用?VARCHAR(20)?存 "active"/"inactive" 壓縮效果好——不僅字典編碼的字典更小，差值編碼也更高效。用?DATE?存日期而不是?VARCHAR(10)?存 "2024-06-01"，列存引擎可以用專門的日期編碼，壓縮率和查詢時的日期計算性能都更好。用數(shù)值類型存 ID，而不是字符串類型，是同樣的道理。

寫入順序的影響往往被忽略。列存引擎的 RLE 編碼對連續(xù)相同值的效果極好，這意味著如果數(shù)據(jù)按?dept_id?或?order_date?排序?qū)懭?，同一部門或同一日期的數(shù)據(jù)聚集在一起，RLE 的壓縮率會顯著高于隨機順序?qū)懭氲那闆r。在 gload 的配置文件中，如果源數(shù)據(jù)已經(jīng)按某列有序，可以在配置中聲明排序列，讓引擎利用這個信息優(yōu)化編碼。

列的基數(shù)選擇在分布鍵設(shè)計時已經(jīng)討論過，但它同樣影響壓縮效率。用?customer_id（千萬級唯一值）做分布鍵后，該列在每個 gnode 上的局部分布仍然有較高基數(shù)，字典編碼的收益有限；但?dept_id（百級唯一值）的壓縮率就會高得多。這不意味著要為了壓縮率去選擇低基數(shù)列作為分布鍵，而是說在做容量規(guī)劃時，高基數(shù)分布鍵列的壓縮率要按偏低估算，低基數(shù)列按偏高估算，這樣整體容量估算會更準確。

四、實測壓縮效果

在生產(chǎn)環(huán)境中，最準確的壓縮率數(shù)據(jù)來自實際測量，而非公式估算。

通過分列查看，可以發(fā)現(xiàn)哪些列的壓縮率遠低于預(yù)期，進而檢查這些列的數(shù)據(jù)類型是否合理（比如用 VARCHAR 存了應(yīng)該是 INT 的值），或者數(shù)據(jù)分布是否真的是高基數(shù)、高隨機性的（這種情況下低壓縮率是正常的，無需優(yōu)化）。

對于即將上線的新系統(tǒng)，建議在上線前用部分生產(chǎn)數(shù)據(jù)做壓縮率摸底測試，把實測的壓縮比代入容量規(guī)劃公式，這比用經(jīng)驗值（"按 5:1 算"）要準確得多。

五、常見誤區(qū)

誤區(qū)一：壓縮率越高查詢越快。?壓縮率提升減少了 I/O 量，在 I/O 是瓶頸時確實能加速查詢。但如果 CPU 是瓶頸，更高的壓縮率意味著更多的解壓 CPU 開銷，反而可能導(dǎo)致查詢變慢。需要結(jié)合實際的資源瓶頸位置來判斷。

誤區(qū)二：用字符串存數(shù)值不影響壓縮。?字符串 "12345678" 需要 8 個字節(jié)，而 INT 類型的 12345678 只需要 4 個字節(jié)，且 INT 類型可以使用差值編碼進一步壓縮，字符串類型不行。用錯數(shù)據(jù)類型不僅浪費存儲，還會讓特定的編碼優(yōu)化失效。

誤區(qū)三：壓縮是 DBA 的事，與開發(fā)無關(guān)。?開發(fā)人員選擇的數(shù)據(jù)類型和寫入順序直接影響壓縮效率。用?TINYINT?還是?VARCHAR?存 status，壓縮率可能相差 5 倍，查詢時的解壓開銷也相差同等倍數(shù)。把壓縮效率的考量納入代碼審查和表設(shè)計評審，是提升整體系統(tǒng)效率的有效手段。