TimescaleDB手动压缩后磁盘空间未减少 执行vacuum无效问题咨询

可能成因 #

• 压缩参数配置错误：你当前将高基数的时间戳字段insert_time_stamp设为compress_segmentby，该参数用于划分压缩数据分组，字段基数过高会导致每个分组数据量极小，额外存储的压缩元数据占用甚至超过压缩节省的空间，最终出现压缩后体积膨胀。
• 旧chunk未被及时回收：压缩操作会生成新的压缩chunk，原有的未压缩chunk仅被标记为待删除，不会立即释放磁盘空间。普通VACUUM仅标记空间可复用，不会将空闲空间返还给操作系统，因此看不到磁盘可用空间上升。如果压缩生成的新chunk体积超过已标记可复用的空间，就会出现磁盘可用空间反而下降的情况。
• 长事务阻塞垃圾回收：如果存在运行时间超过压缩操作的长事务，会持有旧chunk的快照，导致废弃的未压缩chunk无法被后台回收进程清理。
• 待压缩数据无压缩空间：如果存储的是已经压缩过的二进制数据（比如图片、压缩包、编码后的监控数据），二次压缩不会节省空间，反而会增加元数据开销导致体积上升。

解决方案 #

1. 修正压缩参数配置 #

时间戳类高基数字段应设置为compress_orderby而非compress_segmentby，compress_segmentby仅用于低基数的分组字段（如设备ID、业务类型等），示例配置如下：

-- 先解压之前错误压缩的chunk
SELECT decompress_chunk(i) FROM show_chunks('data_table', older_than => INTERVAL '10 days') i;
-- 重置压缩配置，将insert_time_stamp设为排序字段，按需设置低基数segmentby字段
ALTER TABLE data_table SET (
  timescaledb.compress,
  timescaledb.compress_orderby = 'insert_time_stamp DESC'
  -- 若有低基数分组需求可新增参数 timescaledb.compress_segmentby = '你的低基数字段名'
);
-- 重新执行压缩
SELECT compress_chunk(i) FROM show_chunks('data_table', older_than => INTERVAL '10 days') i;

2. 清理废弃chunk释放磁盘空间 #

首先清理阻塞回收的长事务：

-- 查询运行超过1小时的空闲事务，确认后可手动终止
SELECT pid, query, xact_start FROM pg_stat_activity 
WHERE state = 'idle in transaction' AND xact_start < NOW() - INTERVAL '1 hour';

业务低峰期执行全表VACUUM FULL将空闲空间返还给操作系统：

-- 该操作会锁表，禁止在业务高峰期执行
VACUUM FULL data_table;

如果需要在线无锁回收，可使用pg_repack工具操作。

3. 验证压缩效果 #

执行以下查询确认压缩率是否符合预期：

SELECT 
  chunk_table,
  pg_size_pretty(before_compression_total_bytes) AS 压缩前体积,
  pg_size_pretty(after_compression_total_bytes) AS 压缩后体积,
  ROUND((1 - after_compression_total_bytes::NUMERIC / before_compression_total_bytes::NUMERIC) * 100, 2) AS 压缩率
FROM timescaledb_information.chunks 
WHERE hypertable_name = 'data_table' AND is_compressed = TRUE;

合理配置下时序类数据的压缩率通常可达80%~95%。

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