PolarDB 中的数据压缩：表压缩与页压缩的性能对比与配置方法

一、为什么需要数据压缩？

在数据库的世界里，存储空间就像你手机的内存一样珍贵。随着业务数据不断膨胀，你会发现数据库占用的空间越来越大，查询速度却越来越慢。这时候数据压缩技术就像给你的数据库装了个"瘦身神器"，既能节省存储成本，又能提升I/O性能。

PolarDB作为阿里云推出的云原生数据库，提供了两种主流的压缩方式：表压缩和页压缩。它们就像减肥的两种不同方法 - 一种是全身减脂（表压缩），一种是局部塑形（页压缩）。接下来我们就来详细对比这两种方法的实际效果。

二、表压缩深度解析

表压缩是PolarDB中的"重量级"压缩方案，它会对整张表的数据进行压缩处理。这就好比你把冬天的羽绒服全部塞进真空压缩袋，可以大幅减少占用空间。

让我们通过一个实际例子来看看如何在PolarDB中创建压缩表（技术栈：PolarDB PostgreSQL）：

-- 创建压缩表示例
CREATE TABLE sales_compressed (
    id SERIAL PRIMARY KEY,
    order_date DATE NOT NULL,
    customer_id INT NOT NULL,
    product_id INT NOT NULL,
    quantity INT NOT NULL,
    amount DECIMAL(10,2) NOT NULL
) WITH (
    COMPRESSION = 'pglz'  -- 使用PolarDB的压缩算法
);

-- 插入测试数据
INSERT INTO sales_compressed (order_date, customer_id, product_id, quantity, amount)
SELECT 
    CURRENT_DATE - (random()*365)::integer,
    (random()*1000)::integer,
    (random()*100)::integer,
    (random()*10)::integer,
    (random()*1000)::numeric(10,2)
FROM generate_series(1, 1000000);

-- 查看压缩效果
SELECT pg_size_pretty(pg_total_relation_size('sales_compressed')) AS compressed_size;

表压缩的优点非常明显：

压缩比高，通常能达到3-5倍的压缩率
对批量扫描操作特别友好，因为数据在磁盘上就是压缩状态
减少备份存储空间和网络传输量

但它的缺点也不容忽视：

写入时需要额外的CPU资源进行压缩
单条记录查询时需要解压整块数据
不适合频繁更新的表

三、页压缩技术详解

页压缩是PolarDB中的另一种压缩方式，它以数据页为单位进行压缩。这就像是你把衣服一件件叠好放进抽屉，虽然不如真空压缩那么节省空间，但拿取更方便。

下面我们看看页压缩的实际应用（技术栈：PolarDB MySQL）：

-- 创建页压缩表
CREATE TABLE log_entries (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    timestamp DATETIME NOT NULL,
    user_id INT NOT NULL,
    action VARCHAR(50) NOT NULL,
    details TEXT,
    KEY idx_timestamp (timestamp)
) COMPRESSION='ZLIB'  -- 使用ZLIB压缩算法
  ROW_FORMAT=COMPRESSED
  KEY_BLOCK_SIZE=8;   -- 设置压缩页大小

-- 插入测试数据
INSERT INTO log_entries (timestamp, user_id, action, details)
VALUES 
    (NOW(), 1001, 'login', 'User logged in from IP 192.168.1.1'),
    (NOW(), 1001, 'view_page', 'Viewed product ID 305'),
    (NOW(), 1002, 'search', 'Searched for "wireless headphones"');

-- 查看压缩信息
SELECT 
    table_name AS "表名",
    table_rows AS "行数",
    avg_row_length AS "平均行长度",
    data_length AS "数据长度",
    index_length AS "索引长度",
    round((data_length + index_length) / 1024 / 1024, 2) AS "总大小(MB)"
FROM information_schema.tables
WHERE table_schema = DATABASE() AND table_name = 'log_entries';

页压缩的特点包括：

压缩粒度更细，以页为单位（通常8KB或16KB）
随机读写性能更好，因为只需要解压单个页
支持在线调整压缩参数

但同样存在一些限制：

压缩比通常低于表压缩
需要额外的内存缓冲解压后的数据
对非常小的行效果不明显

四、性能对比与实战测试

为了更直观地比较两种压缩方式的性能差异，我们设计了一个测试场景（技术栈：PolarDB PostgreSQL）：

-- 测试准备：创建两个结构相同但压缩方式不同的表
CREATE TABLE uncompressed_table (
    id SERIAL PRIMARY KEY,
    data JSONB NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE table_compressed (
    id SERIAL PRIMARY KEY,
    data JSONB NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
) WITH (COMPRESSION = 'pglz');

CREATE TABLE page_compressed (
    id SERIAL PRIMARY KEY,
    data JSONB NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
) WITH (COMPRESSION = 'pglz', FILLFACTOR = 80);

-- 插入100万条测试数据
INSERT INTO uncompressed_table (data)
SELECT jsonb_build_object(
    'user_id', (random()*10000)::integer,
    'action', CASE (random()*5)::integer
        WHEN 0 THEN 'login'
        WHEN 1 THEN 'purchase'
        WHEN 2 THEN 'view'
        WHEN 3 THEN 'search'
        ELSE 'logout' END,
    'value', (random()*1000)::numeric(10,2)
)
FROM generate_series(1, 1000000);

-- 复制数据到压缩表
INSERT INTO table_compressed SELECT * FROM uncompressed_table;
INSERT INTO page_compressed SELECT * FROM uncompressed_table;

-- 测试查询性能
EXPLAIN ANALYZE SELECT COUNT(*) FROM uncompressed_table WHERE data @> '{"action": "purchase"}';
EXPLAIN ANALYZE SELECT COUNT(*) FROM table_compressed WHERE data @> '{"action": "purchase"}';
EXPLAIN ANALYZE SELECT COUNT(*) FROM page_compressed WHERE data @> '{"action": "purchase"}';

-- 测试更新性能
EXPLAIN ANALYZE UPDATE uncompressed_table SET data = jsonb_set(data, '{value}', '999.99'::jsonb) WHERE id = 500000;
EXPLAIN ANALYZE UPDATE table_compressed SET data = jsonb_set(data, '{value}', '999.99'::jsonb) WHERE id = 500000;
EXPLAIN ANALYZE UPDATE page_compressed SET data = jsonb_set(data, '{value}', '999.99'::jsonb) WHERE id = 500000;

从测试结果来看：

存储空间：表压缩节省最多，页压缩次之，未压缩表最大
全表扫描：表压缩最快，因为I/O负载最低
点查询：页压缩表现最好，表压缩因需要解压大块数据而稍慢
更新操作：页压缩最灵活，表压缩需要重写整个压缩块

五、配置建议与最佳实践

根据实际经验，我总结了以下配置建议：

表压缩最适合的场景：

数据仓库或分析型应用
主要进行批量读取操作
数据写入后很少更新

示例配置：

CREATE TABLE analytics_data (
    id BIGSERIAL PRIMARY KEY,
    event_time TIMESTAMPTZ,
    metrics JSONB
) WITH (
    COMPRESSION = 'pglz',
    AUTOVACUUM_ENABLED = ON,
    FILLFACTOR = 100
);

页压缩最适合的场景：

OLTP系统，频繁随机读写
需要平衡读写性能
表中有大量文本或JSON数据

示例配置：

CREATE TABLE user_activities (
    user_id INT,
    activity_time TIMESTAMPTZ,
    activity_details TEXT,
    PRIMARY KEY (user_id, activity_time)
) WITH (
    COMPRESSION = 'pglz',
    FILLFACTOR = 80
);

通用优化建议：
- 压缩表上创建适当的索引
- 监控CPU使用率，避免压缩导致过载
- 对大表考虑分区+压缩的组合策略
- 定期分析表以优化压缩效果

六、常见问题与解决方案

在实际使用中，可能会遇到以下问题：

压缩效果不明显：
- 检查数据类型，文本/JSON压缩效果好，已压缩数据（如图片）效果差
- 调整FILLFACTOR参数，给更新操作留空间
- 考虑使用列存格式进一步提高压缩率
查询性能下降：
- 确保有足够的work_mem供解压操作使用
- 对压缩表避免全表扫描，使用索引查询
- 考虑使用部分索引减少索引大小
写入速度变慢：
- 评估服务器CPU资源是否充足
- 考虑在业务低峰期进行批量加载
- 测试不同压缩算法(pglz/lz4/zstd)的性能差异

七、未来发展与总结

随着硬件技术的发展，数据压缩技术也在不断进化。PolarDB已经支持智能压缩策略，可以根据访问模式自动调整压缩级别。未来我们可能会看到：

自适应压缩：根据数据特征自动选择最佳压缩算法
硬件加速：使用专用处理器加速压缩/解压操作
混合压缩：同一表中不同列使用不同压缩策略

总结一下选择压缩策略的关键点：

表压缩适合"读多写少"的大数据量场景
页压缩适合需要平衡读写性能的OLTP场景
压缩可以显著节省存储，但需要权衡CPU开销
正确的配置和监控是发挥压缩效果的关键

敲码拾光专注于编程技术，涵盖编程语言、代码实战案例、软件开发技巧、IT前沿技术、编程开发工具，是您提升技术能力的优质网络平台。