Why We Shrank Our TimescaleDB Chunks from 30 Days to 7 (WMG/Sodatone)
Author: Yask Srivastava (WMG Lab) | Source: tech.wmg.com | Published: 2026-06-02
한 줄 요약
ingest 증가로 30일 chunk가 메모리·압축·백필을 압박하자 TimescaleDB hypertable의 chunk 간격을 7일로 줄여(미래 chunk만 영향, 무중단·가역) 압축 lag·백필 비용·읽기 성능을 모두 개선.
핵심 주장/내용
- TimescaleDB hypertable = 시간 범위별 작은 테이블(chunk)의 집합. 최근 1개월 쿼리는 최근 chunk만 touch하고 나머지는 pruning으로 skip
- chunk 크기가 영향을 주는 5가지: ① 메모리 working set(active chunk가 shared buffer에 안 맞으면 I/O) ② chunk pruning 선택성 ③ 압축 batch 크기 ④ 백필 비용(압축 chunk 수정 = 압축 해제→적용→재압축) ⑤ retention granularity
- TimescaleDB 권장: active chunk가 메모리의 ~25%에 맞아야 함 — moving target(ingest 증가하면 같은 시간 간격이 더 많은 바이트)
- 증상: 무거운 hypertable에서 압축이 ingest를 못 따라감, 가을 내내 읽기 무거워짐, 업스트림이 수일치 history 재발행할 때마다 수개월치 압축 해제. 9월엔 chunk가 너무 커져 압축 잡 실패
set_chunk_time_interval은 미래 chunk만 영향(기존 chunk rewrite·exclusive lock·백필 없음) → 가장 안전한 knob, 한 줄·가역
주요 수치 / 사실
- 주당 수백만 행, 압축 전 multi-TB
- 7일 chunk는 압축 후 원본의 ~10%로 축소(73GB → ~7,425MB, 90.1% 절감)
- 주의: chunk 많아지면 catalog 행·1년+ rollup planner 작업 증가 → 변경 후 widest 쿼리 재실행 점검
- “1년+ 운영했고 chunk 간격을 재검토한 적 없다면 가서 확인하라 — 마이그레이션은 한 줄, 가역, 미래 chunk만 영향”
관련 위키
Source: 원문 보기