시계열 데이터베이스 2026 완벽 가이드 - InfluxDB 3 · TimescaleDB · QuestDB · ClickHouse · Prometheus · VictoriaMetrics · Grafana Mimir 심층 분석

프롤로그 — 시계열은 왜 별도 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는 완전히 다른 길로. 옵션:

Big-bang 마이그레이션 — 짧은 기간(밤) 안에 데이터 export → import. 작은 데이터셋만 가능.
Dual-write — 일정 기간 양쪽에 동시 쓰기, 검증 후 cutover.
읽기 전용 보존 — 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 실수 정리.

user_id를 라벨로 박기. 카디널리티 폭발 #1 원인.
Prometheus를 장기 보관소로 쓰기. 30일 넘기면 디스크 부족. Mimir/Thanos/VictoriaMetrics로 보내라.
PostgreSQL에 raw 시계열. TimescaleDB 확장 안 켜면 10배 비싸다.
OLTP DB와 TSDB 합치기. 시계열 워크로드가 OLTP 성능 죽인다.
라벨에 timestamp/UUID 박기. 매 row가 새 시리즈.
백업 안 함. Prometheus는 단일 노드 디스크에 모두. 노드 죽으면 0.
다운샘플링 없이 모두 raw 보관. 디스크 폭발.
카디널리티 모니터링 안 함. prometheus_tsdb_head_series 추적 필수.
Flux/Influx 1.x로 신규 프로젝트 시작. 3.x로 가라.
카드 한도 무시한 Datadog 도입. "Custom metric"으로 청구서 폭증. 라벨 정책 가드레일 필요.

26장 · 참고 / References

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

시계열 데이터베이스 2026 완벽 가이드 - InfluxDB 3 · TimescaleDB · QuestDB · ClickHouse · Prometheus · VictoriaMetrics · Grafana Mimir 심층 분석

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

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

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

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

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

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

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

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

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

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

10장 · Grafana Mimir — 수평 확장 Prometheus

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

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

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

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

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

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

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

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

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

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

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

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

23장 · 마이그레이션 패턴

24장 · 의사결정 매트릭스

25장 · 안티패턴 10가지

26장 · 참고 / References

댓글