135. 시계열 데이터베이스 (Time Series DB) — InfluxDB/TimescaleDB/QuestDB

핵심 인사이트 (3줄 요약)

본질: 시계열 DB(TSDB, Time Series Database)는 타임스탬프를 기본 인덱스로 설계하여 시간 순 추가(Append) 전용 워크로드에서 범용 DB 대비 10~100배 높은 압축률과 쓰기 처리량을 달성한다.
가치: 자동 데이터 보존 정책(Retention Policy)과 다운샘플링(Downsampling)으로 수개월치 원시 데이터를 집계 데이터로 압축하여 무한정 증가하는 IoT·모니터링 데이터를 비용 효율적으로 관리한다.
판단 포인트: SQL 친숙도가 높으면 TimescaleDB, 성능·비용 최우선이면 InfluxDB, 초고속 삽입(수백만 rows/sec)이 필요하면 QuestDB를 선택하는 것이 실무 기준이다.

Ⅰ. 개요 및 필요성

시계열 데이터의 특성

┌──────────────────────────────────────────────────────────┐
│              시계열 데이터의 4가지 특성                     │
│                                                          │
│  1. 시간 순서 (Time-Ordered)                              │
│     타임스탬프가 기본 식별자이자 정렬 기준                    │
│                                                          │
│  2. 추가 전용 (Append-Only)                               │
│     과거 데이터 수정 거의 없음 → 쓰기 최적화                 │
│                                                          │
│  3. 고빈도 쓰기 (High Write Throughput)                   │
│     초당 수천~수백만 개의 센서 포인트 동시 유입               │
│                                                          │
│  4. 시간 기반 쿼리 (Time-Range Query)                     │
│     "지난 1시간 평균 CPU", "어제 최대 온도" 등              │
└──────────────────────────────────────────────────────────┘

범용 DB vs 시계열 DB 비교

항목	RDBMS/MongoDB	시계열 DB
기본 인덱스	PK (임의 키)	타임스탬프
쓰기 패턴	CRUD	주로 INSERT (Append)
삭제 방식	개별 행 삭제	TTL 기반 일괄 삭제
압축	범용 압축	델타 인코딩 + Gorilla 압축
쿼리 특화	범용 SQL	시간 집계 함수 (rollup, downsampling)
저장 효율	기준	5~30배 효율적

📢 섹션 요약 비유

시계열 DB는 타임랩스 영상을 위한 카메라와 같다. 매 초 같은 각도로 찍는다는 사실(타임스탬프 순서)을 알기 때문에, 일반 카메라보다 훨씬 압축률이 높고 "어제 오전 8시부터 9시 사이"를 빠르게 되감아볼 수 있다.

Ⅱ. 아키텍처 및 핵심 원리

InfluxDB 핵심 개념 구조

┌────────────────────────────────────────────────────────────┐
│                  InfluxDB 데이터 모델                        │
│                                                            │
│  Measurement (≈ 테이블):  "cpu_usage"                       │
│  ┌──────────────┬───────────────────┬────────────────────┐ │
│  │  Timestamp   │     Tags (인덱스)  │  Fields (값)       │ │
│  │  (ns 정밀도) │  host | region    │  usage_user|idle   │ │
│  ├──────────────┼──────┬────────────┼────────────────────┤ │
│  │ 1714550400ns │ web1 │ ap-korea   │   45.2  |  54.8   │ │
│  │ 1714550460ns │ web1 │ ap-korea   │   47.1  |  52.9   │ │
│  │ 1714550400ns │ db1  │ ap-korea   │   12.3  |  87.7   │ │
│  └──────────────┴──────┴────────────┴────────────────────┘ │
│                                                            │
│  Tags: 인덱싱, 그룹핑 기준 (low cardinality 권장)            │
│  Fields: 실제 측정값, 집계 대상 (숫자/문자열/불리언)            │
│  Series: Measurement + Tags의 고유 조합                      │
└────────────────────────────────────────────────────────────┘

InfluxDB 보존 정책 (Retention Policy)과 다운샘플링

원시 데이터 (1초 간격, 30일 보관)
       │
       ↓ Continuous Query / Task
1분 집계 (avg, min, max) → 1년 보관
       │
       ↓
1시간 집계            → 5년 보관
       │
       ↓
1일 집계              → 영구 보관

결과: 스토리지 99% 절약 (1초 × 365일 → 1일 × 365일)

TimescaleDB 구조 (PostgreSQL 확장)

┌──────────────────────────────────────────────────────────┐
│                 TimescaleDB 아키텍처                       │
│                                                          │
│  Hypertable (논리적 단일 테이블)                           │
│  ┌──────────────────────────────────────────────────┐   │
│  │  CREATE TABLE metrics (                          │   │
│  │    time  TIMESTAMPTZ NOT NULL,                   │   │
│  │    host  TEXT,                                   │   │
│  │    cpu   DOUBLE PRECISION                        │   │
│  │  );                                              │   │
│  │  SELECT create_hypertable('metrics', 'time');    │   │
│  └──────────────────────────────────────────────────┘   │
│                        ↓                                 │
│  Chunks (시간 기반 자동 파티션):                           │
│  chunk_2026_04_01  |  chunk_2026_04_02  |  ...           │
│                                                          │
│  * 오래된 Chunk → 저비용 스토리지로 자동 이동(티어링)         │
│  * 풀 SQL 지원: JOIN, Window Function, CTE 모두 가능       │
└──────────────────────────────────────────────────────────┘

QuestDB 고성능 인제스션 구조

QuestDB 성능 비결:
  1. 열 기반 (Columnar) 저장 → 특정 필드 집계 시 I/O 최소화
  2. 메모리 매핑 파일 (Memory-Mapped Files) → 커널 I/O 우회
  3. SIMD (Single Instruction, Multiple Data) 활용
  4. 파티션 병렬 처리

성능: 단일 서버 기준 수백만 rows/sec 삽입

DB	쿼리 언어	특징	최고 성능 지표
InfluxDB	Flux / InfluxQL	네이티브 TSDB, 클라우드 관리형	쓰기 200K pts/sec
TimescaleDB	SQL (PostgreSQL)	SQL 호환, Hypertable	쓰기 100K rows/sec
QuestDB	SQL (방언)	열 기반, SIMD	쓰기 4M rows/sec
VictoriaMetrics	MetricsQL	Prometheus 호환, 초경량	쓰기 수십만 pts/sec

📢 섹션 요약 비유

다운샘플링은 긴 회의 영상을 요약본으로 편집하는 것과 같다. 5시간 원본(1초 데이터)을 5분 요약본(1분 평균)으로 만들면 찾아보기는 오래 걸리지 않으면서 저장 공간을 95% 절약할 수 있다.

Ⅲ. 비교 및 연결

Prometheus vs InfluxDB 비교

항목	Prometheus	InfluxDB
수집 방식	Pull (스크레이핑)	Push (직접 삽입)
데이터 모델	레이블 기반 시계열	Measurement + Tags
장기 보관	취약 (Thanos/Cortex 필요)	내장 보존 정책
쿼리 언어	PromQL	Flux / InfluxQL
생태계	Grafana 통합 강력	InfluxDB Cloud
적합	쿠버네티스 모니터링	IoT, 범용 시계열

시계열 압축 기술 (Gorilla 알고리즘)

페이스북 Gorilla 시계열 압축:
  - XOR 기반 델타 인코딩
  - 연속 타임스탬프: 각 시간 차이만 저장
  - 연속 부동소수점: XOR 비트만 저장

예시:
  원시: 23.5, 23.7, 23.6, 23.8  (각 8바이트 = 32바이트)
  압축: 23.5, +0.2, -0.1, +0.2  (델타 2비트 = 0.25바이트)
  압축률: 128:1 까지 가능

📢 섹션 요약 비유

Prometheus와 InfluxDB의 차이는 기자(Pull)와 제보자(Push)의 차이다. Prometheus는 정기적으로 각 서버에 찾아가 수치를 읽어오고(스크레이핑), InfluxDB는 각 센서가 직접 데이터를 보내준다(Push). 서버가 적으면 Pull이 간편하고, 서버가 수만 대면 Push가 확장성이 높다.

Ⅳ. 실무 적용 및 기술사 판단

IoT 플랫폼 아키텍처 설계

센서 디바이스
     │ MQTT/HTTP
     ↓
IoT 브로커(Mosquitto/AWS IoT)
     │ 스트림 처리
     ↓
Kafka (버퍼 + 내결함성)
     │
     ↓
시계열 DB (InfluxDB/TimescaleDB)
     │
     ↓
Grafana (시각화 대시보드)
     │
     ↓
이상 감지 (ML 모델 → 알람)

기술사 설계 체크리스트

항목	결정 기준
카디널리티 관리	Tags 조합 수 < 수백만 (InfluxDB High Cardinality 주의)
보존 정책 설계	원시→1분→1시간 다운샘플링 계층 정의
쿼리 최적화	시간 범위 WHERE 절 항상 포함
파티션 전략	시간 기반 파티션으로 오래된 데이터 빠른 삭제
고가용성	InfluxDB Enterprise 클러스터 or 관리형 클라우드

📢 섹션 요약 비유

시계열 DB의 High Cardinality 문제는 도서관 분류 체계가 너무 세밀한 것과 같다. 책 한 권마다 고유한 선반 번호를 붙이면 목록 관리 비용이 도서관보다 더 커진다. Tags는 적당한 범주(호스트명, 리전)로 묶어야 인덱스 효율이 유지된다.

Ⅴ. 기대효과 및 결론

도입 효과 비교 (IoT 플랫폼 실사례)

항목	PostgreSQL	TimescaleDB	개선율
1주일 데이터 쓰기	55K rows/sec	110K rows/sec	2배
1개월 집계 쿼리	45sec	3sec	15배
스토리지(압축 후)	100GB	12GB	8.3배 절약
데이터 티어링	수동	자동	—

결론

시계열 DB는 IoT·모니터링·금융 틱 데이터처럼 타임스탬프가 핵심이고 쓰기가 압도적으로 많은 워크로드의 표준 인프라로 자리잡았다. 기술사 시험에서는 TSDB의 4가지 특성, 보존 정책+다운샘플링 설계, InfluxDB 데이터 모델(Tags/Fields/Measurement), Gorilla 압축 알고리즘 원리가 핵심 논점이다.

📢 섹션 요약 비유

시계열 DB 도입은 기상청이 기온 기록을 위한 전용 시스템을 도입하는 것과 같다. 일반 스프레드시트(RDBMS)에도 기록할 수 있지만, 매분 전국 수천 곳의 기온을 기록하고 "지난 10년 8월 평균"을 즉시 뽑으려면 기상 전용 시스템이 필요하다.

📌 관련 개념 맵

개념	관계	설명
Gorilla 압축	저장 최적화	델타 XOR 인코딩, 시계열 전용
Retention Policy	데이터 관리	보존 기간 정책, 자동 삭제
Downsampling	집계 최적화	원시 → 집계 데이터 계층화
Hypertable	TimescaleDB 구조	시간 기반 자동 파티션 테이블
PromQL	연관 기술	Prometheus 시계열 쿼리 언어

📈 관련 키워드 및 발전 흐름도

[관계형 DB (RDBMS) — 시계열 저장 시 인덱스 팽창·쓰기 병목 발생]
    │
    ▼
[시계열 DB (TSDB) — 시간 스탬프 기반 압축·집계 최적화 전문 스토리지]
    │
    ▼
[InfluxDB / TimescaleDB — 대표 TSDB, 라인 프로토콜·SQL 인터페이스 제공]
    │
    ▼
[다운샘플링·보존 정책 (Downsampling & Retention) — 오래된 데이터 자동 집계·삭제]
    │
    ▼
[스트리밍 연계 (Kafka → TSDB) — 실시간 지표 수집·저장·알림 파이프라인]

이 흐름은 RDBMS의 시계열 저장 한계를 전문 TSDB가 극복하고, 다운샘플링으로 장기 보관을 최적화하며, 실시간 스트리밍 파이프라인으로 통합되는 과정을 보여준다.

👶 어린이를 위한 3줄 비유 설명

시계열 DB는 온도계 일지와 같아요. 매시간 온도를 기록하고, "이번 주 가장 더웠던 날"을 바로 찾아줘요.
다운샘플링은 긴 노트를 요약본으로 줄이는 것 — 매분 기록 대신 하루 평균만 남겨도 큰 흐름은 보여요.
시계열 DB가 없으면 수백만 개의 센서 신호가 쏟아질 때 일반 DB가 숨이 막혀버리는데, 시계열 DB는 이런 상황에 딱 맞게 만들어진 거예요.