TimescaleDB로 PostgreSQL 시계열 최적화

개요

시계열 데이터는 저장량이 빠르게 증가하고, 쓰기와 집계 쿼리가 빈번하다. 기존 PostgreSQL만으로도 처리 가능하지만 운영 비용과 쿼리 응답 시간이 문제로 떠오른다. TimescaleDB는 PostgreSQL 확장으로 설계되어 기존 생태계를 활용하면서 시계열 특화 기능을 제공한다. 본문에서는 설치 절차, 기본 모델링, hypertable 활용, 압축과 인덱스, 성능 튜닝을 단계별로 살펴본다.

왜 TimescaleDB를 선택하는가

PostgreSQL과의 호환성

TimescaleDB는 PostgreSQL 확장이므로 기존 SQL, 확장, 드라이버, 백업 도구를 그대로 사용 가능하다. 이로 인해 마이그레이션 비용이 낮다.

시계열 최적화 기능

주요 기능은 hypertable(자동 파티셔닝), 투명한 압축, 시계열 전용 집계 함수, continuous aggregate 등이다. 이 기능들은 대량의 시계열 데이터를 효율적으로 저장하고 빠르게 조회하도록 돕는다.

설치 및 초기 설정

패키지 설치 예시 (Ubuntu)

간단한 설치 예시를 제공한다. 로컬 테스트나 프로덕션용으로 패키지 또는 Docker를 선택할 수 있다.

sudo apt install -y gnupg2 wget ca-certificates
wget -qO- https://packagecloud.io/timescale/timescaledb/gpgkey | sudo apt-key add -
sudo add-apt-repository "deb https://packagecloud.io/timescale/timescaledb/ubuntu/ $(lsb_release -cs) main"
sudo apt update
sudo apt install -y timescaledb-postgresql-14
sudo timescaledb-tune --pg14
sudo systemctl restart postgresql

위 명령은 PostgreSQL 14 기반 TimescaleDB를 설치하고 기본 튜닝을 적용한다. Docker 사용 시에는 공식 이미지를 참고한다.

기본 데이터 모델링

테이블 설계

시계열 데이터는 시간 열(timestamp)과 태그(tag) 및 메트릭(metric)으로 구성된다. 태그는 보통 저비용 인덱스를 적용하고, 메트릭은 컬럼으로 둔다.

CREATE TABLE sensor_data (
  time TIMESTAMPTZ NOT NULL,
  device_id TEXT NOT NULL,
  temperature DOUBLE PRECISION,
  humidity DOUBLE PRECISION,
  PRIMARY KEY (time, device_id)
);
-- hypertable로 변환
SELECT create_hypertable('sensor_data', 'time', chunk_time_interval => interval '1 day');

chunk_time_interval는 데이터 특성에 맞춰 설정한다. 짧게 설정하면 많은 조각(chunk)이 생기고, 길게 설정하면 단일 조각이 커진다.

Hypertable과 파티셔닝 전략

chunk 크기와 파티션 키

chunk는 성능의 핵심 요소다. 대개 하루, 한 주 또는 한 달 단위로 설정하며, 쓰기 속도와 보관 전략에 따라 조정한다. 복합 파티셔닝이 필요한 경우 태그 컬럼을 기반으로 추가 파티셔닝을 고려한다.

continuous aggregate

실시간으로 집계를 계속 유지해야 하는 경우 continuous aggregate를 사용하면 쿼리 비용을 줄일 수 있다.

CREATE MATERIALIZED VIEW daily_stats
WITH (timescaledb.continuous) AS
SELECT time_bucket('1 day', time) AS day,
       device_id,
       avg(temperature) AS avg_temp,
       max(temperature) AS max_temp
FROM sensor_data
GROUP BY day, device_id;

인덱스, 압축과 보관

적절한 인덱스 설계

인덱스는 읽기 패턴에 맞춰 만든다. 시간 범위 쿼리는 시간 인덱스 또는 기본키로 충분한 경우가 많다. 태그 기반 필터링이 잦다면 태그 컬럼에 B-tree 또는 BRIN 인덱스를 고려한다.

압축 적용

TimescaleDB는 컬럼 기반 압축을 제공해 저장 공간을 크게 절감한다. 압축은 주로 오래된 데이터에 적용한다.

ALTER TABLE sensor_data SET (
  timescaledb.compress,
  timescaledb.compress_segmentby = 'device_id'
);
SELECT add_compression_policy('sensor_data', INTERVAL '30 days');

위 예시는 30일 지난 데이터를 자동으로 압축하도록 설정한다.

성능 튜닝 전략

읽기·쓰기 균형 맞추기

쓰기 집약적 워크로드는 commit 속도, wal 설정, autovacuum 파라미터를 조정해야 한다. 읽기 빈도가 높으면 인덱스와 continuous aggregate를 통해 응답 시간을 단축한다.

주요 설정 예시

# postgresql.conf 예시
shared_buffers = 25GB
work_mem = '64MB'
maintenance_work_mem = '2GB'
effective_cache_size = '75GB'
wal_compression = on
max_wal_size = '4GB'
checkpoint_completion_target = 0.9

환경에 따라 수치는 달라진다. timescaledb-tune으로 시작값을 얻고, 모니터링 결과에 따라 조정한다.

모니터링과 운영

모니터링 지표

중요 지표는 쓰기 지연, 쿼리 응답 시간, chunk 수, 압축률, autovacuum 활동 등이다. Prometheus와 Grafana를 연동하면 실시간 대시보드로 상태를 확인할 수 있다.

백업과 보관 정책

백업은 PostgreSQL 도구와 호환된다. 오래된 데이터는 압축 후 S3 같은 오브젝트 스토리지로 내보내는 정책을 고려한다.

요약과 권장 흐름

설치: 패키지 또는 Docker 사용하여 timescaledb postgres 설치 후 timescaledb-tune 실행
모델링: 시간 열과 태그를 분리하고 hypertable로 변환
운영: 인덱스와 continuous aggregate로 조회 최적화, compression으로 저장 비용 절감
튜닝: 워크로드 기반으로 postgresql.conf를 조정하고 모니터링을 지속

시작은 간단하지만, 운영 환경에서는 모니터링과 반복적인 튜닝이 핵심이다. 특히 시계열 데이터 특성에 맞춘 chunk 크기와 압축 정책, 인덱스 전략이 전체 성능과 비용을 좌우한다. 본문에서 제시한 절차와 예시는 실제 환경에 맞춰 조정해 적용할 수 있다.

목차

개요