515. 시계열 DB 보존 정책 (Retention) 데이터 라이프사이클

+++

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

본질: MVCC(Multi-Version Concurrency Control)는 데이터를 읽을 때 읽기 잠금 없이 해당 시점의 스냅샷을 제공하고, 쓰기는 새로운 버전을 생성하여 읽기-쓰기 충돌을 제거한다.

가치: 읽기 작업이 쓰기 작업을 차단하지 않아 동시성이 크게 향상되고, Non-Blocking Read가 가능하다.

융합: PostgreSQL, MySQL InnoDB, Oracle 등 주요 RDBMS에서 사용되며, 새타 기반 동시성 제어와 결합되어 활용된다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념

MVCC(Multi-Version Concurrency Control)는 각각의 트랜잭션에 데이터베이스의 특정 시점 뷰를 제공하는 동시성 제어 기법이다. 쓰기가 발생하면 기존 버전을 유지하면서 새 버전을 생성하고, 읽기는 지정된 시점의 버전을 보는 구조로, 읽기 잠금(Shared Lock) 없이 일관된 읽기가 가능하다.

필요성

Traditional한 2PL에서 읽기 작업은 Shared Lock을 획득해야 하므로, 쓰기 작업이 진행 중이면 읽기 작업이 대기해야 한다. 이로 인해 동시성이 크게 저하된다. MVCC는 이를 해결하여 읽기가 쓰기를 차단하지 않도록 한다.

비유

MVCC는 Google Docs의 版本管理와 같다. 다른 사람이 문서를 편집해도 내 화면에서는 내版本의 문서가 보여지고, 그 사람이 편집을 완료하면 나중에 변경 사항을 볼 수 있다.

섹션 요약 비유

MVCC는 동네 시절의 다중平行 세계와 같다. 여러 버전의 세계가 동시에存在하고, 각 사람은 자기 세계(시점)의 모습만 보며, versões 사이의 간섭은 없다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

MVCC 동작 구조

  ┌───────────────────────────────────────────────────────────────────────┐
  │                    MVCC 동작 구조                                        │
  ├───────────────────────────────────────────────────────────────────────┤
  │
  │   [데이터 구조]                                                        │
  │   ┌─────────────────────────────────────────────────────────────┐    │
  │   │  xid  │ field_a │ field_b │ CREATE_XID │ DELETE_XID │ version │    │
  │   │  (내부 트랜잭션 ID)                                            │    │
  │   └─────────────────────────────────────────────────────────────┘    │
  │
  │   [버전 체인]                                                         │
  │
  │   VERSION 3 (DELETE flag)                                           │
  │         │                                                            │
  │         │ pointer                                                     │
  │         ▼                                                            │
  │   VERSION 2 ───────────────────────────────────────────▶ [최신]      │
  │         │                                                            │
  │         │ pointer                                                     │
  │         ▼                                                            │
  │   VERSION 1 ───────────────────────────────────────────▶            │
  │         │                                                            │
  │         ▼                                                            │
  │      (원본)                                                          │
  │
  │   [읽기 시 고려사항]                                                  │
  │   • T1이 시작: T1.start_timestamp = 100                            │
  │   • VERSION 2: create_xid=95, delete_xid=110                        │
  │   • 100 > 95 (생성 이후) AND (110 > 100 이라면? 미삭제)               │
  │   • T1은 VERSION 2를 본다                                            │
  │
  └───────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] MVCC의 핵심은 각 행(row)에 메타데이터(XMIN: 생성 트랜잭션 ID, XMAX: 삭제 트랜잭션 ID)를 저장하고, 새로운 버전을 생성할 때 이전 버전에 포인터를 연결하는"버전 체인"이다. 읽기 시에는 트랜잭션의 시작 타임스탬프(start_timestamp)를 기준으로, 해당 시점 이후에 생성되고 아직 삭제되지 않은 버전을 찾는다. 이것이"스냅샷 읽기"의 원리다. 이렇게 하면 읽기는 절대 잠금을 기다릴 필요 없이 바로 스냅샷을 제공하고, 쓰기는 기존 버전을 덮어쓰지 않고 새 버전을 추가하므로 읽기-쓰기 충돌이 발생하지 않는다. 그러나 쓰기-쓰기 충돌(두 트랜잭션이 동시에 한 버전을 수정)은 여전히 2PL의 배타적 잠금으로 해결해야 한다.

MVCC 구현 방식

방식	설명	대표 DB
오래아기기 관리	유효한 버전만 유지, 오래된 버전은 periodically 정리	PostgreSQL
Append-Only	업데이트 시 새 행을 추가하고, 이전 행을标记	Cassandra
일시적 Deleted	삭제 시 행을标记, 나중에 제거	Oracle

섹션 요약 비유

MVCC의 版本 관리는 手紙のやり取り история와 같다. 각 편지(버전)을 keeping하고, 수신자가 특정 시점 이후의 편지만 읽으면(타임스탬프 기준) 상처往来가乱れることが 없다.

Ⅲ. 융합 비교 및 다각도 분석

비교: MVCC vs Traditional 2PL

구분	MVCC	Traditional 2PL
읽기	Non-blocking (스냅샷)	Blocking (S-Lock 필요)
쓰기	버전을 생성하므로 충돌少	배타적 잠금 사용
복잡도	높음	낮음
存储空间	버전 数 × overhead	단일 버전

과목 융합 관점

컴퓨터구조: MVCC의 버전 정리는 CPU 캐시의 라인 교체 정책(LRU, Clock)과 유사한 접근이다.
운영체제: MVCC의 스냅샷은 프로세스의 문맥 스위치에서의 상태 보존과 유사하다.

섹션 요약 비유

MVCC vs Traditional 2PL은 커피숍의 좌석 사용 방식과 같다. Traditional 2PL은 한 사람이 앉으면 다른 사람은 그 자리가 비기를까지 기다려야 하고, MVCC는 각 사람마다自分の席 النسخ)를 받는다.

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

실무 시나리오

시나리오 —的长업 무제한 스냅샷: 사용자가 복잡한 리포트를 생성하는 동안 다른 사용자가 동일한 테이블을 수정해도, 리포트 생성은 자신의 스냅샷에서 계속 수행되어影响받지 않는다. 이것이 MVCC의 가장 큰 장점으로, OLAP 쿼리와 OLTP 쿼리가 서로를 blocking하지 않는다.

도입 체크리스트

기술적: 版本 관리戦略(garbage collection)이 수립되어야 하며, 버전이 과도하게累积되면 성능이 저하된다.
운영·보안적: 스냅샷 격리가 READ COMMITTED 이상 수준을 제공하지만, "dirty read"는 방지하지 못하므로 트랜잭션 시작 시점을 주의 깊게 설정해야 한다.

안티패턴

버전 과다 누적: 업데이트가 빈번한 테이블에서 버전 정리(gc)가跟不上으면 버전 수가 폭발하여 스토리지가 증가하고 查询 성능이 저하된다.
잘못된 스냅샷: 트랜잭션이 너무 길면 시작 시점의 스냅샷이 너무 오래된 版本을 보게 되어, 다른 트랜잭션의 변경을 利用하지 못한다.

섹션 요약 비유

MVCC 버전 관리는 장기간 진행되는 프로젝트의 파일 버전 관리와 같다. 수백 개의 버전이 쌓이면储存空间가 부족해져서, 정기적으로古老的 버전는 정리해야 한다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	Traditional 2PL	MVCC 적용	개선 효과
읽기 대기 시간	수 ms ~ 수십 ms	0 ms	100%消除
동시 읽기 수	제한적	제한 없음	동시성大幅 향상
전체 처리량	중간	높음	수십 % 향상

미래 전망

SI (Snapshot Isolation)의 표준화: MVCC의 스냅샷 격리가 SQL 표준에 포함되어, 더 많은 DBMS가 MVCC를支持的趋向이다.
Distributed MVCC: CockroachDB, Spanner 등에서 분산 환경에서도 MVCC를 제공하려는 연구가 진행 중이다.

섹션 요약 비유

MVCC의 발전은 手紙からメールへの 변화와 같다. 편지를 기다리는 동안(잠금 대기) 아무것도 하지 못하는 것이 아니라, 바로 다른 일을 할 수 있게(Non-blocking) 되었다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
잠금 (Lock)	MVCC는 읽기 잠금을 제거하여 병렬성을 높이지만, 쓰기 잠금은 여전히 필요하다.
스냅샷 격리	MVCC의 구현 중 하나로, PostgreSQL에서 기본 격리 수준이다.
2PL	MVCC와 결합되어 사용되며, MVCC가 읽기를, 2PL이 쓰기를 담당한다.
PostgreSQL	MVCC의 대표적인 구현으로, 각 버전의 메타데이터로 XMIN, XMAX를 사용한다.
Garbage Collection	MVCC에서 불필요한 버전을 정리하는 메커니즘이다.

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

MVCC는 우리반 복사기 제도와 같아서, 누군가 시험지를 푸는 동안(쓰기) 다른 사람은 이전 복사본(스냅샷)을 보며 공부할 수 있어요.
각자 다른 시간에 찍은 사진(버전)을 보면서, 서로 방해하지 않고 각자의 속도로 공부할 수 있어요.
컴퓨터도 누군가 데이터를 고치는 동안(쓰기) 다른 사람이 이전 데이터(스냅샷)를 볼 수 있어서,大家가 동시에 일을 할 수 있어요!