시계열 데이터베이스 2026 — TimescaleDB / InfluxDB 3 / QuestDB / ClickHouse / VictoriaMetrics 심층 비교

프롤로그 — "시계열 DB 하나로 다 되는 시대는 끝났다"

2017년쯤만 해도 "시계열 DB?" 하면 InfluxDB 1.x 한 개의 이름이 떠올랐다. 2020년이 되자 Prometheus가 메트릭의 표준이 됐고, TimescaleDB가 Postgres 위에서 SQL을 무기로 등장했다. 2023년에는 ClickHouse가 OLAP 영역에서 시계열까지 잠식하기 시작했고, QuestDB는 Java로 빠른 ingest를 들고 나왔다.

2026년 현재, 우리가 "시계열 데이터"라 부르는 것 안에는 최소 4개의 다른 워크로드가 들어 있다.

메트릭 (metrics) — CPU·메모리·QPS 같은 시간당 숫자. 카디널리티 폭발이 핵심 적.
로그 (logs) — 텍스트 한 줄당 timestamp + 메시지. 풀텍스트 검색 + 시간 필터.
트레이스 (traces) — 분산 시스템의 span. span-id, trace-id로 연결된 그래프 구조.
IoT/센서 (telemetry) — 디바이스·차량·공장 센서의 시계열. 압축률과 ingest 처리량.

이 4축 위에 또 OLAP(분석성 쿼리)와 APM(애플리케이션 성능 관리)이라는 응용 카테고리가 겹친다. 그래서 같은 "시계열 DB"라는 라벨을 달고 있어도 TimescaleDB와 VictoriaMetrics와 ClickHouse는 서로 노리는 시장이 다르다.

이 글은 2026년 5월 기준 9개 주요 후보 — TimescaleDB, InfluxDB 3 Core/Enterprise, QuestDB, ClickHouse, VictoriaMetrics, Prometheus + Grafana Mimir, M3DB, GreptimeDB, TDengine/OpenTSDB — 의 위치와 강점·약점을 정리한다. 그리고 마지막에 "우리 팀은 무엇을 골라야 하나"를 4가지 도메인(IoT·관찰성·금융·OLAP)별로 답한다.

1장 · 2026년 시계열 DB 지도 — 메트릭·로그·트레이스·IoT 4축

먼저 큰 그림. 2026년의 시계열 DB는 크게 세 가족으로 분류된다.

가족	특징	대표주자
Postgres 가족	표준 SQL, 트랜잭션, JOIN 강함	TimescaleDB
전용 TSDB 가족	시계열 최적화 압축·인덱스, 메트릭 특화	InfluxDB 3, VictoriaMetrics, Prometheus, M3DB, GreptimeDB
컬럼 스토어 가족	OLAP에서 출발, 시계열도 잘 됨	ClickHouse, QuestDB, Apache Druid, Apache Pinot

그리고 워크로드별로 보면.

워크로드	권장 후보	이유
Kubernetes 메트릭	Prometheus + Mimir, VictoriaMetrics	표준 호환, 카디널리티 관리 도구
APM 메트릭 + 트레이스	OTel + ClickHouse 또는 GreptimeDB	OTLP 직접 수신, 컬럼 압축
IoT 센서 (수십만 디바이스)	InfluxDB 3, TDengine, TimescaleDB	압축률, 다운샘플링, edge 통합
금융 틱 데이터	QuestDB, ClickHouse, TimescaleDB	ns 단위 정확도, 빠른 시계열 JOIN
일반 분석 + 시계열	ClickHouse, TimescaleDB	SQL 친숙도, 일반 데이터와 결합
로그 (메트릭과 같이)	ClickHouse, GreptimeDB	풀텍스트 + 시간 필터

핵심 통찰 한 가지: 시계열 DB를 하나로 통일하려는 시도는 거의 다 실패한다. k8s 관찰성과 IoT를 같은 DB에 우겨넣는 시도는 카디널리티 모델이 달라서 한쪽이 깨진다. 우리 팀의 워크로드를 먼저 정의하고, 맞는 도구를 골라야 한다.

2장 · TimescaleDB — Postgres 위의 시계열

TimescaleDB는 시계열 DB라기보다 시계열 친화 Postgres 확장이다. 2017년 등장한 이래 "SQL을 사랑하지만 시계열 압축과 파티셔닝은 자동화하고 싶다"는 팀의 압도적 1위 선택.

핵심 개념

Hypertable — 시간 컬럼 기준으로 자동 파티셔닝된 테이블. 사용자는 일반 테이블처럼 본다.
Chunk — Hypertable의 시간 청크 (예: 7일 단위). 오래된 청크는 압축·이동·삭제 가능.
Continuous Aggregate — 머티리얼라이즈드 뷰 + 자동 리프레시. 미리 집계된 결과를 빠르게 읽는다.
Compression — 행 기반에서 컬럼 기반으로 변환 후 압축 (보통 90% 이상 절약).

강점

표준 PostgreSQL — JOIN, 윈도우, CTE, 외래키, JSON, 지리정보까지 다 된다.
풀스택 — 시계열만이 아니라 관계형 데이터와 한 DB에서 다룰 수 있다.
운영 인력이 Postgres에 익숙하다 — 백업·복제·모니터링 도구 그대로.
Timescale Cloud (관리형) 옵션도 성숙.

약점

메트릭 카디널리티 측면에서 Prometheus·VictoriaMetrics보다 무겁다.
100만 series 이상으로 가면 인덱스 비용이 빠르게 증가.
ClickHouse만큼 대규모 OLAP 쿼리에서 빠르지 않다.

언제 고르나

이미 Postgres를 쓰고 있는 팀, 그리고 시계열을 보조 워크로드로 다루는 경우.
SQL JOIN이 자주 필요한 경우 (예: 디바이스 메타데이터와 센서 데이터를 함께).
금융 분석처럼 정확도와 트랜잭션이 중요한 경우.

-- TimescaleDB hypertable 생성
CREATE TABLE metrics (
  time TIMESTAMPTZ NOT NULL,
  device_id TEXT NOT NULL,
  temperature DOUBLE PRECISION,
  humidity DOUBLE PRECISION
);

SELECT create_hypertable('metrics', 'time');

-- 시간 청크 자동 압축 정책
ALTER TABLE metrics SET (
  timescaledb.compress,
  timescaledb.compress_segmentby = 'device_id'
);
SELECT add_compression_policy('metrics', INTERVAL '7 days');

-- 연속 집계
CREATE MATERIALIZED VIEW metrics_hourly
WITH (timescaledb.continuous) AS
SELECT
  time_bucket('1 hour', time) AS bucket,
  device_id,
  AVG(temperature) AS avg_temp,
  MAX(temperature) AS max_temp
FROM metrics
GROUP BY bucket, device_id;

3장 · InfluxDB 3 (DataFusion + Arrow) — 완전히 새로워진 InfluxDB

InfluxDB 1.x → 2.x → 3.x로 오면서 내부가 두 번 갈렸다. 2.x의 Flux 언어는 거의 폐기 수순이고, 3.x는 Apache DataFusion 쿼리 엔진 + Apache Arrow 메모리 포맷 + Apache Parquet 스토리지 위에 다시 지어졌다. 사실상 "InfluxDB라는 이름의 Arrow 시계열 데이터베이스"다.

핵심 변화

언어 — InfluxQL과 SQL 둘 다 지원. Flux는 사실상 deprecated.
엔진 — Rust로 작성된 IOx 엔진. DataFusion이 쿼리 플래너.
스토리지 — Parquet 파일 + 오브젝트 스토리지 (S3, GCS) 기반.
에디션 — Core(오픈소스, 단일 노드), Enterprise(클러스터·HA), Cloud(관리형, 서버리스).

강점

표준 SQL 지원 — 이전의 InfluxQL/Flux 학습 부담이 사라짐.
Arrow Flight SQL로 클라이언트 통신 — 빠르고 표준화됨.
오브젝트 스토리지에 직접 쓰기 — 사실상 무제한 보관, 저렴.
IoT 워크로드용 압축률·ingest 처리량 우수.

약점

2.x → 3.x 마이그레이션 경로가 깨끗하지 않음. 2.x를 운영 중이면 통증.
클러스터(Enterprise)는 유료. 큰 규모 OSS 옵션이 약함.
생태계가 Telegraf·Chronograf 시절에 비해 분산됨.

언제 고르나

IoT/센서 데이터 — 디바이스 수십만, 압축이 핵심인 경우.
이미 InfluxDB 1.x/2.x를 쓰고 있다면 마이그레이션 경로로.
오브젝트 스토리지에 시계열을 평평하게 쌓고 싶을 때.

-- InfluxDB 3 SQL 예시 (DataFusion)
SELECT
  date_bin('1 hour', time) AS hour,
  device_id,
  AVG(temperature) AS avg_temp
FROM metrics
WHERE time > now() - INTERVAL '7 days'
GROUP BY 1, 2
ORDER BY 1 DESC;

4장 · QuestDB — SQL과 빠른 ingest의 만남

QuestDB는 자바로 작성된, 시계열 특화 컬럼 스토어다. 핵심 어필 포인트는 "Postgres 와이어 프로토콜 + InfluxDB Line Protocol을 동시에 받는다". SQL을 쓰면서 InfluxDB 호환 클라이언트로 ingest 할 수 있다는 뜻.

핵심 개념

SYMBOL 타입 — 반복되는 문자열을 dictionary encoding으로 저장. 카디널리티 관리에 효과적.
PARTITION BY — DAY/MONTH/HOUR 단위 파티션. 자동 보존(retention)으로 오래된 파티션 자동 삭제.
DEDUP — 동일 timestamp + 키 중복을 자동 제거.
ILP (InfluxDB Line Protocol) — TCP/HTTP로 라인 단위 ingest.

강점

ingest 처리량이 매우 높다 — 단일 노드 수백만 row/s 가능.
SQL이 표준에 가깝다 — PG 와이어로 일반 클라이언트가 그대로 연결.
빠른 시계열 JOIN — ASOF JOIN(가장 가까운 시간) 지원이 깊다.
금융 틱 데이터 쪽에서 잡힌 명성.

약점

클러스터(분산)는 Enterprise 유료. OSS는 단일 노드.
생태계가 작다 — 운영 도구·예제·SI 인력 등이 다른 후보 대비 적음.
일반 데이터(트랜잭션)에는 적합하지 않다.

언제 고르나

금융 시장 데이터(틱) — 빠른 ASOF JOIN과 정확도가 필수.
단일 노드에서 매우 높은 ingest 처리량이 필요한 경우.
SQL을 쓰면서 InfluxDB 클라이언트 호환을 받고 싶을 때.

-- QuestDB ASOF JOIN — 시계열 특화
SELECT
  trades.timestamp,
  trades.symbol,
  trades.price,
  quotes.bid,
  quotes.ask
FROM trades
ASOF JOIN quotes
WHERE trades.symbol = quotes.symbol
  AND trades.timestamp > '2026-01-01';

5장 · ClickHouse — 컬럼 스토어의 압도적 성능

ClickHouse는 엄밀히 말해 시계열 DB가 아니라 OLAP 컬럼 스토어다. 그런데 시간 컬럼으로 정렬·파티션하면 시계열 DB로 쓸 수 있고, 거기서 다른 시계열 DB들을 압도하는 분석 성능을 낸다. 2024-2026 사이 옵저버빌리티 영역에서 가장 많이 채택된 백엔드 중 하나.

핵심 개념

MergeTree 엔진 패밀리 — ORDER BY로 정렬, PARTITION BY로 분할. ReplicatedMergeTree로 복제.
컬럼 압축 — LZ4(기본), ZSTD, Delta, DoubleDelta, Gorilla 등 코덱 선택 가능.
Materialized View — 트리거 기반 사전 집계. continuous aggregate 비슷.
Projection — 같은 데이터를 다른 정렬로 한 번 더 저장 → 다른 쿼리 패턴에도 빠름.

강점

분석 쿼리 속도가 압도적이다 — 동급 OLAP DB와 비교해도 상위.
다양한 코덱 — Gorilla(부동소수점), DoubleDelta(시간) 등 시계열 특화 압축.
거의 모든 입출력 — JDBC, ODBC, HTTP, Kafka 통합, Parquet 외부 테이블.
거대 데이터 (수십~수백 TB)에서도 잘 돈다.

약점

단건 UPDATE/DELETE에 약하다 (배치 머지 모델). 트랜잭션 워크로드에는 부적합.
운영이 복잡 — 머지·복제·zookeeper(또는 ClickHouse Keeper) 학습 필요.
메트릭 카디널리티에서 InfluxDB·VictoriaMetrics만큼 자동화돼 있지 않음.

언제 고르나

OpenTelemetry 백엔드 — OTel 트레이스/로그/메트릭 통합 저장.
대규모 로그 분석.
BI + 시계열 결합 (분석가가 SQL로 자유롭게 쿼리).
사용자 행동 이벤트 + 시계열 통합 DW.

-- ClickHouse: 시계열 + Gorilla 압축
CREATE TABLE metrics (
  time DateTime64(3, 'UTC') CODEC(DoubleDelta, ZSTD),
  device_id LowCardinality(String),
  metric LowCardinality(String),
  value Float64 CODEC(Gorilla, LZ4)
) ENGINE = MergeTree
PARTITION BY toYYYYMM(time)
ORDER BY (device_id, metric, time);

-- 사전 집계 머티리얼라이즈드 뷰
CREATE MATERIALIZED VIEW metrics_hourly
ENGINE = AggregatingMergeTree
PARTITION BY toYYYYMM(hour) ORDER BY (device_id, metric, hour) AS
SELECT
  toStartOfHour(time) AS hour,
  device_id,
  metric,
  avgState(value) AS avg_v,
  maxState(value) AS max_v
FROM metrics GROUP BY hour, device_id, metric;

6장 · VictoriaMetrics — Prometheus 호환 + 가벼움

VictoriaMetrics(이하 VM)는 한 문장으로 "Prometheus와 호환되는데 더 빠르고 가볍고 디스크 효율이 좋다". Prometheus의 PromQL을 거의 그대로 받고, 그 위에 MetricsQL이라는 확장을 얹는다. 2020년부터 꾸준히 성장해 2026년에는 큰 규모 메트릭 백엔드의 표준 옵션 중 하나로 자리잡았다.

핵심 개념

vmstorage / vmselect / vminsert — 클러스터에서 책임 분리된 컴포넌트.
vmagent — Prometheus의 스크레이프 대체. remote_write도 함.
vmalert — Prometheus 알림 규칙 호환.
MetricsQL — PromQL 상위 호환 + 확장(rollup_*, histogram_quantile 개선 등).

강점

Prometheus 호환 — 대시보드(Grafana)와 알림 규칙을 그대로.
디스크 사용량이 작다 — Prometheus 대비 7배 이상 절약 사례 흔함.
운영이 단순 — single-binary OSS 옵션, 클러스터 옵션 모두 명료.
카디널리티 관리 도구가 잘 만들어져 있다 (cardinality explorer).

약점

"Prometheus + 가벼움" 외의 차별점은 적다. 그 가치가 분명하지 않으면 굳이?
로그/트레이스는 별도(VictoriaLogs, VictoriaTraces). 통합 솔루션은 아님.
분산 클러스터 운영은 그래도 손이 간다.

언제 고르나

이미 Prometheus를 쓰고 있는데 보관 기간/카디널리티가 한계에 부딪힐 때.
단일 노드에서 큰 메트릭 부하를 받는 경우.
카디널리티 가시성이 필요한 경우.

# vmagent로 Prometheus 스크레이프 대체
vmagent \
  -promscrape.config=/etc/scrape_config.yml \
  -remoteWrite.url=http://vmstorage:8480/insert/0/prometheus/

# PromQL 그대로
sum(rate(http_requests_total[5m])) by (service)

# MetricsQL 확장
rollup_rate(http_requests_total[5m]:1m)

7장 · Prometheus + Mimir — Kubernetes 메트릭의 표준

Prometheus는 2026년에도 Kubernetes 메트릭의 사실상 표준이다. CNCF Graduated 프로젝트로 어디서나 돌아간다. 한계는 명확하다 — 장기 보관과 수평 확장. 이를 해결하기 위한 옵션 중 가장 보편적인 것이 Grafana Mimir (Cortex의 후계).

Prometheus의 위치

pull 기반 메트릭 — /metrics 엔드포인트를 정기 스크레이프.
PromQL — 메트릭 쿼리의 사실상 표준 언어.
로컬 디스크에 TSDB. 보통 15일 정도 보관.

Mimir가 해결하는 것

장기 보관 — 오브젝트 스토리지(S3/GCS)에 평평하게 누적. 1년+ 보관 일반화.
수평 확장 — distributor/ingester/store-gateway/querier 등 컴포넌트 분리.
multi-tenancy — 한 클러스터에서 여러 팀의 메트릭을 격리.
글로벌 뷰 — 여러 Prometheus 인스턴스를 하나로 합쳐 쿼리.

경쟁자

옵션	특징
Grafana Mimir	Cortex 후계, Grafana Labs 주도
Thanos	사이드카 모델, 같은 문제 다른 답
VictoriaMetrics cluster	더 단순, MetricsQL 확장
Cortex	Mimir로 사실상 흡수됨

강점·약점

강점: Kubernetes·CNCF 생태계와 완벽 통합, exporter 풀, 표준 PromQL. 약점: 메트릭 외(로그/트레이스)는 별도 스택, 카디널리티 폭발 시 운영이 무거움.

언제 고르나

Kubernetes 클러스터의 인프라/애플리케이션 메트릭이 메인일 때.
이미 PromQL과 Grafana로 표준화된 팀.
multi-tenant 관찰성 플랫폼을 구축할 때 (Mimir 선택).

8장 · GreptimeDB — Rust 기반 신예

GreptimeDB는 2022년 등장한 Rust 기반 시계열 DB로, 2024-2026 사이 빠르게 성장했다. 목표가 야심차다 — 메트릭·로그·트레이스를 한 DB에서, 클라우드 네이티브로.

특징

Rust로 작성 — 메모리 안정성과 성능.
SQL + PromQL + InfluxQL 동시 지원 — 마이그레이션 친화.
로컬 + 오브젝트 스토리지 분리 — 컴퓨트와 스토리지 분리, S3에 직접 쓰기.
OpenTelemetry 네이티브 — OTLP 수신을 1급으로.

강점

한 DB에서 메트릭·로그·트레이스 — 통합 관찰성 솔루션으로 매력.
오브젝트 스토리지 분리 — 저렴한 장기 보관.
활발한 OSS 커뮤니티, 클라우드 옵션도 있음.

약점

아직 성숙도 측면에서 Prometheus·ClickHouse만큼 검증되지는 않음.
운영 경험 풀이 작음.
큰 규모 production 사례가 상대적으로 적음.

언제 고르나

새 옵저버빌리티 스택을 처음부터 짤 때.
OTel 표준에 맞춘 메트릭/로그/트레이스 통합이 목표일 때.
Rust 기반의 가벼움과 단순함을 선호할 때.

9장 · M3DB / TDengine / OpenTSDB — 그 외 후보들

M3DB

우버에서 만들어 오픈소스화한 분산 TSDB.
메트릭·인덱스·집계 컴포넌트 분리.
우버 내부 규모(억 단위 series)에서 검증.
약점: 외부 채택은 좁고, 운영이 복잡.

TDengine

중국 Taos Data가 만든 IoT 특화 TSDB.
디바이스당 1 테이블 모델 — IoT 카디널리티에 효율적.
자체 SQL과 클러스터 옵션.
약점: 영어권 커뮤니티가 작고, 일부 기능은 Enterprise.

OpenTSDB

HBase 위에 시계열 인덱스를 올린 1세대 TSDB.
안정성은 좋으나 생태계가 정체.
신규 프로젝트로는 거의 선택되지 않음.

Apache Druid / Pinot

엄밀히 TSDB는 아니지만 시간 차원이 큰 OLAP에서 자주 등장.
실시간 대시보드·이벤트 분석에 강함.
시계열 메트릭 백엔드로는 무겁다.

10장 · 압축 전략 — Gorilla, ZSTD, Snappy

시계열 DB에서 디스크 사용량은 곧 비용이다. 그래서 2026년의 모든 메이저 TSDB는 여러 코덱을 조합한다.

시계열 특화 코덱

Gorilla (Facebook) — 부동소수점 시계열에 특화. XOR + Variable-length encoding으로 평균 1.37바이트/포인트.
Delta encoding — 정수 시퀀스에서 인접 값 차이만 저장. timestamp에 특히 잘 맞음.
DoubleDelta — Delta의 Delta. 시간 컬럼처럼 거의 일정한 간격에서 매우 효과적.
RLE (Run-Length Encoding) — 같은 값이 반복되는 시퀀스 압축.
Dictionary encoding — 반복되는 문자열을 ID로 (QuestDB SYMBOL, ClickHouse LowCardinality, Parquet dictionary).

범용 코덱 (위 단계 다음에)

LZ4 — 가장 빠르고 압축률은 보통. 핫 데이터에 적합.
Snappy — Google. LZ4와 비슷한 위치.
ZSTD — Facebook. 압축률과 속도 균형이 우수. 콜드 데이터에 자주.
gzip — 오래된 표준. 압축률은 괜찮으나 속도는 떨어짐.

조합 패턴

대부분의 시계열 DB는 "시계열 특화 코덱 → 범용 코덱"을 파이프라인으로 적용한다. 예를 들어 ClickHouse:

시간 컬럼: DoubleDelta + ZSTD
측정값(float): Gorilla + LZ4
카테고리 문자열: LowCardinality + ZSTD

이 조합으로 보통 원본 대비 5~20배 압축. 디스크 비용이 1/10 이하로 떨어진다.

11장 · 카디널리티 폭발 — 시계열 DB의 1번 적

"카디널리티(cardinality)"는 시계열 DB에서 가장 자주 폭발하는 항목이다. 정의는 단순하다 — 고유한 시계열의 개수.

무엇이 카디널리티를 폭발시키나

각 시계열은 보통 다음과 같이 정의된다.

metric_name{label1=value1, label2=value2, ...}

라벨의 값 조합 수가 곧 series 수다. 위험한 라벨 예:

사용자 ID — 사용자가 100만 명이면 series 100만 배.
요청 ID·세션 ID·trace ID — 거의 무한.
IP 주소 — 동적 IP면 폭발.
URL path with parameters — /user/12345/order/67890.
에러 메시지 원문 — 변동 부분이 들어가면 폭발.

폭발하면 무슨 일이 일어나나

인덱스가 메모리에 다 안 들어옴 → 쿼리 폭주.
디스크 사용량 폭증.
ingest가 느려져서 메트릭 손실.
Grafana 대시보드가 timeout.

해결 방법

라벨 위생 — 카디널리티 폭발 라벨을 식별하고 메트릭에서 빼거나, 별도로 트레이스/로그로 이동.
카디널리티 가시성 — VictoriaMetrics의 vmui cardinality explorer, Prometheus의 cardinalities 쿼리, Grafana Mimir의 분석.
카디널리티 limit — 한 series당 라벨 값 한도를 ingest 단에서 강제.
Drop / Rewrite 규칙 — 스크레이프 단계에서 위험한 라벨 제거.
샘플링·집계 — 모든 series를 보관하지 않고, 핵심 집계만.

"트레이스로 보내라" 원칙

높은 카디널리티 디멘션(사용자·요청 ID·트레이스 ID)은 메트릭이 아니라 트레이스로 보내는 것이 2026년의 표준 답이다. 메트릭은 집계, 트레이스는 디테일.

12장 · 표준 — Prometheus 노출 형식·OpenMetrics·OTel

서로 다른 시계열 DB를 보더라도, 데이터를 그쪽에 흘려보내는 표준은 점점 통합되고 있다.

Prometheus exposition format

# HELP http_requests_total Total HTTP requests
# TYPE http_requests_total counter
http_requests_total{method="GET",status="200"} 1234 1715814000000
http_requests_total{method="POST",status="201"} 56 1715814000000

가장 보편적. 모든 TSDB가 이걸 받거나 변환한다.
counter, gauge, histogram, summary 4종.

OpenMetrics

Prometheus 형식의 IETF 표준화 버전.
ExemplarLink로 트레이스 연결 가능.
기본은 Prometheus 형식과 호환.

OpenTelemetry (OTel)

메트릭·로그·트레이스 통합 표준.
OTLP 프로토콜로 collector 또는 직접 백엔드로 전송.
2026년 사실상 멀티 시그널 표준.

InfluxDB Line Protocol

measurement,tag1=value1 field1=1.0 1715814000000000000

InfluxDB·QuestDB·일부 IoT 백엔드가 받음.
IoT 게이트웨이에서 가벼운 옵션으로 자주.

권장 접근

새 프로젝트라면 OTel(OTLP)을 1급 시그널로, 그리고 백엔드에 따라 Prometheus 형식 또는 OTLP 직접 수신. 메이저 TSDB는 모두 둘 다 지원한다.

13장 · IoT vs APM vs 금융 — 누가 무엇을 골라야 하나

이제 종합. 도메인별로 2026년 5월 기준의 권장.

Kubernetes/관찰성 (메트릭 중심)

첫 선택: Prometheus + Grafana Mimir (또는 VictoriaMetrics cluster).
이유: PromQL 표준, 생태계 풍부, 카디널리티 관리 도구 성숙.
트레이스·로그도 필요: + Tempo + Loki 또는 + ClickHouse 통합.

멀티 시그널 옵저버빌리티 (메트릭 + 로그 + 트레이스 통합)

첫 선택: ClickHouse (OTel 백엔드로) 또는 GreptimeDB.
이유: 한 DB에서 SQL로 세 시그널 다, 컬럼 압축으로 비용 절감.
단점: 운영 부담은 Prometheus보다 큼.

IoT/센서 (수십~수백만 디바이스)

첫 선택: InfluxDB 3 또는 TDengine 또는 TimescaleDB.
이유: 압축률, ingest 처리량, 다운샘플링, edge 통합.
선택 기준: 압도적 ingest가 필요하면 TDengine/QuestDB, SQL과 일반 데이터 결합이면 TimescaleDB, 오브젝트 스토리지 통합이면 InfluxDB 3.

금융 시장 데이터 (틱·호가)

첫 선택: QuestDB 또는 ClickHouse 또는 kdb+.
이유: ns 단위 timestamp, ASOF JOIN, 빠른 시계열 분석.
kdb+의 위치: 여전히 일부 헤지펀드의 최상위 선택. 비용·인력 풀이 진입장벽.

일반 OLAP + 시계열

첫 선택: ClickHouse 또는 TimescaleDB.
이유: SQL로 BI·시계열 결합.
선택 기준: 트랜잭션·관계형 데이터 결합이 크면 TimescaleDB, 대규모 분석 쿼리가 메인이면 ClickHouse.

안티패턴 7가지

"시계열 DB 하나로 다" — 워크로드를 안 나누면 카디널리티 모델이 깨진다.
메트릭에 사용자 ID·요청 ID 박기 — 카디널리티 폭발.
압축 코덱 기본값 그대로 — 컬럼 특성에 맞게 골라야 5배 차이.
보관 정책 없이 무한 누적 — 디스크 비용이 1년 만에 폭주.
continuous aggregate 안 쓰기 — 매번 raw에서 집계.
Prometheus만으로 1년+ 보관 — Mimir/VictoriaMetrics/Thanos 둘 중 하나.
메트릭과 트레이스 책임 혼동 — 디테일은 트레이스로, 집계는 메트릭으로.

다음 글 예고

다음 후보: OpenTelemetry 깊게 — Collector·Processor·Exporter 실전, Grafana 대시보드 디자인 가이드, 카디널리티 폭발 사례 분석과 운영 패턴.

"시계열은 한 가지 워크로드가 아니다. 메트릭·로그·트레이스·IoT는 같은 모양으로 보여도 다른 문제다. 다른 도구로 푸는 게 정답이다."

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

프롤로그 — "시계열 DB 하나로 다 되는 시대는 끝났다"

1장 · 2026년 시계열 DB 지도 — 메트릭·로그·트레이스·IoT 4축

2장 · TimescaleDB — Postgres 위의 시계열

핵심 개념

강점

약점

언제 고르나

3장 · InfluxDB 3 (DataFusion + Arrow) — 완전히 새로워진 InfluxDB

핵심 변화

강점

약점

언제 고르나

4장 · QuestDB — SQL과 빠른 ingest의 만남

핵심 개념

강점

약점

언제 고르나

5장 · ClickHouse — 컬럼 스토어의 압도적 성능

핵심 개념

강점

약점

언제 고르나

6장 · VictoriaMetrics — Prometheus 호환 + 가벼움

핵심 개념

강점

약점

언제 고르나

7장 · Prometheus + Mimir — Kubernetes 메트릭의 표준

Prometheus의 위치

Mimir가 해결하는 것

경쟁자

강점·약점

언제 고르나

8장 · GreptimeDB — Rust 기반 신예

특징

강점

약점

언제 고르나

9장 · M3DB / TDengine / OpenTSDB — 그 외 후보들

M3DB

TDengine

OpenTSDB

Apache Druid / Pinot

10장 · 압축 전략 — Gorilla, ZSTD, Snappy

시계열 특화 코덱

범용 코덱 (위 단계 다음에)

조합 패턴

11장 · 카디널리티 폭발 — 시계열 DB의 1번 적

무엇이 카디널리티를 폭발시키나

폭발하면 무슨 일이 일어나나

해결 방법

"트레이스로 보내라" 원칙

12장 · 표준 — Prometheus 노출 형식·OpenMetrics·OTel

Prometheus exposition format

OpenMetrics

OpenTelemetry (OTel)

InfluxDB Line Protocol

권장 접근

13장 · IoT vs APM vs 금융 — 누가 무엇을 골라야 하나

Kubernetes/관찰성 (메트릭 중심)

멀티 시그널 옵저버빌리티 (메트릭 + 로그 + 트레이스 통합)

IoT/센서 (수십~수백만 디바이스)

금융 시장 데이터 (틱·호가)

일반 OLAP + 시계열

안티패턴 7가지

다음 글 예고

참고 / References