解读

国内线上业务普遍面临“数据膨胀→存储成本飙升→领导要求降本”与“用户体验→RT 必须稳定→领导要求保 SLA”的双重 KPI。压缩比 90% 意味着 1 TB 原始数据落到 100 GB，直接带来：

1. 云盘/对象存储费用下降 70% 以上（含备份、跨 AZ 副本）。
2. 内存缓存命中率提升，Page Cache 可缓存更多热数据。
3. 网络传输量下降，跨区域同步带宽费减少。

但实测 RT 翻倍，说明解压/重构、向量化过滤、索引失配或 I/O 放大抵消了存储红利。面试时，面试官想听到“可量化的权衡公式 + 可落地的分级方案 + 可回退的兜底策略”，而不是一句“看业务场景”。

知识点

1. TimescaleDB 原生压缩（native compression）机制
   – 按 chunk 级触发，行列混合转列存（Array 化），LZ 压缩，元数据保留 min/max 作为 Segment Meta。
   – 解压粒度为 1000 行一批，不支持行级索引，仅支持 Segment-level Skip Index。
2. 查询 RT 放大根因
   a. CPU：批量解压 + 反序列化 Array 占 30–50% CPU。
   b. I/O：压缩后 10% 体积，但随机点查需整块解压→I/O 放大 8–40 倍。
   c. 计划器：压缩 chunk 无法使用 B-tree，导致 Bitmap Scan 退化为 Seq Decompress Scan。
3. 国内公有云成本模型（华北 2 2024Q2 报价）
   – PL1 SSD 云盘 1 TB·月 680 元；
   – 同样容量 OSS 标准 120 元，低频 60 元；
   – 4 vCPU 实例单价 0.32 元/分钟，CPU 利用率每提升 10%≈1800 元/月。
   由此可把“RT↑”换算成“需要多加多少台只读节点”或“缓存层费用”。
4. SLA 分级
   – P0 接口：RT p99 < 500 ms，全年可用性 99.95%；
   – P2 报表：RT p99 < 5 s，可用性 99%。
   不同分级允许不同压缩策略。
5. 国内合规要求
   – 日志/轨迹数据保存 ≥ 6 个月，可接受 RT 劣化；
   – 交易流水需实时索引，不允许 RT 翻倍。

答案

“我会把决策拆成四步，输出一张可量化的权衡表，让老板在‘省多少钱’与‘加多少机器’之间一眼看懂。

第一步，量化收益

1. 存储成本：原 10 TB PL1 云盘月费 6.8 万 → 压缩后 1 TB 月费 0.68 万，节省 6.12 万/月。
2. 备份、跨区同步带宽：按 0.8 元/GB 算，再省 1.1 万/月。
   合计月省 7.2 万，年省 86 万。

第二步，量化代价
RT 翻倍后，P0 查询 p99 从 400 ms 涨到 800 ms，触碰 SLA 红线。
压测得出 CPU 增加 35%，为了保持 p99 < 500 ms，需把只读节点从 4 台扩到 6 台。
4 vCPU 16 G 实例单价 0.32 元/分钟，全年额外 2×0.32×60×24×365 ≈ 33.6 万。
净收益 = 86 – 33.6 = 52.4 万/年，ROI 仍 >150%，值得做。

第三步，分级落地

1. 热数据层：近 7 天 chunk 不压缩，保持 B-tree，保障 P0 接口。
2. 温数据层：7–30 天 chunk 开压缩，但预先建 BRIN 索引 + 自定义 Skip Index，把点查 RT 控制在 +30% 以内。
3. 冷数据层：30 天以上 chunk 全压缩，并转存 OSS，通过 pg_prewarm 把当天报表常用分区提前拉到本地 NVMe 缓存池，RT 允许 +100%。
4. 回退方案：若大促期间流量翻倍，通过 timescaledb_decompress_chunk() 秒级回滚指定 chunk，全程灰度，无需重启。

第四步，监控与闭环

1. 把‘压缩率、解压 CPU%、RT p99、存储费用’四个指标打到 Prometheus，用 Grafana 建 ROI 看板，每周review。
2. 设定阈值：RT p99 > 600 ms 或 CPU decompress > 40% 持续 5 min，自动触发扩容并告警。
3. 每季度做一次压缩算法基准测试，TimescaleDB 新版若支持 ZSTD 流式解压，可再降 15% CPU，继续优化收益。

结论：在现有 SLA 与成本模型下，90% 压缩比带来的 52 万年净收益大于扩容开销，可以接受 RT 翻倍，但通过热-温-冷分级策略，把翻倍局限在冷数据，实际对用户体验无感。”

拓展思考

1. 如果领导明年把 SLA 收紧到 p99 < 300 ms，上述分级收益会被吃掉，需要引入“部分解压”方案：把压缩 chunk 再按小时做稀疏索引，或者把 TimescaleDB 的 Continuous Aggregate 预先物化指标，查询直接走物化视图，绕过解压。
2. 国内金融合规要求“原始明细不可丢”，但允许“冷热分离”。可以考虑压缩后把冷 chunk 转存到私有云 HDFS + ORC，查询走 Trino 联邦，把存储成本压到 30 元/TB·月，同时利用 Trino 的列批处理把 RT 控制在 1 s 内，实现“极冷数据”的再分级。
3. 未来 TimescaleDB 推出 Custom Scan API 后，可自研 GPU 解压插件，把解压延迟从 120 ms 降到 20 ms，届时可在热数据层也开启压缩，进一步节省 40% 成本，这是后续技术预研方向。