[DB] 시계열 기반 실시간 데이터 수집 환경에서의 고속 Insert 성능 최적화를 위한 데이터베이스 기술 비교 및 아키텍처 설계

[gsandoo]

💐 개요

💡 ‘코알람’이라는 프로젝트는 실시간으로 수집되는 시세·체결·캔들 데이터를 초당 수천 건 이상 고속으로 데이터베이스에 저장해야 하는 환경이다.

이에 여러 시계열 지원 DBMS 간 Insert 성능을 비교하고, 가장 적합한 저장소 기술을 결정하기 위한 사전 연구를 진행한다.

🧭 핵심 문제 정의

실시간으로 대량의 시세 데이터를 수집해야 하는 환경에서,

가장 빠르고 안정적으로 insert를 처리할 수 있는 데이터베이스는 무엇인가?

🧠 주제 (타이틀)

"시계열 기반 실시간 데이터 수집 환경에서의 고속 Insert 성능 최적화를 위한 데이터베이스 기술 비교 및 아키텍처 설계"

왜 TimescaleDB를 선택했는가?

💡 TimescaleDB는 실시간 insert + Join 연산을 통한 쿼리가 가능한 대표적인 시계열 DB다.

💡 TimescaleDB는 PostgreSQL 기반이기 때문에 집계 서버인 Spring의 ORM, SQL과 호환에 문제가 없다.

💡 러닝 커브가 적다.

🔎 비교군 선정 기준

• 현업에서 고려 가능한 실질적 선택지 중심 (PostgreSQL 또는 Influx 기반이 많은 기업 환경 반영)
• 서로 다른 스토리지 모델 (Row vs Column vs Document)
• SQL 호환성, 시계열 특화 기능 유무 등을 비교 기준으로 설정

💡 비교 DBMS 선정 이유

DBMS	선택 이유	카테고리
TimescaleDB	PostgreSQL 기반 확장으로 SQL 호환성과 시계열 최적화 기능 모두 제공	시계열 DB 확장형
InfluxDB	시계열 전용, insert 처리량 최고 수준	시계열 전용
ClickHouse	OLAP 성능 우수, 열지향 insert 성능도 점검	열지향 DB
MongoDB TimeSeries	범용 NoSQL에 시계열 컬렉션 기능 추가	Document 기반
PostgreSQL (기본)	Timescale과 비교군으로서 기준선 역할	범용 RDB

📌 정리: 세 모델 비교 (Row vs Column vs Document)

특성	Row-Oriented	Column-Oriented	Document-Oriented
저장 단위	행 (tuple)	열 (column)	문서 (JSON)
Insert 성능	빠름	느림 (batch는 빠름)	빠름
Select 성능	범용적	특정 컬럼 빠름	유연성은 높음
Join, SQL 쿼리	매우 강함	제한적	제한적
압축 효율	낮음	매우 높음	낮음
시계열 적합성	중간 이상	분석 중심에 매우 좋음	기본적으로 비효율적
예시 DBMS	PostgreSQL, MySQL	ClickHouse, Druid	MongoDB

🗜️ 시계열 데이터베이스에서 “압축”의 중요성

💡 시계열 데이터는 양이 기하급수적으로 늘어나고 값의 패턴이 반복되며 오래된 데이터는 거의 읽지 않기 때문에 압축이 매우 효과적이고 중요하다.

🧬 DBMS 구조 및 특성 비교

DBMS	저장 구조	특징	MVCC	트랜잭션
TimescaleDB	Row (PostgreSQL 기반)	하이퍼테이블, 압축, continuous aggregate	✅	✅ FULL ACID
InfluxDB	LSM + TSM 구조	WAL + TSM 압축 구조, 고속 write	❌	❌ (단일 insert 중심)
ClickHouse	Column (MergeTree)	고속 OLAP, batch 최적화	❌	⚠️ 비동기 중심
MongoDB TS	Document (Bucket 구조)	유연한 schema, 최근 시계열 컬렉션	⚠️ Document 수준 MVCC	✅ 단일 문장 ACID
PostgreSQL	Row	전통적 RDB, 범용 안정성	✅	✅ FULL ACID

🛠️ 워크 로드

📋 테스트 데이터

• 데이터 구조: 시계열 데이터는 JSON 형식으로 구성되며, 각 데이터 레코드는 거래소에서 발생하는 시세 데이터를 포함

{
  "timestamp": "2025-04-17T13:00:00Z",
  "exchange": "Binance",
  "symbol": "BTC/USDT",
  "open": 75420.1,
  "high": 75880.9,
  "low": 74820.0,
  "close": 75210.5,
  "volume": 123.45
}

📄 고속 Insert 쿼리 예시

• tickers 테이블 Insert

INSERT INTO tickers (
    timestamp, exchange, base_symbol, quote_symbol, open, high, low, close, last, previous_close,
    change, percentage, base_volume, quote_volume
)
VALUES (to_timestamp($1 / 1000.0), $2, $3, $4, $5, $6, $7, $8, $9, $10, $11, $12, $13, $14)
ON CONFLICT (timestamp, exchange, base_symbol, quote_symbol) DO NOTHING;

• candles 테이블 Insert

INSERT INTO candles (
  timestamp, exchange, base_symbol, quote_symbol, timeframe, open, high, low, close, volume
) 
VALUES (to_timestamp($1 / 1000.0), $2, $3, $4, $5, $6, $7, $8, $9, $10)
ON CONFLICT (timestamp, exchange, base_symbol, quote_symbol, timeframe) DO NOTHING;

• trades 테이블 Insert

INSERT INTO trades (
  timestamp, exchange, base_symbol, quote_symbol, trade_id, price, amount, cost, side
) 
VALUES (to_timestamp($1 / 1000.0), $2, $3, $4, $5, $6, $7, $8, $9)
ON CONFLICT (timestamp, exchange, base_symbol, quote_symbol) DO NOTHING;

♻️ 테스트 환경

인프라

• AWS EC2: 테스트를 위한 EC2 인스턴스를 3대 구성하여 부하를 분산하고, 안정적인 테스트 환경 구축
  • 부하기 EC2 인스턴스 1대, 모니터링 EC2 인스턴스 1대, DB EC2 인스턴스 1대
  • 인스턴스 종류: t4g.medium
  • OS: Ubuntu 22.04 LTS
  • 스토리지: SSD 기반 EBS 볼륨 100GB
  • SSD를 사용하여 저장 성능 병목을 줄이고, 네트워크 및 디스크 안정성 확보

모니터링 시스템 EC2

• Prometheus + Grafana를 사용하여 각 DBMS의 성능 메트릭을 실시간으로 모니터링

데이터베이스 EC2

• PostgreSQL, InfluxDB, TimescaleDB, MongoDB, ClickHouse 세팅 및 동일 스키마 적용
• exporter 설치 진행중

부하 생성 도구 EC2

• JMeter를 사용하여 각 DBMS에 대해 동일한 워크로드를 적용하고, 고속 Insert 작업을 측정

📜 시나리오

시나리오 1: Sequential Insert

• 목표: 1초당 1,000건 이상 Insert 가능한지 평가
• 설명: 10분 동안 지속적으로 Insert 요청을 보내며 TPS를 측정
• 측정 항목: 평균 Insert TPS, 평균 Insert latency 등

시나리오 2: Burst Insert

• 목표: 급격한 트래픽을 처리하는 성능 평가
• 설명: 30초 동안 1초당 5,000건의 Insert 요청을 보냄
• 측정 항목: 초당 Insert TPS, 에러율, 평균/최댓값 latency 등

시나리오 3: Long-term Insertion

• 목표: 장시간에 걸쳐 안정적인 Insert 성능 유지 여부 평가
• 설명: 1시간 동안 500건/초로 데이터를 지속적으로 삽입
• 측정 항목: 전체 CPU 사용량, 메모리 사용량, 에러율 등

시나리오 4: Multi-threaded Insert

• 목표: 멀티 스레딩을 통한 Insert 성능 분석
• 설명: 10, 50, 100 쓰레드를 사용하여 병렬 Insert 성능 측정
• 측정 항목: Insert TPS, 시스템 자원 사용량 등

시나리오 5: Batch Size Variation

• 목표: 배치 크기(100, 500, 1000)가 성능에 미치는 영향 분석
• 설명: 배치 크기별 Insert 성능을 측정하고 비교
• 측정 항목: 평균 TPS, 배치 크기 별 성능 변화 등

🦍 차주 진행 방향

💡 직접 성능 측정을 통해 우리의 서비스에 최적화된 데이터베이스가 “TimescaleDB”가 맞는가를 검증한다.

[ej31]

github markdown 스타일로 문법 변경했습니다.

[ej31]

@gsandoo 업데이트해주세요!