57. 시계열 데이터베이스 다운샘플링 (Downsampling) 및 보존 정책

⚠️ 이 문서는 서버의 CPU 사용량, 주식 틱 데이터, IoT 센서 온도 등 시간에 따라 끊임없이 쏟아지는 시계열 데이터를 처리하는 전문 DB(InfluxDB, Prometheus 등)에서, **무한정 쌓이는 데이터로 인해 디스크가 터지는 것을 막기 위해 오래된 고해상도 데이터를 저해상도로 뭉뚱그려(압축) 저장하는 '다운샘플링(Downsampling)'과, 유통기한이 지난 데이터를 자동으로 폐기하는 '보존 정책(Retention Policy)'**을 다룹니다.

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

  1. 본질: "지금 당장 1초 전의 1초 단위 주식 가격은 중요하지만, 3년 전의 1초 단위 주식 가격은 아무도 보지 않는다." 데이터의 가치가 시간에 반비례하여 급격히 떨어지는 시계열 데이터의 경제학적 한계를 기술적으로 해결한 아키텍처다.
  2. 가치: 다운샘플링을 통해 과거의 1초 단위 데이터 수천 개를 묶어 '1시간 단위 평균값' 1개로 변환해 저장함으로써, 3년 치 데이터를 보관하더라도 디스크 스토리지 비용을 1/100 이하로 아끼고 과거 데이터를 조회하는 쿼리 속도를 빛의 속도로 유지한다.
  3. 기술 체계: TSDB 내부의 백그라운드 엔진이 스케줄에 따라 배치(Batch) 작업을 돌며 낡은 데이터를 집계 함수(Max, Min, Avg)로 뭉치고(Downsampling), 아예 보존 기한이 지나 썩어버린 데이터 청크는 통째로 날려버린다(Retention).

Ⅰ. 시계열 데이터의 저주: 무한 팽창과 가치 하락

센서 데이터는 일반적인 회원 정보 DB와 생태계가 다르다.

  1. 폭발적인 데이터 유입량 (High Ingestion Rate):
    • 전국 10만 대의 공장 IoT 센서가 '1초'마다 온도를 찍어 데이터베이스(TSDB)로 쏜다. 초당 10만 건, 하루면 86억 건의 데이터가 쏟아진다.
    • 일반적인 관계형 DB(RDBMS)에 이 짓을 하면 하루도 못 가 디스크가 터지고 시스템이 마비된다.
  2. 데이터의 반감기 (Time Decay of Value):
    • 시계열 데이터의 핵심 특징은 '방금 찍힌 1초 전 데이터'는 에러를 탐지하기 위해 눈에 불을 켜고 보지만, '1년 전 오늘 오후 3시 5분 12초의 온도'를 궁금해하는 사람은 아무도 없다는 것이다.
    • 1년 전 데이터는 그저 "작년 3월의 하루 평균 온도"라는 거시적 통계(Trend)로만 가치를 가진다.
  3. 다운샘플링(Downsampling)의 탄생:
    • 그래서 TSDB는 기발한 아이디어를 냈다. "오래된 데이터는 어차피 세밀하게 안 보니까, 픽셀을 뭉개서 저해상도 이미지로 만들어 용량을 확 줄여버리자!"

📢 섹션 요약 비유: 아기가 태어난 첫 달에는 부모님이 귀엽다며 매일 100장씩 사진(고해상도 데이터)을 찍어 폰 용량이 꽉 찹니다. 하지만 3년이 지나면 그 사진들을 다 보지 않으므로, 한 달에 제일 예쁜 사진 1장(평균값)만 남기고 나머지는 다 지워버려(다운샘플링) 폰 용량을 아끼면서도 아기의 성장 과정(트렌드)은 충분히 기억할 수 있게 만드는 지혜입니다.

Ⅱ. 다운샘플링 (Downsampling) 메커니즘

해상도를 낮추면서 의미는 살려야 한다.

  1. 지속적 쿼리 (CQ, Continuous Queries):
    • InfluxDB 같은 시스템은 백그라운드에서 끊임없이 도는 매크로(CQ)를 켜둔다.
    • "매 1시간마다, 지난 1시간 동안 쌓인 '1초 단위' 데이터 3,600개를 가져와서, 평균(AVG), 최대(MAX), 최소(MIN) 값 3개로 압축 계산한 뒤 '1시간 단위 통계 테이블'에 저장하라."
  2. 연속적인 해상도 저하 (Tiered Resolution):
    • 시간이 지날수록 픽셀은 더 크게 뭉개진다.
    • 최근 7일 치: 1초 단위 원본 데이터 유지 (장애 디버깅 용도)
    • 1주 ~ 1달 치: 1분 단위 평균값으로 다운샘플링 유지
    • 1달 ~ 1년 치: 1시간 단위 평균값으로 다운샘플링 유지
    • 1년 이상: 하루 단위 평균값 1개로 극단적 압축
  3. 쿼리 최적화의 기적:
    • 분석가가 "작년 1년 치 온도 변화 그래프 그려줘"라고 할 때, TSDB가 1초 단위 데이터 수백억 건을 뒤져 평균을 내면 화면이 뜨는 데 1시간이 걸린다.
    • 하지만 이미 다운샘플링된 '하루 단위' 테이블(365건)을 읽어오면 그래프가 0.01초 만에 그려진다.

📢 섹션 요약 비유: cctv 녹화기를 돌릴 때, 오늘 찍힌 영상은 도둑을 잡아야 하니 4K 초고화질 60프레임(1초 단위 원본)으로 생생하게 저장합니다. 하지만 일주일이 지난 영상은 아무 일도 없었으니 용량을 아끼기 위해 흑백 1프레임(하루 단위 평균)으로 해상도를 확 낮춰서 압축 보관하는 것과 완벽히 같은 원리입니다.

Ⅲ. 보존 정책 (Retention Policy)과 자동 폐기

쓸모를 다한 데이터는 쥐도 새도 모르게 증발시켜야 한다.

  1. 자동화된 삭제의 필요성:
    • RDBMS에서 데이터를 지울 때 DELETE 쿼리를 날리면 트랜잭션 로그가 쌓이면서 디스크 I/O가 엄청나게 발생한다. 수백억 건의 만료된 시계열 데이터를 매일 DELETE 쿼리로 지우면 DB가 뻗어버린다.
  2. 보존 정책 (Retention Policy, RP) 적용:
    • TSDB는 데이터를 저장할 때 "이 데이터의 수명은 딱 30일이다"라는 보존 정책을 꼬리표처럼 달아서 블록(Chunk) 단위로 디스크에 모아둔다.
  3. 디스크 드롭 (Chunk Dropping):
    • 30일이 지나는 순간, TSDB는 DELETE 쿼리로 데이터를 하나하나 지우는 것이 아니라, 30일 치 데이터가 몽땅 들어있는 디스크 폴더(블록) 자체를 리눅스 파일 시스템에서 통째로 툭 떼어버린다(Unlink).
    • CPU나 디스크 I/O 오버헤드 0에 수렴하는 완벽하고 깔끔한 데이터 삭제가 이루어진다.

📢 섹션 요약 비유: 서류 파쇄기에 종이를 한 장씩 밀어 넣으며 윙윙 갈아버리는 것(DELETE 쿼리)은 너무 시끄럽고 힘듭니다. TSDB의 보존 정책은 아예 '유통기한 30일'이라고 적힌 커다란 골판지 박스에 서류를 모아두고, 기한이 지나면 박스째로 소각장에 휙 던져버려(Chunk Drop) 순식간에 창고 공간을 확보하는 매우 똑똑한 쓰레기 수거 시스템입니다.