이력 테이블 vs 스냅샷 테이블 - 인덱서 DB 설계 전략

시리즈 목차

1. 블록체인 인덱서란?
2. 인덱서 아키텍처 Deep Dive
3. 이력 테이블 vs 스냅샷 테이블 (현재 글)
4. Rust로 인덱서 SDK 만들기
5. Diesel ORM 실전 활용
6. 멱등성 있는 인덱서 핸들러 설계

핵심 결론: 둘 다 필요하다

이력 테이블

• 모든 변경을 누적 저장
• 분석/감사/시점 재구성에 필수

스냅샷 테이블

• 현재 상태만 유지
• 사용자 조회 성능에 필수

이중 테이블 패턴

한 이벤트 처리 시:

1. 이력 테이블 INSERT
2. 스냅샷 테이블 UPSERT

스냅샷 UPSERT에는 버전 조건을 넣어 역전 업데이트를 막아야 합니다.

인덱스 전략 요약

• 이력: 시간, 주체 주소, 버전 인덱스
• 스냅샷: 현재 조회 키(소유자, 상태) 중심 인덱스

실무 팁

1. PK를 이벤트 식별자/버전 기반으로 고정
2. 스냅샷 갱신 시 WHERE last_version < incoming_version 적용
3. 대규모 집계는 이력 테이블, 사용자 조회는 스냅샷으로 분리

결론

인덱서 DB 설계의 목표는 정규화가 아니라 "질문 유형별 최적화"입니다.