南大通用GBase 8a数据库（gbase database）的存储引擎 Express 是纯列存架构，压缩不是可选功能，而是数据写入的标准流程。理解列存压缩的工作原理，能帮助 DBA 和开发人员在建表时做出更好的数据类型选择，在查询优化时理解 I/O 代价的构成，在容量规划时给出更准确的磁盘估算。本文从列存的基本原理出发，逐一介绍南大通用GBase 8a数据库（gbase database）支持的编码策略和压缩算法，分析不同数据特征下的最优选择，并给出实际测量压缩效果的方法。

一、列存与行存的压缩差异

理解 GBase 8a的压缩机制，首先要理解列存储与行存储在数据组织方式上的根本差异，因为压缩效率的高低直接源于此。

行存储（如 MySQL InnoDB）把一行数据的所有字段连续存放在磁盘上。这种布局对 OLTP 场景友好——读取一整行只需一次顺序 I/O，但压缩效果有限，因为同一行中不同字段的数据类型、值域和重复性各不相同，很难找到统一的压缩规律。

列存储把同一列的所有值连续存放在一起。这个看似简单的改变带来了巨大的压缩优势：同一列的所有值共享相同的数据类型和值域，相邻的值往往高度相似甚至完全相同（比如 dept_id 列中大量相同的部门编号，或者 status 列中只有 0/1/2 三个值），压缩算法可以针对这种同质性做深度优化。

GBase 8a 的实测压缩比通常在 3:1 到 10:1 之间，对于重复度极高的枚举型列（如省份、状态码），压缩比甚至可以超过 20:1。这意味着同样的原始数据，在 GBase 8a 中占用的磁盘空间只有 MySQL 的十分之一甚至更少，这是 MPP 分析型数据库能处理 TB 级数据的重要基础之一。

压缩带来的另一个隐性收益是 查询性能的提升，这一点常常被忽视。因为磁盘读取是按数据块进行的，压缩后同样大小的数据块能装下更多的行，意味着一次磁盘 I/O 可以读取到更多有效数据。在磁盘 I/O 是查询瓶颈的场景下，压缩率越高，查询速度往往也越快。当然，解压缩本身需要消耗 CPU，在 CPU 已经成为瓶颈的场景下，压缩率并非越高越好，需要在 I/O 节省和 CPU 消耗之间找到平衡点。

二、列存的两层压缩体系

GBase 8a 的 Express 引擎对每列数据采用两层压缩：第一层是 编码（Encoding），第二层是通用压缩算法。两层叠加后才是最终存储在磁盘上的数据形态。

这种两层设计的原因在于：编码是针对特定数据模式的"智能变换"，能把原始值转换成更规律、更小的表示形式，为后续的通用压缩算法提供更好的输入；通用压缩算法（如 LZ4、ZSTD）则负责在编码输出的基础上做进一步的字节级压缩。两者结合，比单独使用任何一种效果都好。

第一层：编码策略

字典编码（Dictionary Encoding）是最常用的编码方式，适合低基数列——即唯一值数量远小于总行数的列。字典编码的原理是：先把列中所有出现过的唯一值建立一个字典（如 {0: "active", 1: "inactive", 2: "pending"}），然后把每行的值替换为对应的字典索引（一个很小的整数）。字典索引通常只需要 1~2 个字节，而原始字符串可能需要 10 多个字节，压缩效果立竿见影。

status、province、dept_id、gender 这类列是字典编码的理想对象。GBase 8a 的 Express 引擎会自动检测列的基数，对符合条件的列自动应用字典编码，不需要手动配置。

行程编码（Run-Length Encoding，RLE）专为有大量连续重复值的列设计。比如按时间顺序排列的数据中，order_date 列往往有大量连续相同的日期（同一天的订单聚集在一起）；按部门排列的数据中，dept_id 可能有几千行连续相同。RLE 把连续重复的值记录为"(值, 重复次数)"的形式，大量连续重复时压缩率极高。

差值编码（Delta Encoding）适合单调递增或变化幅度较小的数值列，如自增 ID、时间戳序列。差值编码存储相邻两个值的差而非原始值。如果 order_id 从 1 连续递增到 10 亿，差值始终是 1，整列只需存储起始值和"差值=1"这条信息，压缩率接近极限。

第二层：通用压缩算法

在编码之后，GBase 8a 会对数据块进一步应用通用压缩算法。常见选项是 LZ4 和 ZSTD：LZ4 的压缩和解压速度极快，CPU 开销极小，但压缩率中等；ZSTD 的压缩率更高，CPU 开销相对较大，但在现代多核 CPU 上通常仍在可接受范围内。对于 I/O 密集型场景（磁盘慢、网络慢），优先选 ZSTD；对于 CPU 密集型场景（大量并发查询），优先选 LZ4。