서버 CPU 사용률, IoT 센서 온도, 주가, 심박수 — 이 데이터의 공통점은 '시간에 따라 끊임없이 생성된다'는 것이다. 일반 DB에서 이 데이터를 다루면 왜 느리고, 시계열 DB는 어떻게 이 문제를 해결하며, 어떤 제품을 선택해야 하는지를 풀어본다.
당신이 IoT 플랫폼을 운영한다고 하자. 전국에 설치된 10만 대의 센서가 매초 온도·습도·진동 데이터를 보낸다.
이 데이터를 RDS(MySQL)에 넣으면 어떻게 될까?
RDS는 이런 워크로드를 위해 설계되지 않았다. 문제의 핵심:
이런 특수한 데이터를 위한 전문 DB가 시계열 데이터베이스(Time Series Database, TSDB) 다.
시계열 데이터(Time Series Data) 는 시간에 따라 순서대로 기록되는 데이터 포인트의 연속이다. 각 데이터 포인트는 반드시 타임스탬프를 가진다.
| 분야 | 데이터 | 빈도 | 규모 |
|---|---|---|---|
| 서버 모니터링 | CPU, 메모리, 디스크, 네트워크 | 매 초~분 | 서버 수천 대 × 수십 메트릭 |
| IoT/센서 | 온도, 습도, 진동, 위치 | 매 초~밀리초 | 센서 수만~수백만 대 |
| 금융 | 주가, 환율, 거래량 | 매 밀리초 | 수천 종목 |
| 사용자 행동 | 페이지뷰, 클릭, 세션 | 이벤트 기반 | 수백만 사용자 |
| 의료 | 심박수, 혈압, 산소포화도 | 매 초 | 환자 수만 명 |
| 에너지 | 전력 소비, 발전량, 배터리 상태 | 매 분 | 수백만 스마트미터 |
| 물류 | 차량 위치, 속도, 배송 상태 | 매 초 | 수만 대 |
CREATE TABLE sensor_data (
id BIGINT AUTO_INCREMENT PRIMARY KEY,
sensor_id VARCHAR(50),
timestamp DATETIME(3),
temperature FLOAT,
humidity FLOAT,
INDEX idx_sensor_time (sensor_id, timestamp)
);
초당 10만 건 INSERT. 한 달이면 2,592억 행. 문제:
1. 쓰기 병목: B-tree 인덱스는 INSERT마다 인덱스를 업데이트해야 한다. 데이터가 커질수록 INSERT가 느려진다.
2. 쿼리 병목: "지난 1시간의 센서별 평균 온도"를 구하려면 3.6억 행을 스캔.
3. 스토리지 폭발: 행 저장 + B-tree 인덱스 오버헤드로 데이터 크기가 원본의 2~3배.
4. 데이터 보존 정책 없음: 90일 지난 데이터를 자동으로 삭제하려면? DELETE WHERE timestamp < '...' — 2,592억 행에서 DELETE는 며칠이 걸린다.
| 문제 | 일반 DB의 한계 | TSDB의 해결 |
|---|---|---|
| 쓰기 성능 | B-tree INSERT 병목 | LSM-tree / 시간 파티션 — 쓰기에 최적화 |
| 쿼리 성능 | 전체 테이블 스캔 | 시간 기반 인덱싱 — 시간 범위 쿼리 최적화 |
| 스토리지 | 행 저장, 인덱스 오버헤드 | 컬럼나 압축 — 90%+ 압축률 |
| 데이터 보존 | DELETE 쿼리 (느림) | 자동 만료(TTL) — 설정만 하면 자동 삭제 |
| 다운샘플링 | 직접 구현 필요 | 자동 다운샘플링 — 1초 → 1분 → 1시간 자동 집계 |
RRDtool(Round Robin Database) — 1999년, Tobias Oetiker가 개발. 네트워크 모니터링 도구 MRTG의 데이터 저장소로 시작.
혁신적 아이디어: 고정 크기 DB. 데이터가 계속 들어와도 DB 파일 크기가 절대 커지지 않는다. 오래된 데이터는 자동으로 집계(다운샘플링)되어 덮어쓰기된다. "라운드 로빈" = 원형 버퍼. 끝에 도달하면 처음부터 다시 쓴다.
2010년, StumbleUpon(현 Mix)이 HBase 위에 구축한 시계열 DB. 수십억 데이터 포인트를 처리할 수 있었지만, HBase 클러스터 관리가 복잡했다.
2013년, InfluxData가 시계열에 완전히 특화된 DB를 만들었다. 전용 쿼리 언어(InfluxQL/Flux), 자동 다운샘플링, 내장 보존 정책. TSDB 시장의 선두주자가 됐다.
SoundCloud의 엔지니어들이 개발하고, 2016년 CNCF의 두 번째 졸업 프로젝트(K8s 다음)가 된 Prometheus. 쿠버네티스 환경의 사실상 표준 모니터링 TSDB다.
TSDB는 데이터를 시간 단위(예: 시간별, 일별)로 파티셔닝한다.
장점:
"지금"의 데이터는 1초 단위로 필요하지만, 1년 전 데이터는 1시간 단위면 충분하다.
원본: 매 초 데이터 → 86,400건/일
↓ 24시간 후
1분 집계: → 1,440건/일 (60배 축소)
↓ 7일 후
1시간 집계: → 24건/일 (3,600배 축소)
↓ 90일 후
삭제 (TTL)
스토리지가 시간이 지나도 무한정 증가하지 않는다. 이것이 RRDtool에서 시작된 아이디어.
시계열 데이터는 압축에 매우 유리하다:
Facebook의 2015년 VLDB 논문 "Gorilla: A Fast, Scalable, In-Memory Time Series Database"에서 제안한 XOR 기반 부동소수점 압축은 연속적인 시계열 값을 12배 압축할 수 있음을 증명했다. 이 기법은 Prometheus, InfluxDB, Timestream 등 대부분의 현대 TSDB에 채택됐다.
| 제품 | 유형 | 강점 | 적합한 경우 |
|---|---|---|---|
| Prometheus | 오픈소스, K8s 표준 | K8s 네이티브, PromQL, 풀(Pull) 모델 | K8s 모니터링 |
| InfluxDB | 오픈소스/클라우드 | 전용 DB, 풍부한 기능, SQL 지원 (3.0) | 범용 TSDB |
| AWS Timestream | 서버리스 관리형 | AWS 네이티브, IoT Core 연동 | AWS IoT |
| Grafana Mimir | 오픈소스 | Prometheus 장기 저장소, 무한 확장 | 대규모 Prometheus |
| TimescaleDB | PostgreSQL 확장 | SQL 100% 호환, PostgreSQL 생태계 | SQL 익숙한 팀 |
| ClickHouse | 컬럼나 OLAP | 초고속, 범용 분석 + 시계열 | 분석 + 시계열 통합 |
| VictoriaMetrics | 오픈소스 | Prometheus 호환, 저자원 | Prometheus 대안 |
이 시리즈의 CloudWatch 글에서 "K8s 환경에서는 Prometheus가 표준"이라고 했다. Prometheus의 핵심:
# 지난 5분간 HTTP 요청 에러율 (PromQL)
rate(http_requests_total{status=~"5.."}[5m])
/ rate(http_requests_total[5m]) * 100
TimescaleDB는 PostgreSQL의 확장(Extension) 으로 구현된 TSDB다. PostgreSQL의 모든 기능(SQL, JOIN, 인덱스, 트랜잭션)을 그대로 쓰면서 시계열 최적화를 추가한다.
AWS의 관리형 시계열 DB. 이 시리즈에서 반복되는 패턴 — 서버 관리 없이 데이터만 넣으면 된다.
핵심 기능:
시계열 데이터가 유출되면 사람의 행동 패턴이 노출된다:
Tesla의 모든 차량은 초당 수백 개의 시계열 데이터 포인트(배터리 상태, 모터 온도, GPS, 가속도)를 전송한다. 수백만 대의 차량에서 발생하는 이 데이터는 자율주행 학습, 원격 진단, 리콜 판단에 사용된다.
Uber는 M3(자체 개발 TSDB)로 수천 개의 마이크로서비스에서 발생하는 초당 수십억 개의 메트릭 데이터 포인트를 수집·저장·쿼리한다.
Cloudflare는 전 세계 300+ 데이터센터의 네트워크 장비, DNS 쿼리, DDoS 트래픽을 시계열 데이터로 수집한다. ClickHouse를 사용하여 초당 수백만 건의 메트릭을 실시간 분석.
2026년의 트렌드: 전용 TSDB와 범용 분석 DB의 경계가 흐려지고 있다.
시계열 데이터는 AI/ML의 핵심 입력이다:
AWS Timestream은 Timestream for LiveAnalytics에서 이상 감지를 내장 제공하고, CloudWatch는 Anomaly Detection 기능으로 메트릭의 이상을 AI가 자동 감지한다.
이 시리즈에서 다룬 전체 데이터 생태계의 최종 지도를 완성하면:
| 데이터 특성 | DB 유형 | 대표 제품 | 핵심 질문 |
|---|---|---|---|
| 구조화된 관계형 | 행 저장 RDBMS | Aurora, RDS | "이 주문의 상태는?" |
| 유연한 문서형 | 문서 DB | MongoDB | "이 사용자의 프로필은?" |
| 초고속 키-값 | 키-값 DB | DynamoDB | "이 세션의 데이터는?" |
| 텍스트/벡터 검색 | 검색 엔진 | OpenSearch | "이 키워드가 포함된 문서는?" |
| 대규모 분석 | 컬럼나 DW | Redshift, BigQuery | "지난 1년 카테고리별 매출?" |
| 시간 순서 데이터 | 시계열 DB | Prometheus, InfluxDB, Timestream | "지난 1시간 CPU 평균은?" |
| 파일/오브젝트 | 오브젝트 스토리지 | S3 | "이 파일을 저장/가져와" |
각 DB 유형은 다른 차원의 질문에 최적화되어 있다. 시계열 DB는 "시간"이라는 축이 핵심인 데이터를 위한 전문 도구다.
코어닷투데이의 AI 서비스에서도 시계열 데이터는 곳곳에 있다. AI 추론 서버의 응답 시간 추이(Prometheus), IoT 키오스크의 센서 데이터(Timestream), 서비스 사용량 메트릭(CloudWatch) — 이 모든 데이터가 시간의 축 위에서 흐르고, 시계열 DB가 그 흐름을 포착하고 분석한다.
"데이터에는 여러 차원이 있지만, 시간은 가장 보편적인 차원이다." 시계열 DB는 이 가장 보편적인 차원을 가장 효율적으로 다루는 도구다.