Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

프롤로그 — 시계열은 왜 별도 DB가 필요한가

2026년 신입 백엔드 엔지니어가 처음 마주치는 환상: "메트릭? Postgres에 timestamp 컬럼 만들고 INSERT 하면 되겠지."

3개월 뒤 현실: 1초에 10만 개 메트릭이 들어오는데 Postgres가 디스크 I/O로 죽고, 인덱스는 매일 10GB씩 부풀고, `SELECT avg(value) FROM metrics WHERE time > now() - interval '1 hour' GROUP BY tag` 한 줄이 90초 걸리고, 30일치 보관하려니 NVMe 한 대로 부족하다.

**시계열 데이터(time-series data)는 일반 OLTP 데이터와 근본적으로 다르다.** 차이는 네 가지다.

- **Append-heavy** — 99.9%가 INSERT, UPDATE는 거의 없다. 새 행은 항상 "now"에 추가된다.

- **시간 순서(time-ordered)** — 데이터는 시간축으로 정렬되어 도착하고, 쿼리도 시간 범위가 거의 항상 들어간다.

- **다운샘플링(downsample)** — 최근 1시간은 1초 해상도, 어제는 1분 해상도, 작년은 1시간 해상도. 시간이 지날수록 정밀도를 떨어뜨려도 된다.

- **보관 정책(retention)** — 30일 후 자동 삭제. 365일짜리 롤업만 유지.

이 네 가지 특성을 활용해 만든 게 **시계열 데이터베이스(TSDB)**다. 같은 메트릭 1조 행을 Postgres에 넣으면 10TB가 필요하지만, InfluxDB나 ClickHouse에는 300GB로 들어간다. **압축비 30배, 쿼리 속도 100배** — 이게 별도 DB가 필요한 이유다.

이 글은 2026년 5월 기준 시계열 DB 풀스택을 해부한다. InfluxDB 3.0의 Rust 리라이트부터 TimescaleDB hypertables, ClickHouse MergeTree, Prometheus 3.0, VictoriaMetrics 1.110+, Grafana Mimir·Cortex·Thanos, TDengine·GreptimeDB까지.

1장 · 시계열 데이터의 5가지 특성

**1. Time-ordered append.** 거의 모든 쓰기가 단조 증가하는 timestamp와 함께 들어온다. 정렬된 데이터는 압축이 잘 되고, B-tree보다 LSM-tree나 column-store가 적합하다.

**2. High cardinality.** "1초에 10만 개 메트릭"의 실체는 (host, region, container, pod, namespace) 같은 라벨 조합 폭발이다. 라벨이 5개고 각각 100가지 값을 가지면 카디널리티는 10^10 — 이게 TSDB의 #1 스케일링 문제다.

**3. Compression-friendly.** 인접 값들이 비슷하다. CPU 사용률은 73.2, 73.3, 73.1처럼 미세하게 흔들린다. Gorilla XOR 인코딩, delta-of-delta, ZSTD를 조합하면 30~50배 압축이 가능하다.

**4. Range queries dominate.** "지난 1시간 평균", "어제 9~10시 max", "이번 달 percentile 95" — 시간 범위 + 집계 함수가 패턴의 99%다. Point lookup은 거의 없다.

**5. Downsample-able.** 1초 해상도 데이터를 1분, 1시간, 1일로 롤업하면서 원본을 삭제해도 분석에 큰 손실이 없다. 이게 **연속 집계(continuous aggregate)** 또는 **머터리얼라이즈드 뷰(materialized view)**가 핵심 기능인 이유다.

이 다섯 가지를 어떻게 잘 다루느냐가 TSDB의 차별점이다.

2장 · TSDB 시장 지도 — 6개 진영

2026년 시계열 DB 시장을 큰 그림으로 정리하면 여섯 진영이다.

**1. Influx 진영.** InfluxDB 3.0/3.1 (Rust + Arrow + Parquet), InfluxDB 1.x/2.x (TSM + Flux). 가장 오래된 전용 TSDB.

**2. Postgres 확장 진영.** TimescaleDB 2.18 (Timescale Inc → 2025년 TigerData로 리브랜딩). 관계형 + 시계열 하이브리드.

**3. ClickHouse 진영.** ClickHouse 25.x — 원래는 OLAP인데 사실상 가장 많이 쓰이는 "비공식" TSDB. Yandex가 만들었고 ClickHouse Inc.가 상용화.

**4. Prometheus 생태계.** Prometheus 3.0 (CNCF) + VictoriaMetrics 1.110+ + Grafana Mimir + Cortex + Thanos. 모니터링 메트릭에 특화.

**5. 신생 진영.** QuestDB 8.x (SIMD), GreptimeDB (Rust + cloud-native), TDengine (중국 IoT), CrateDB (분산 SQL).

**6. OLAP 인접 진영.** Apache Druid, Apache Pinot, StarRocks — 원래는 OLAP인데 시계열 워크로드도 처리한다.

여기에 **상용 SaaS** (Datadog, New Relic, Splunk, Honeycomb, Lightstep) 가 별도 계층으로 존재한다. 이건 "DB"라기보다 "관측성 플랫폼"이다.

진영을 외워두면 의사결정이 빨라진다. **메트릭 모니터링은 Prometheus 생태계, IoT/금융 틱은 InfluxDB·QuestDB, BI 분석 겸용은 ClickHouse·TimescaleDB**가 기본 매핑이다.

3장 · InfluxDB 1.x / 2.x — TSM 시대의 유산

InfluxDB는 2013년 출시된 1세대 전용 TSDB다.

**1.x (2016~2020).** TSM(Time-Structured Merge tree) 엔진. InfluxQL 쿼리 언어 (SQL 비슷). 단일 노드. Telegraf로 수집 → InfluxDB 저장 → Chronograf로 시각화 → Kapacitor로 알림. 이른바 TICK 스택.

**2.x (2020~2024).** TSM + 자체 키-값 인덱스. Flux 언어 (함수형 데이터 파이프라인). UI 통합, 토큰 인증, 태스크 스케줄러. Cloud 1세대.

**Flux 언어 예시.**

from(bucket: "metrics")

|> range(start: -1h)

|> filter(fn: (r) => r._measurement == "cpu")

|> filter(fn: (r) => r._field == "usage_user")

|> aggregateWindow(every: 1m, fn: mean)

|> yield(name: "mean_cpu")

**문제.** Flux는 학습 곡선이 가팔랐다. SQL을 아는 데이터 엔지니어가 Flux를 다시 배워야 했다. 인덱스도 카디널리티 100만이 넘으면 성능이 무너졌다. Clustering(분산)은 엔터프라이즈에서만 제공.

2024년에 InfluxDB Inc.(Influx Data)는 **TSM과 Flux를 버리고 처음부터 다시 쓰기로 결정**했다. 그 결과가 3.0이다. **1.x/2.x는 레거시**가 됐고, 신규 프로젝트는 3.0을 써야 한다.

4장 · InfluxDB 3.0 / 3.1 — Rust + Arrow + Parquet 리라이트

InfluxDB 3.0 (2024년 6월 정식 출시, 2026년에는 3.1) 은 완전히 다른 DB다.

**아키텍처.**

- **언어**: Go → **Rust** 전면 재작성.

- **인메모리 포맷**: Apache Arrow (column-oriented in-memory).

- **쿼리 엔진**: Apache DataFusion (Rust 기반 SQL 엔진).

- **온디스크 포맷**: Apache Parquet (column-store, ZSTD 압축).

- **쿼리 언어**: SQL + InfluxQL (Flux는 deprecate).

- **분리 아키텍처**: 인제스트, 저장, 쿼리, 컴팩션이 별도 컴포넌트.

**제품 SKU 3종.**

- **InfluxDB 3 Core** — 오픈소스 (MIT). 단일 노드. Edge/IoT용.

- **InfluxDB 3 Enterprise** — 상용. 클러스터, HA, 보안.

- **InfluxDB 3 Cloud (Serverless / Dedicated)** — 완전 관리형. AWS·GCP·Azure 리전.

**왜 Arrow + Parquet인가.** 시계열 데이터는 column-oriented가 압도적으로 유리하다. (timestamp, host=A, cpu=73.2) 가 (timestamp, host=A, cpu=73.3) 으로 흘러가면, cpu 컬럼만 따로 모아 압축하면 거의 동일한 값들이라 압축비가 폭발한다. Parquet는 이 모델의 산업 표준이다.

**Arrow의 진짜 효용은 zero-copy interop**이다. InfluxDB 3에서 쿼리한 데이터를 그대로 Pandas, Polars, DuckDB로 넘길 수 있다. ETL 없이 분석 도구에 꽂힌다.

**마이그레이션 주의.** 2.x → 3.x는 **API와 쿼리 언어가 달라진다.** Flux는 deprecate, write API 엔드포인트 경로도 다르다. Telegraf 출력 플러그인은 호환이 있지만, 직접 짠 코드는 거의 다 리팩토링이 필요하다. **2026년에 2.x를 계속 쓰는 곳이 많은 이유**다.

5장 · TimescaleDB 2.18 / TigerData — Postgres가 TSDB가 되다

TimescaleDB는 2017년 출시. 2026년 현재 2.18. **Postgres extension**이라는 게 핵심이다.

**핵심 개념: Hypertable.** 일반 Postgres 테이블처럼 보이지만 내부적으로 시간 기준으로 자동 파티셔닝된다.

CREATE TABLE metrics (

time TIMESTAMPTZ NOT NULL,

device_id INT,

cpu DOUBLE PRECISION,

memory DOUBLE PRECISION

);

SELECT create_hypertable('metrics', 'time', chunk_time_interval => INTERVAL '1 day');

이렇게만 하면 매일 새 청크(파티션)가 자동 생성된다. 30일 후 자동 삭제도 한 줄.

SELECT add_retention_policy('metrics', INTERVAL '30 days');

**연속 집계(continuous aggregate).** 매분 들어오는 1초 데이터를 자동으로 분/시/일 단위로 롤업하는 머터리얼라이즈드 뷰. 백그라운드 작업이 증분 갱신을 한다.

CREATE MATERIALIZED VIEW metrics_1h

WITH (timescaledb.continuous) AS

SELECT time_bucket('1 hour', time) AS bucket,

device_id,

avg(cpu) AS avg_cpu,

max(cpu) AS max_cpu

FROM metrics

GROUP BY bucket, device_id;

**컬럼 압축.** 청크 단위로 row-store → column-store로 변환. 보통 90~95% 압축.

ALTER TABLE metrics SET (timescaledb.compress, timescaledb.compress_segmentby = 'device_id');

SELECT add_compression_policy('metrics', INTERVAL '7 days');

**TigerData 리브랜딩(2025).** Timescale Inc.는 2025년 회사명을 **TigerData**로 바꿨다. 제품명은 여전히 TimescaleDB. 클라우드 SaaS는 Timescale Cloud → Tiger Cloud. 이유는 "Timescale = 사후 분석 도구" 인식 탈피, AI/실시간 분석 메시징 강화.

**강점.** Postgres와 100% 호환 — psql, pgAdmin, ORM, BI 툴 전부 그대로 쓴다. 관계형 조인이 자유롭고 SQL이 풍부하다.

**약점.** 인제스트 한계가 단일 노드 기준 초당 100만 행 정도. 그 이상은 ClickHouse나 InfluxDB가 빠르다. Multi-node TimescaleDB는 2.13에서 deprecate됐다(클라우드만 분산).

6장 · QuestDB 8.x — SIMD로 무장한 인제스트 괴물

QuestDB는 2014년 시작된 오픈소스 TSDB. 2026년 8.x.

**특이점.** Java + Native (SIMD intrinsics) 로 작성. 인제스트 속도가 무지막지하게 빠르다. **초당 400만 행** 벤치마크가 흔하다.

**스토리지.** 컬럼 기반 + 시간 파티셔닝. 디스크에 컬럼 파일이 시간 순으로 깔린다 — `cpu.d`, `memory.d`, `timestamp.d`. 새 데이터는 항상 append-only로 끝에 추가.

**쿼리.** SQL 사용. SAMPLE BY, LATEST ON 같은 시계열 전용 확장 문법.

SELECT timestamp, avg(cpu)

FROM metrics

WHERE timestamp > dateadd('h', -1, now())

SAMPLE BY 1m;

SELECT * FROM metrics

LATEST ON timestamp PARTITION BY device_id;

**인터페이스.** InfluxDB Line Protocol over UDP/TCP (Telegraf 호환), PostgreSQL wire protocol (psql로 접속 가능), REST API.

**강점.** 단일 노드 인제스트 속도는 업계 톱. 메모리 사용량이 낮고 (10GB로 수십억 행 처리 가능), 운영이 단순하다. 라이선스는 Apache 2.0.

**약점.** 분산이 약하다 (Replication은 8.0에서 추가됐지만 아직 신생). 카디널리티가 너무 높으면 (라벨이 수천만 종) 무너진다. SQL이지만 표준 JOIN이 제한적.

**적합한 곳.** 금융 시장 데이터 (틱 데이터), IoT 센서, 게임 텔레메트리. 단일 노드로 1조 행을 시간 순으로 받아치는 워크로드.

7장 · ClickHouse 24.x / 25.x — OLAP인데 사실상 TSDB

ClickHouse는 Yandex가 2009년 사내용으로 만든 column-store OLAP DB. 2016년 오픈소스, 2021년 ClickHouse Inc. 분사. 2026년 25.x.

**왜 TSDB로도 쓰이는가.** Column-store + 시간 정렬 데이터에서 압도적으로 빠르다. MergeTree 엔진은 LSM-tree 비슷한 구조로 정렬된 데이터를 background로 머지한다.

**핵심 엔진.**

- **MergeTree** — 기본. ORDER BY 키로 정렬된 청크를 background merge.

- **ReplicatedMergeTree** — ZooKeeper 기반 복제. HA용.

- **SummingMergeTree / AggregatingMergeTree** — 머지하면서 자동 집계 (count, sum, min, max).

- **ReplacingMergeTree** — 같은 키 중복 시 최신값 유지.

**테이블 생성.**

CREATE TABLE metrics

(

timestamp DateTime,

device_id UInt32,

cpu Float64,

memory Float64

)

ENGINE = MergeTree()

PARTITION BY toYYYYMM(timestamp)

ORDER BY (device_id, timestamp);

**ALTER TABLE materialized view.** ClickHouse의 머터리얼라이즈드 뷰는 INSERT 트리거다. 들어온 행을 변환·집계해서 다른 테이블에 INSERT.

CREATE MATERIALIZED VIEW metrics_1h

ENGINE = AggregatingMergeTree()

ORDER BY (device_id, bucket)

AS SELECT

toStartOfHour(timestamp) AS bucket,

device_id,

avgState(cpu) AS avg_cpu,

maxState(cpu) AS max_cpu

FROM metrics

GROUP BY bucket, device_id;

**강점.** 압도적인 분석 쿼리 속도. 10억 행 GROUP BY가 1~3초. 압축비 10~30배. SQL이 풍부 (window function, array, map). 분산 클러스터가 표준 기능.

**약점.** UPDATE/DELETE가 비싸다 (ALTER TABLE ... DELETE는 비동기 mutation). 트랜잭션이 없다. 단일 행 lookup은 약하다. 운영 복잡도가 InfluxDB보다 높다.

**2026년 위상.** Cloudflare, Uber, Bloomberg, eBay가 메트릭 저장소로 쓴다. Grafana Mimir와 경쟁한다기보다 **상호 보완**적으로 쓰인다.

8장 · Prometheus 2.x / 3.0 — 메트릭 모니터링의 사실상 표준

Prometheus는 2012년 SoundCloud에서 시작, 2016년 CNCF 가입. 2025년 **Prometheus 3.0** 출시. 메트릭 모니터링 분야의 사실상 표준이다.

**아키텍처.**

- **Pull 모델** — Prometheus 서버가 대상(`/metrics` 엔드포인트)을 주기적으로 스크레이프.

- **TSDB 엔진** — 자체 구현. 2시간 청크, WAL, head·persistent block 구조.

- **PromQL** — 시계열 전용 쿼리 언어. `rate`, `sum by`, `histogram_quantile` 등.

- **Alertmanager** — 별도 컴포넌트. 알림 라우팅·중복 제거.

- **Service Discovery** — Kubernetes, EC2, Consul 등에서 대상 자동 발견.

**PromQL 예시.**

rate(http_requests_total[5m])

sum by (status) (rate(http_requests_total[5m]))

histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

**3.0의 변화 (2025).**

- **UTF-8 라벨 지원** — 라벨 이름에 점, 하이픈 사용 가능 (OpenTelemetry semantic convention 호환).

- **Native histograms** — 기존 bucket 히스토그램의 카디널리티 문제 해결. 동적 bucket.

- **Remote-write 2.0** — 효율적인 원격 저장소 전송.

- **OpenTelemetry 인제스트** — OTLP 메트릭 직접 수신.

**약점.** 단일 노드. 장기 보관(retention)은 디스크 한계. HA는 federation 또는 외부 도구(Mimir, Thanos, VictoriaMetrics)로 해결. 카디널리티 폭발에 약하다 — 라벨 조합이 100만 시리즈를 넘으면 메모리가 폭증.

**여전히 2026년 표준인 이유.** Kubernetes ecosystem 통합이 완벽. 모든 인프라 도구가 Prometheus exposition format을 지원한다. 가벼운 환경에서는 단일 노드로 충분하다.

9장 · VictoriaMetrics 1.110+ — Prometheus의 효율적 대안

VictoriaMetrics는 2018년 시작된 오픈소스 TSDB. 2026년 1.110+. **Prometheus 호환**이지만 더 효율적인 엔진.

**아키텍처.**

- **vmstorage** — 데이터 저장. column-store, ZSTD 압축.

- **vminsert** — 쓰기 받는 프록시.

- **vmselect** — 쿼리 라우터.

- **vmagent** — Prometheus 대체 스크레이퍼. remote-write 송신.

- **vmalert** — Alertmanager 대체.

**MetricsQL.** PromQL의 슈퍼셋. 추가 함수 (`keep_last_value`, `aggr_over_time`, `running_sum`) 와 더 빠른 실행기.

**Prometheus 대비 장점.**

- **압축비 10배 좋다.** 같은 데이터를 Prometheus는 100GB, VM은 10GB.

- **메모리 7배 적게 쓴다.** 10M active series를 Prometheus는 32GB 필요, VM은 4GB.

- **인제스트 속도 7배 빠르다.** 카디널리티 폭발에도 더 견딘다.

- **클러스터 버전이 오픈소스.** Prometheus의 HA는 federation 또는 Mimir 필요. VM은 자체 클러스터.

**vmagent로 Prometheus 대체.** Prometheus는 메모리에 데이터 보관 + 디스크 flush + remote-write를 동시에 한다. vmagent는 스크레이프 후 즉시 remote-write — 메모리 사용량이 1/10.

**적합한 곳.** 대규모 메트릭 (1억+ active series), 비용 절감, 오픈소스 단일 도구로 끝내고 싶을 때.

**약점.** Grafana/Prometheus ecosystem 통합은 99% 호환이지만 1%에서 엣지케이스. Recording rules 문법 차이.

10장 · Grafana Mimir — 수평 확장 Prometheus

Grafana Mimir는 2022년 Grafana Labs가 발표한 오픈소스 프로젝트다. **Cortex의 fork + 재설계.** Grafana Cloud Metrics의 백엔드.

**핵심 가치 제안.** "Prometheus를 1조 series까지 수평 확장."

**아키텍처.**

- **Distributor** — 인제스트 수신, 해싱으로 ingester로 분배.

- **Ingester** — WAL + 인메모리 chunk.

- **Store-Gateway** — S3/GCS/Azure Blob에서 historical 데이터 쿼리.

- **Querier** — 쿼리 실행기.

- **Query-Frontend** — 쿼리 캐싱·분할.

- **Compactor** — Block 머지.

- **Object storage** — 모든 영속 데이터는 S3 호환 스토리지에 저장.

**S3가 핵심.** Mimir는 RAM/SSD를 캐시로만 쓰고, 영속 저장소는 S3 (또는 GCS/Azure Blob). 무한 보관, 저렴한 비용, 노드 추가/제거가 자유롭다.

**PromQL 호환.** Prometheus 쿼리, recording rules, Alertmanager 모두 그대로.

**적합한 곳.** Grafana 스택을 이미 쓰고 메트릭을 1억+ series로 확장하는 SaaS. Grafana Cloud 자체 호스팅 버전.

**약점.** 운영 복잡도가 매우 높다. 8~10개 컴포넌트. ZooKeeper/Consul 비슷한 KV 스토어 (memberlist 가능) 필요. Helm으로 배포해도 튜닝이 어렵다.

11장 · Cortex와 Thanos — Mimir 이전의 두 갈래

Mimir 등장 전, 수평 확장 Prometheus는 두 솔루션이 있었다.

**Cortex (2017~).** Weaveworks가 시작, CNCF Incubating. Multi-tenant Prometheus. S3 object storage 기반. Mimir는 Cortex 2021년 fork 후 라이선스 변경(AGPL)으로 갈라졌다.

**Thanos (2017~).** Improbable가 시작, CNCF Incubating. 다른 접근 — Prometheus 인스턴스를 그대로 두고 sidecar로 데이터를 S3로 업로드, 쿼리 시점에 여러 Prometheus + S3를 통합 조회. 단순함이 강점.

**2026년 위상.**

- **Thanos** — 여전히 인기. 기존 Prometheus를 그대로 두고 보강하는 데 적합. Multi-cluster·multi-region에 강하다.

- **Cortex** — Mimir 등장 후 빛 잃음. 일부 레거시 운영처가 남아있음.

- **Mimir** — 가장 적극적으로 개발. Grafana Labs 풀 푸시.

- **VictoriaMetrics** — 위 셋과 별개 진영. 더 단순.

**선택 가이드.** 새로 시작이면 Mimir 또는 VictoriaMetrics. 기존 Prometheus가 여러 클러스터에 흩어져 있고 그대로 두고 싶으면 Thanos.

12장 · 카디널리티 — TSDB의 #1 스케일링 문제

TSDB를 어느 정도 운영해본 사람은 다 안다. **모든 문제의 근원은 카디널리티(cardinality)**다.

**카디널리티의 정의.** 유니크한 시계열(time series)의 개수. `http_requests_total{method="GET", status="200", path="/api/v1/users"}` 가 하나의 시리즈다. 라벨 조합이 폭발하면 시리즈 수도 폭발한다.

**위험한 패턴.**

- **user_id를 라벨로** — 사용자 100만 명이면 시리즈 100만 개 폭증.

- **request_id를 라벨로** — 매 요청마다 새 시리즈. 메모리 즉사.

- **timestamp를 라벨로** — 비슷한 자살 행위.

- **에러 메시지 전체를 라벨로** — 변동성 무한.

**메모리 비용.** Prometheus 단일 노드 기준 100만 active series에 대략 2GB 메모리. 1000만 series는 20GB. 1억은 200GB — 단일 노드로 불가능.

**완화 기법.**

- **라벨 정규화.** path를 `/api/v1/users/:id`로 정규화 (id 빼고).

- **bucket으로 묶기.** latency를 ms 단위로 라벨링하지 말고 히스토그램으로.

- **고카디널리티 라벨은 별도 저장.** request_id 같은 건 로그(Loki, Elasticsearch)로 보내고 메트릭에 안 넣는다.

- **VictoriaMetrics / Mimir로 확장.** 1억 series까지는 도구 선택으로 해결.

**카디널리티는 처음부터 설계해야 한다.** 한 번 라벨 schema가 코드 전체에 박히면 빼기 어렵다. **TSDB 도입 전 라벨 가이드를 먼저 만들어라**가 산업 규칙이다.

13장 · 압축 — Gorilla XOR · delta-of-delta · ZSTD

TSDB가 일반 DB보다 30배 압축이 잘 되는 이유는 세 가지 기법의 조합이다.

**1. Delta encoding (timestamp용).** 절댓값이 아니라 직전 값과의 차이만 저장. 1초 간격 데이터면 차이는 거의 1000(ms). 64-bit 정수 8바이트가 가변 길이 1~2바이트로 줄어든다.

**2. Delta-of-delta encoding (timestamp용).** 한 단계 더. 차이의 차이를 저장. 거의 일정 간격이면 0이 연속으로 나와 더 압축된다. Gorilla 논문(Facebook 2015)의 핵심.

**3. Gorilla XOR encoding (float값용).** 직전 값과 XOR한 결과를 저장. 비슷한 부동소수점은 XOR 결과의 leading/trailing zero가 많아 가변 길이 인코딩이 잘 된다. CPU 사용률처럼 부드럽게 변하는 메트릭에 효과적.

**4. ZSTD compression (블록 단위).** 위 인코딩 후 ZSTD로 한 번 더 압축. 보통 추가로 2~3배.

**효과.** 16바이트 (timestamp + float64) 가 평균 1.5바이트까지 줄어든다. **10배 압축**이 베이스라인이고, **30배**가 흔하다.

**TSDB별 구현.**

- **Prometheus / Mimir / Thanos** — Gorilla 기반.

- **InfluxDB 3** — Parquet (PLAIN_DELTA_ENCODING, RLE_DICTIONARY 등) + ZSTD.

- **TimescaleDB** — segment-by 컬럼 단위 압축 + ZSTD/LZ4.

- **VictoriaMetrics** — 자체 알고리즘 + ZSTD. 같은 데이터에서 Prometheus보다 약 10배 효율.

- **ClickHouse** — DoubleDelta + Gorilla + LZ4/ZSTD.

압축은 단순히 디스크 절약이 아니라 **I/O 절약**이다. SSD 대역폭이 곧 쿼리 성능이고, 압축이 잘 되면 같은 I/O로 더 많은 데이터를 읽는다.

14장 · 연속 집계 vs 머터리얼라이즈드 뷰

다운샘플링과 사전 집계는 두 가지 패턴으로 구현된다.

**연속 집계(continuous aggregate) — TimescaleDB.** 머터리얼라이즈드 뷰지만 **증분 갱신**된다. 백그라운드 작업이 새로 들어온 데이터만 집계해 뷰에 추가. 사용자는 SELECT만 하면 된다.

**머터리얼라이즈드 뷰(materialized view) — ClickHouse.** **INSERT 트리거**다. 새 행이 들어오면 변환·집계해서 다른 테이블에 INSERT. 자동 증분이 아니라 정의 시점부터 들어오는 데이터만 처리.

**recording rules — Prometheus.** PromQL 표현식을 주기적(예: 1분마다) 실행해 결과를 별도 시리즈로 저장. Grafana에서 비싼 쿼리를 미리 계산해두는 용도.

**Tasks — InfluxDB 3.** SQL/InfluxQL을 스케줄러로 주기 실행. 결과를 다른 measurement에 쓴다.

**continuous query (1.x) — InfluxDB 1.** 레거시. 3.x에서는 Tasks로 대체.

**선택 가이드.**

- **자동·정확한 백필이 필요하면 TimescaleDB의 연속 집계.** 과거 데이터 변경이 자동 반영.

- **인제스트 시점에 즉시 집계하고 싶으면 ClickHouse materialized view.** 단, 백필은 별도로.

- **Prometheus 사용처라면 recording rules 그대로.**

15장 · OpenTelemetry 메트릭 — 새로운 표준

2026년 메트릭 송수신의 사실상 표준은 **OpenTelemetry (OTel)**다.

**OTel Metrics 모델.**

- **Counter** — 단조 증가. `http_requests_total` 같은.

- **UpDownCounter** — 증감 둘 다. `goroutines_active` 같은.

- **Gauge** — 즉시값. `memory_used_bytes`.

- **Histogram** — 분포. `request_duration_seconds`.

- **ExponentialHistogram** — 동적 bucket 히스토그램 (Prometheus 3.0의 native histogram과 호환).

**OTLP — OpenTelemetry Line Protocol.** gRPC 또는 HTTP/protobuf로 메트릭 전송.

**TSDB 인제스트.** 2026년 거의 모든 TSDB가 OTLP를 직접 받는다.

- **Prometheus 3.0** — OTLP receive 내장.

- **VictoriaMetrics** — OTLP endpoint 지원.

- **InfluxDB 3** — OTLP 호환.

- **Grafana Mimir** — OTLP 인제스트.

- **ClickHouse** — OTel Collector 통해 인제스트.

**전환의 의미.** Prometheus exposition format (pull) 만이 표준이던 시대에서, OTLP (push) + Prometheus (pull) 가 공존하는 시대로. SDK 코드는 OTel SDK 하나로 작성하고, 어디로 송신할지만 설정으로 바꾼다.

**Korean/Japanese 적용.** 카카오는 사내 메트릭을 Prometheus → OTel 마이그레이션 중. NTT는 OTel을 기본으로 채택. 신규 프로젝트는 OTel이 디폴트가 됐다.

16장 · TDengine · GreptimeDB · CrateDB — 신생 진영

2026년 주목할 신생 TSDB 셋.

**TDengine 3.x.** 중국 Taos Data가 만든 오픈소스 TSDB. IoT 특화. C로 작성, 가볍고 빠르다. "1 device = 1 table" 모델 — 디바이스마다 별도 테이블을 만들어 시계열 격리. 단일 노드로 1억 디바이스 처리 가능. SQL 사용. 클러스터는 엔터프라이즈.

**GreptimeDB 0.10+.** 2022년 출시, Rust로 작성된 cloud-native TSDB. Storage-compute 분리, S3 백엔드, Kubernetes 친화적. InfluxDB Line Protocol + MySQL/PostgreSQL wire protocol + PromQL 동시 지원. **2025년 v0.10에서 안정화.** 후발주자지만 InfluxDB 3와 직접 경쟁.

**CrateDB.** 2014년 출시 (Crate.io, 오스트리아). 분산 SQL DB지만 시계열 워크로드도 처리. Elasticsearch처럼 샤딩, Lucene 인덱스 활용. SQL이 풍부하고 풀텍스트 검색도 됨. 일부 IoT 고객에서 인기.

**언제 쓰는가.**

- **TDengine** — IoT 디바이스 수가 수억이고 각 디바이스가 동일 schema. 중국 시장.

- **GreptimeDB** — Cloud-native 환경, K8s + S3. InfluxDB 3 대안 평가 중.

- **CrateDB** — 시계열 + 풀텍스트 + 관계형 조합. SQL 친화적 분산 DB가 필요할 때.

이 셋은 메인스트림(Prometheus, ClickHouse, InfluxDB, TimescaleDB)을 대체하기보다 **특정 niche를 노린다.**

17장 · OLAP 인접 — Apache Druid, Pinot, StarRocks

원래 OLAP인데 시계열 워크로드도 처리하는 셋.

**Apache Druid.** 2011년 Metamarkets에서 시작, 2018년 Apache. 시계열 + OLAP. Real-time 인제스트 (Kafka 친화), columnar storage, bitmap index. Netflix, Airbnb, eBay가 사용자 분석 / 광고 메트릭에 씀.

**Apache Pinot.** 2014년 LinkedIn에서 시작, 2019년 Apache. Druid와 비슷한 분야 — real-time OLAP. Low-latency (sub-second) 쿼리에 강점. LinkedIn, Uber, Stripe가 사용.

**StarRocks.** 2020년 시작 (중국). MPP query engine. 분석 워크로드 + 시계열 결합. ClickHouse와 직접 경쟁. 2026년에 빠르게 성장 중.

**OLAP TSDB vs 전용 TSDB.**

- 전용 TSDB는 **append-heavy + retention + 압축**이 강점.

- OLAP은 **임의 GROUP BY + JOIN + 복잡한 분석**이 강점.

**언제 OLAP을 쓰는가.** 시계열 + 디멘션 분석(슬라이스 앤 다이스, drill-down) 이 같이 필요할 때. 광고 어트리뷰션, 사용자 행동 분석, 비즈니스 인텔리전스.

**언제 TSDB만 쓰는가.** 모니터링 메트릭, IoT 센서, 금융 틱 — 단순 시간축 집계가 99%면 전용 TSDB가 더 효율적.

18장 · 로그 인접 — VictoriaLogs, Loki, OpenObserve

메트릭과 로그는 서로 가깝다. 같은 도구로 묶으려는 시도가 많다.

**Grafana Loki.** 2018년 Grafana Labs. "로그용 Prometheus." 인덱스는 라벨만 (전체 텍스트 인덱스 X). LogQL로 쿼리. S3 백엔드. Mimir와 자매.

**VictoriaLogs.** VictoriaMetrics의 로그 버전. 2023년 출시. 단일 바이너리, 압축비 뛰어남, LogsQL 쿼리 언어.

**OpenObserve.** 2023년 출시. Rust로 작성된 all-in-one observability — 로그, 메트릭, 트레이스. Parquet + S3 백엔드. Elasticsearch/Splunk 대체 노리는 후발주자.

**Elasticsearch / OpenSearch.** 여전히 가장 보편적 로그 저장소. 비싸고 무겁지만 풀텍스트 검색 기능이 압도적.

**ClickHouse for logs.** Uber, Cloudflare가 로그도 ClickHouse에 저장. ELK보다 압축 좋고 빠르지만 풀텍스트 검색은 약하다.

**조합 패턴.**

- **Grafana 스택** = Prometheus/Mimir(메트릭) + Loki(로그) + Tempo(트레이스).

- **VictoriaMetrics 스택** = VM(메트릭) + VictoriaLogs(로그).

- **OpenObserve 단일.** 한 도구로 셋 다.

- **ELK + Prometheus.** 클래식 분리 모델.

19장 · 상용 SaaS — Datadog · New Relic · Splunk · Honeycomb

오픈소스 TSDB를 직접 운영하지 않고 SaaS를 쓰는 곳도 많다.

**Datadog.** 2010년 창업, 시가총액 약 400억 달러 (2026년). 메트릭 + APM + 로그 + RUM + Security를 한 화면에. UX 최고, 가격 비싸기로 악명. 시리즈당 / 호스트당 청구.

**New Relic.** Datadog 경쟁자. 2020년 가격 모델 단순화 (이전엔 SKU가 너무 많았음). 한국·일본 시장에서 점유율 늘리는 중.

**Splunk.** 2003년 창업. 로그 중심 (메트릭은 약). 엔터프라이즈 보안(SIEM)에 강점. 2024년 Cisco 인수.

**Honeycomb.** Charity Majors가 2016년 창업. "Observability 2.0" — 이벤트 기반 high-cardinality 분석. 메트릭이라기보다 trace + event. SRE 커뮤니티에서 컬트적 인기.

**Lightstep.** Ben Sigelman 창업, 2021년 ServiceNow 인수. 트레이싱 중심.

**Grafana Cloud.** Grafana Labs의 SaaS. Mimir + Loki + Tempo를 매니지드.

**선택 가이드.**

- **풀스택을 빠르게 — Datadog.** 비싸지만 빠르다.

- **메트릭만, 자체 호스팅 옵션 — Grafana Cloud.**

- **High-cardinality 디버깅 — Honeycomb.**

- **엔터프라이즈 보안 — Splunk.**

**비용 함정.** Datadog는 카디널리티 폭발 시 청구서가 폭증한다. "Custom metric" 한 라벨 추가가 월 수십만 달러를 더할 수 있다.

20장 · 하드웨어 — NVMe I/O 패턴과 메모리 budget

TSDB 성능은 하드웨어 선택에 직결된다.

**NVMe SSD는 필수.** SATA SSD 대역폭 (550MB/s) 으로는 인제스트가 따라잡지 못한다. NVMe (3~7 GB/s read, 1~5 GB/s write) 가 표준. 2026년에는 PCIe 5.0 NVMe도 보편화.

**시계열 I/O 패턴.**

- **Sequential write** — 새 데이터는 append-only. 거의 sequential.

- **Range read** — 시간 범위 쿼리는 연속 블록 읽기.

- **Random read 적음** — point lookup은 드물다.

이 패턴은 LSM-tree, MergeTree, Parquet 같은 sequential 친화 구조에 유리하다.

**메모리 budget per series.** 단순화한 룰.

- **Prometheus 단일 노드** — 1.5~2 KB / active series. 100만 series = 2GB.

- **VictoriaMetrics** — 약 400 bytes / series. 7배 효율.

- **TimescaleDB** — chunk_cache 설정에 따라 가변.

- **ClickHouse** — primary key index size + mark cache. 명시적으로 조정.

- **InfluxDB 3** — Arrow 인메모리 buffer 크기 명시.

**S3 백엔드의 함의.** Mimir, Thanos, GreptimeDB는 영속 저장소를 S3에 둔다. 디스크는 캐시만. 노드 추가/삭제가 자유롭고 비용도 SSD보다 1/10. 단점은 쿼리 latency가 SSD 직접 접근보다 100ms 이상 추가.

**ARM CPU 효과.** AWS Graviton, Ampere Altra 같은 ARM 서버 CPU에서 ClickHouse, VictoriaMetrics는 x86 대비 20~30% 가성비 우수. InfluxDB 3는 Rust로 ARM에서도 잘 돈다.

21장 · 한국 — NHN Cloud, Kakao, Coupang

한국 회사들의 TSDB 사용 사례.

**NHN Cloud.** **NHN Cloud Time Series** 라는 매니지드 TSDB 서비스 제공. 내부적으로 InfluxDB 기반 + 자체 확장. 게임 텔레메트리, IoT용으로 마케팅.

**Kakao.** 카카오톡 백엔드 메트릭은 Prometheus + Thanos. 2024년 일부 워크로드를 VictoriaMetrics로 전환. 메트릭 시리즈 수 1억+ 규모. 사내 데이터 플랫폼은 ClickHouse도 함께 운영.

**Naver.** 네이버 클라우드(NCP)는 Cloud DB for InfluxDB 매니지드 제공. 사내 모니터링은 Prometheus + Grafana 기본 스택. AI 플랫폼 메트릭은 ClickHouse.

**Coupang.** Coupang R&D는 ClickHouse를 적극 사용. 검색·추천·물류 메트릭. Prometheus는 인프라 모니터링용.

**Toss / 토스.** 결제 워크로드 메트릭은 Prometheus + VictoriaMetrics. 카디널리티 관리 가이드를 사내에 적극 배포한다.

**삼성SDS / LG CNS.** 엔터프라이즈는 Splunk + Datadog를 많이 쓰지만, 클라우드 네이티브 워크로드는 Prometheus + Grafana로 빠르게 전환 중.

**한국어 학습 자원.** Prometheus 한국어 가이드(Owen Lee), VictoriaMetrics Korean Slack 커뮤니티가 활발. ClickHouse 사용자 모임은 카카오·당근마켓 주도.

22장 · 일본 — NTT R&D, Rakuten, CyberAgent, Mercari

일본은 TSDB 도입이 활발한 편이다.

**NTT R&D.** Prometheus + Thanos가 표준. 일부 IoT 연구는 InfluxDB. OpenTelemetry 채택 가장 적극적인 일본 회사.

**Rakuten.** Rakuten Data Platform은 ClickHouse 대규모 사용. 사용자 행동 분석 + 광고 메트릭. 추가로 Datadog로 인프라 모니터링.

**CyberAgent.** AbemaTV(아베마TV) 메트릭은 Prometheus + Grafana Mimir. 광고 어트리뷰션은 BigQuery + 자체 시계열 도구. 사내에서 Grafana Mimir 컨퍼런스 발표를 종종.

**Mercari.** Microservices가 1000+ 규모. Prometheus + Cortex (Mimir로 마이그레이션 중). Datadog APM도 병행.

**LINE.** LINE Yahoo (2023년 합병) 의 메트릭 인프라는 Prometheus + 자체 확장. Hadoop/Hive 기반 시계열 분석도 운영.

**SoftBank Robotics, Sony.** IoT/로보틱스는 InfluxDB 1.x/2.x 레거시가 많고 InfluxDB 3 마이그레이션 평가 중.

**일본어 자료.** O'Reilly Japan의 "Prometheus 実践ガイド", 닛케이 BP 시계열 데이터 처리 시리즈가 표준. 그라파나 도쿄 사용자 모임이 분기별로 열린다.

23장 · 마이그레이션 패턴

기존 TSDB에서 다른 TSDB로 옮기는 시나리오.

**InfluxDB 2 → InfluxDB 3.** **API 호환 안 됨.** Write API는 line protocol 호환이지만 query API와 Flux는 완전히 다른 길로. 옵션:

1. **Big-bang 마이그레이션** — 짧은 기간(밤) 안에 데이터 export → import. 작은 데이터셋만 가능.

2. **Dual-write** — 일정 기간 양쪽에 동시 쓰기, 검증 후 cutover.

3. **읽기 전용 보존** — 2.x를 historical 데이터 보관용으로 동결, 신규 데이터만 3.x.

**Prometheus → Mimir.** 비교적 평화로움. Prometheus의 remote-write로 Mimir를 백엔드로 지정하고, 일정 기간 dual로 운영 후 직접 Mimir 쿼리 사용. PromQL 호환.

**Prometheus → VictoriaMetrics.** 비슷. vmagent로 Prometheus 대체, vmstorage가 데이터 보관. Recording rules 문법 약간 다름 — 미리 변환 필요.

**PostgreSQL (raw) → TimescaleDB.** Postgres extension이라 그냥 `CREATE EXTENSION timescaledb` + `create_hypertable()`. 다운타임 거의 없음. 기존 SQL은 그대로 작동.

**Postgres → ClickHouse.** SQL 문법 차이 큼. PG의 트랜잭션을 포기해야 함. 보통은 dual-write 패턴 — 트랜잭션 데이터는 PG에, 분석/시계열은 ClickHouse에. CDC (Debezium) 로 PG → ClickHouse 복제.

**OpenTSDB → 무엇이든.** OpenTSDB는 2026년에 사실상 사양됐다. HBase 운영 부담이 너무 크다. 대부분 Mimir, VictoriaMetrics, ClickHouse로 마이그레이션.

**마이그레이션 함정.** 라벨 schema 차이 (특히 Prometheus의 UTF-8 처리), timestamp 정밀도(ns/μs/ms/s) 차이, 보관 정책 매핑. 사전 dry-run이 필수.

24장 · 의사결정 매트릭스

상황별 TSDB 선택 가이드.

**케이스 A — 단일 팀, 메트릭 모니터링, K8s 환경.**

- 시리즈 1000만 미만: **Prometheus 3.0 단일 노드.**

- 시리즈 1000만~1억: **VictoriaMetrics** 또는 **Prometheus + Thanos.**

- 시리즈 1억 이상: **Grafana Mimir** 또는 **VictoriaMetrics cluster.**

**케이스 B — IoT 센서 데이터.**

- 디바이스 수십만, edge 컴퓨팅 필요: **InfluxDB 3 Core (Edge).**

- 디바이스 수억, 중국 시장: **TDengine.**

- 디바이스 + 풀텍스트 검색 같이: **CrateDB.**

**케이스 C — 금융 틱 데이터, 단일 노드 인제스트 최적화.**

- 초당 100만+ 행 인제스트, 단일 노드: **QuestDB.**

- 분산 + 분석 쿼리 풍부: **ClickHouse.**

**케이스 D — 비즈니스 KPI + 분석.**

- Postgres 친화 환경: **TimescaleDB.**

- 분석 쿼리 압도적: **ClickHouse.**

- 실시간 OLAP: **Apache Druid** 또는 **StarRocks.**

**케이스 E — 풀스택 관측성 (메트릭 + 로그 + 트레이스).**

- Grafana 스택 선호: **Mimir + Loki + Tempo.**

- VictoriaMetrics 스택 선호: **VM + VictoriaLogs.**

- 단일 도구: **OpenObserve.**

- SaaS 빠르게: **Datadog.**

**케이스 F — AI/ML 워크로드 메트릭.**

- 모델 inference latency, GPU 사용률: **Prometheus + Grafana + OpenTelemetry.**

- 학습 메트릭 로깅과 통합: Weights & Biases / MLflow + 메트릭은 Prometheus.

**기본 출발점.** 잘 모르겠으면 **Prometheus + Grafana**로 시작하고 카디널리티 폭발 시점에 VictoriaMetrics 또는 Mimir로 확장.

25장 · 안티패턴 10가지

흔히 보는 TSDB 실수 정리.

1. **user_id를 라벨로 박기.** 카디널리티 폭발 #1 원인.

2. **Prometheus를 장기 보관소로 쓰기.** 30일 넘기면 디스크 부족. Mimir/Thanos/VictoriaMetrics로 보내라.

3. **PostgreSQL에 raw 시계열.** TimescaleDB 확장 안 켜면 10배 비싸다.

4. **OLTP DB와 TSDB 합치기.** 시계열 워크로드가 OLTP 성능 죽인다.

5. **라벨에 timestamp/UUID 박기.** 매 row가 새 시리즈.

6. **백업 안 함.** Prometheus는 단일 노드 디스크에 모두. 노드 죽으면 0.

7. **다운샘플링 없이 모두 raw 보관.** 디스크 폭발.

8. **카디널리티 모니터링 안 함.** `prometheus_tsdb_head_series` 추적 필수.

9. **Flux/Influx 1.x로 신규 프로젝트 시작.** 3.x로 가라.

10. **카드 한도 무시한 Datadog 도입.** "Custom metric"으로 청구서 폭증. 라벨 정책 가드레일 필요.

26장 · 참고 / References

- [InfluxDB 3 — 공식 문서](https://docs.influxdata.com/influxdb3/)

- [InfluxDB GitHub — influxdb_iox (Rust 코어)](https://github.com/influxdata/influxdb)

- [Apache Arrow — 공식](https://arrow.apache.org/)

- [Apache DataFusion — 공식](https://datafusion.apache.org/)

- [Apache Parquet — 공식](https://parquet.apache.org/)

- [TimescaleDB / TigerData — 공식](https://www.tigerdata.com/)

- [TimescaleDB GitHub](https://github.com/timescale/timescaledb)

- [QuestDB — 공식](https://questdb.io/)

- [QuestDB GitHub](https://github.com/questdb/questdb)

- [ClickHouse — 공식 문서](https://clickhouse.com/docs)

- [ClickHouse GitHub](https://github.com/ClickHouse/ClickHouse)

- [Prometheus — 공식](https://prometheus.io/)

- [Prometheus 3.0 — 릴리스 노트](https://prometheus.io/blog/2024/11/14/prometheus-3-0/)

- [VictoriaMetrics — 공식](https://victoriametrics.com/)

- [VictoriaMetrics GitHub](https://github.com/VictoriaMetrics/VictoriaMetrics)

- [Grafana Mimir — 공식](https://grafana.com/oss/mimir/)

- [Grafana Mimir GitHub](https://github.com/grafana/mimir)

- [Cortex — 공식](https://cortexmetrics.io/)

- [Thanos — 공식](https://thanos.io/)

- [TDengine — 공식](https://tdengine.com/)

- [GreptimeDB — 공식](https://greptime.com/)

- [CrateDB — 공식](https://crate.io/)

- [Apache Druid — 공식](https://druid.apache.org/)

- [Apache Pinot — 공식](https://pinot.apache.org/)

- [StarRocks — 공식](https://www.starrocks.io/)

- [Grafana Loki — 공식](https://grafana.com/oss/loki/)

- [VictoriaLogs — 공식 문서](https://docs.victoriametrics.com/victorialogs/)

- [OpenObserve — 공식](https://openobserve.ai/)

- [Datadog — 공식](https://www.datadoghq.com/)

- [New Relic — 공식](https://newrelic.com/)

- [Splunk — 공식](https://www.splunk.com/)

- [Honeycomb — 공식](https://www.honeycomb.io/)

- [OpenTelemetry — 공식](https://opentelemetry.io/)

- [OpenTelemetry Metrics 스펙](https://opentelemetry.io/docs/specs/otel/metrics/)

- [Gorilla 논문 — Facebook 2015](https://www.vldb.org/pvldb/vol8/p1816-teller.pdf)

- [Awesome Time-Series Databases — GitHub](https://github.com/xephonhq/awesome-time-series-database)

- [NHN Cloud Time Series — 공식](https://www.nhncloud.com/kr/service/database/time-series)

- [Naver Cloud — Cloud DB for InfluxDB](https://www.ncloud.com/product/database/cloudDbForInfluxdb)

— 시계열 데이터베이스 2026, 끝.