Partition Sizing and Management
파티션·청크·part의 크기가 쿼리 성능을 좌우하며, 워크로드 변화에 맞춰 동적으로 관리해야 한다
핵심 개념
대부분의 분석/시계열 스토리지(Cassandra, ClickHouse, TimescaleDB, Iceberg)는 데이터를 파티션/청크/part 단위로 물리적으로 나눈다. 이 단위의 크기는 메모리 working set, pruning 선택성, 압축 효율, 백필 비용, retention 단위를 동시에 좌우한다. 핵심 통찰: “좋은” 파티션 전략은 정적이지 않다 — ingest 증가·워크로드 변화로 day-one에 최적이던 설정이 수개월 후 병목이 된다.
두 가지 실패 모드가 양극단에 있다: wide partition(너무 커서 tail latency 폭발)과 너무 많은 part(메타데이터·planner 오버헤드 폭발).
실패 모드 1 — Wide Partition (Netflix Cassandra)
시계열 데이터가 시간에 따라 누적되며 파티션이 너무 커지면 초 단위 tail latency, 타임아웃, GC pause, thread queueing 발생.
- 테이블 단위 재파티셔닝: 백그라운드 워커가 파티션 히스토그램 모니터 → 설정 density(2~10 MiB) 미달 시 미래 시간 슬라이스의 bucket 간격 조정. 단, 테이블 대부분이 문제일 때만 유효
- ID 단위 동적 분할: 일부 ID만 wide한 경우. 읽기 경로 탐지(바이트 임계 초과 → Kafka 이벤트) → 비동기 split(checkpointing, immutable 우선) → Bloom filter로 투명 라우팅. 원본 파티션은 절대 삭제 안 함(fallback). 결과: tail latency 수 초 → ~200ms
- TimescaleDB chunk 축소: active chunk가 메모리의 ~25%에 맞아야 함(moving target). chunk 30일→7일로 줄이면 압축 lag·백필 비용 감소.
set_chunk_time_interval은 미래 chunk만 영향 → 무중단·가역
실패 모드 2 — 너무 많은 Part (Cloudflare ClickHouse)
파티셔닝 키를 세분화((day)→(namespace, day))하면 쿼리당 읽는 part는 그대로여도 전체 part 개수가 폭증한다. “쿼리당 part 수가 같으니 성능 영향 없다”는 가정이 깨지는 지점:
- query planner가 plan마다 전체 part 리스트에 exclusive lock → 복사 → 필터. 수만 part × 수백 동시 쿼리 = mutex contention(query duration 절반이 대기)
- 진단: query duration vs total part count 상관 + “Real” flame graph(대기 스레드 포함)
- 해법: shared lock(읽기만 하므로) + vector 복사 제거(shared copy 캐시) + binary search(part가 정렬됐음을 활용 → part 개수와 duration 상관 끊음)
공통 원칙
- 정기 재검토: 1년+ 운영했고 파티션/청크 전략을 재검토한 적 없다면 점검 — ingest 증가가 같은 시간 간격을 더 큰 바이트로 만든다
- 미래 단위만 조정 = 안전: 기존 데이터 rewrite 없이 미래 파티션부터 새 전략 적용(Netflix Time Slice, TimescaleDB chunk)이 가장 안전한 knob
- 가정 검증: “part 수가 같으니 성능 동일” 같은 직관은 planner·메타데이터 레이어에서 깨질 수 있음 → flame graph·상관 플롯으로 검증
- 신뢰 구축: 분할/재파티셔닝은 체크섬·shadow 비교·단계적 롤아웃으로 검증(잘못된 읽기는 disastrous)
연관 개념
- Distributed Systems Reliability — wide partition·part 폭증으로 인한 조용한 성능 저하
- Query Optimization — planner·pruning과 직결
- Database Concurrency Control — lock contention과 latch 전략
- Knowledge Graph Infrastructure — Netflix TimeSeries/Graph Abstraction의 파티션 전략
- Catalog-Managed Tables — Iceberg compaction·part 관리
Source: Dynamic Repartitioning for Time Series Workloads at Netflix, ClickHouse Query Plan Lock Contention at Cloudflare, Why We Shrank TimescaleDB Chunks from 30 Days to 7