如何提升TimescaleDB压缩率？与Brotli Parquet对比优化

首先明确核心差异：Parquet是列式存储格式，配合Brotli压缩对结构化时序数据的压缩效率天然高于TimescaleDB基于PostgreSQL行存的传统压缩。但通过以下调整，可以大幅缩小两者的压缩差距：

1. 切换为更高效的压缩算法 #

TimescaleDB默认使用pglz压缩，换成ZSTD或LZ4能显著提升压缩率，其中ZSTD的压缩比接近Brotli，且性能损耗可控。

-- 修改表的压缩算法为ZSTD（支持级别调整，例如zstd:10，级别1-19，越高压缩率越高）
ALTER TABLE sensor_data
SET (timescaledb.compress_algorithm = 'zstd');

-- 重新压缩已有的chunk（true表示强制重压缩）
SELECT compress_chunk(c, true) FROM show_chunks('sensor_data') c;

2. 优化字段类型，减少单条记录体积 #

你当前使用NUMERIC(20,3)存储sensor_value，如果数据范围允许，替换为更紧凑的类型：

• 若数值精度要求在单精度范围内，用FLOAT4（4字节）替代NUMERIC(20,3)（最多13字节）
• 若需要精确小数，用DECIMAL(10,3)替代NUMERIC(20,3)（减少存储字节数）

-- 示例：切换为FLOAT4，需先确认数据无溢出
ALTER TABLE sensor_data ALTER COLUMN sensor_value TYPE FLOAT4;

3. 启用列式压缩（TimescaleDB 2.0+） #

这是缩小与Parquet压缩差距的关键——TimescaleDB的列式压缩会将chunk内数据按列存储后再压缩，逻辑与Parquet对齐，能大幅提升压缩率。

ALTER TABLE sensor_data
SET (
  timescaledb.compress,
  timescaledb.compress_segmentby='sensor_id',
  timescaledb.compress_orderby='time',
  timescaledb.compress_format = 'columnar' -- 启用列式压缩
);

-- 重压缩所有chunk
SELECT compress_chunk(c, true) FROM show_chunks('sensor_data') c;

4. 调整Chunk大小匹配数据粒度 #

你的数据每小时约90万条记录（250条/秒 × 3600秒），将默认1天的Chunk大小改为1小时，让每个Chunk内的数据更紧凑，压缩算法能更好地识别重复模式：

-- 若Hypertable已创建，拆分现有Chunk为1小时粒度（需停机维护，建议先在测试环境验证）
SELECT split_chunk(chunk, INTERVAL '1 hour') FROM show_chunks('sensor_data') chunk;

-- 新建Hypertable时直接指定Chunk大小
SELECT create_hypertable('sensor_data', 'time', chunk_time_interval => INTERVAL '1 hour');

5. 清理冗余索引与约束 #

多余的索引会占用额外存储空间，即使压缩后也会增加体积。仅保留查询必需的索引，例如(time, sensor_id)复合索引，删除不必要的单列索引或约束。

是否已达最优水平？ #

如果已经启用列式压缩+ZSTD高压缩级别，且字段类型已优化到最小可行范围，此时的压缩率已接近TimescaleDB的理论最优。由于TimescaleDB是数据库，需要兼顾随机查询、事务、数据更新等特性，无法完全达到Parquet这种纯存储格式的压缩率（Parquet无需支持数据库的复杂操作，可做更极端的存储优化）。

内容的提问来源于stack exchange，提问作者EllipticalInitial