반정규화

성능 문제 발생
      │
      ▼
┌──────────────────────────┐
│ 1. 문제 원인 분석        │
│    실행 계획 확인        │
│    → 인덱스 문제인가?    │
│    → 조인 비용 문제인가? │
│    → 집계 비용 문제인가? │
└─────────┬────────────────┘
          │
          ▼
┌───────────────────────────┐
│ 2. 인덱스로 해결 시도     │ ← 우선 시도
│    Covering Index 검토    │
│    Materialized View 검토 │
└─────────┬─────────────────┘
          │ 해결 안 됨
          ▼
┌─────────────────────────┐
│ 3. 반정규화 유형 결정   │
│    테이블 병합?         │
│    중복 컬럼 추가?      │
│    요약 테이블?         │
│    파생 컬럼?           │
└─────────┬───────────────┘
          │
          ▼
┌─────────────────────────┐
│ 4. 데이터 정합성 전략   │
│    동기 갱신? 비동기?   │
│    트리거? 배치?        │
│    허용 가능한 지연?    │
└─────────┬───────────────┘
          │
          ▼
┌─────────────────────────┐
│ 5. 적용 및 모니터링     │
│    성능 개선 측정       │
│    갱신 비용 측정       │
│    정합성 검증          │
└─────────────────────────┘

정규화
  users (id, name, email)
  user_profiles (user_id, bio, avatar_url, website)
  → 사용자 정보 조회 시 항상 JOIN 필요

반정규화
  users (
    id, name, email,
    bio, avatar_url, website  ← 프로필 컬럼 병합
  )
  → JOIN 제거, 단일 테이블 조회

정규화
  orders (id, user_id, order_date)
  order_details (id, order_id, product_id, qty, price)

주의: 1:N 병합은 데이터 중복 발생!
  orders_merged (
    id, user_id, order_date,
    product_id, qty, price
  )
  → order_date가 주문 상품 수만큼 중복 저장

적용 조건
  * N쪽 데이터가 적을 때 (예: 주문당 상품 1~3개)
  * 항상 함께 조회되는 경우
  * 주의: 갱신 이상 위험 증가

정규화 (테이블 3개)
  Payment (id, amount, type)
  CardPayment (payment_id, card_number, installment)
  BankPayment (payment_id, bank_code, account)

전략 1: 단일 테이블 전략 (모든 컬럼 합침)
  Payment (
    id, amount, type,
    card_number, installment,  ← type='CARD'일 때만 사용
    bank_code, account         ← type='BANK'일 때만 사용
  )
  장점: JOIN 없음, 쿼리 단순
  단점: NULL 컬럼 많음, 공간 낭비

전략 2: 각 타입별 테이블 전략 (완전 분리)
  CardPayment (id, amount, card_number, installment)
  BankPayment (id, amount, bank_code, account)
  장점: NULL 없음, 각 타입 최적화
  단점: 전체 결제 조회 시 UNION 필요

전략 3: 조인 전략 (정규화 유지)
  Payment (id, amount, type) → 공통
  CardPayment (payment_id, card_number, installment) → 개별
  장점: 정규화 유지, 확장 용이
  단점: JOIN 필요

정규화
  orders (id, user_id, ...)
  → users.name은 조인 필요

반정규화
  orders (id, user_id, user_name, ...)
  └→ user_name은 users.name의 복사본
  └→ 조인 없이 주문 목록에서 이름 조회 가능

┌──────────────────┬──────────────────────┬──────────────────┐
│       유형       │         예시         │ 갱신 주기        │
├──────────────────┼──────────────────────┼──────────────────┤
│ 일별 요약        │ daily_sales_summary  │ 매일 새벽 배치   │
│ 월별 요약        │ monthly_report       │ 매월 1일         │
│ 카테고리별 집계  │ category_stats       │ 실시간 또는 1시간│
│ 사용자별 통계    │ user_activity_stats  │ 실시간 또는 일별 │
│ 실시간 카운터    │ product_view_count   │ 즉시 (트리거)    │
│ 순위 테이블      │ product_ranking      │ 1시간 또는 일별  │
└──────────────────┴──────────────────────┴──────────────────┘

갱신 전략
* 전체 재계산: 단순하지만 데이터 많으면 느림
* 증분 갱신: 변경분만 반영 (MERGE/Upsert)
* 실시간 갱신: 트리거 또는 애플리케이션에서 즉시 반영
* CDC 기반: 변경 데이터 캡처로 비동기 갱신

1. 주문 합계
   orders.total_amount = SUM(order_items.price * qty)

2. 게시글 댓글 수
   posts.comment_count = COUNT(comments)
   → 댓글 INSERT/DELETE 시 +1/-1 갱신

3. 사용자 주문 횟수
   users.order_count = COUNT(orders)
   → 등급 판단에 활용

4. 상품 평균 별점
   products.avg_rating = AVG(reviews.rating)
   → 리뷰 등록/삭제 시 재계산

5. 나이 (생년월일에서 파생)
   users.age = EXTRACT(YEAR FROM SYSDATE)
               - EXTRACT(YEAR FROM birth_date)
   주의: 매년 갱신 필요 → Virtual Column이 더 적합

원래 테이블
  users (id, name, email, password_hash,
         bio, avatar_url, settings_json, login_history)
  → 모든 컬럼이 한 행에 → row 크기가 큼
  → 목록 조회에서 불필요한 BLOB/CLOB도 함께 로드

수직 분할
  users (id, name, email, password_hash)
  user_profiles (user_id, bio, avatar_url)
  user_settings (user_id, settings_json)
  
  장점
  * 자주 조회되는 컬럼만 캐시에 유지
  * I/O 감소 (필요한 컬럼만 읽기)
  * LOB 컬럼 분리로 성능 향상

원래 테이블
  orders (id, user_id, order_date, total, status)
  → 5년치 주문 1억 건 → 전체 스캔 시 매우 느림

수평 분할 (파티셔닝)
  orders_2020 (... WHERE order_date BETWEEN ...)
  orders_2021 (...)
  orders_2022 (...)
  orders_2023 (...)
  orders_2024 (...)

  또는 DBMS 파티셔닝 기능
  PARTITION BY RANGE (order_date) (
    PARTITION p2022 VALUES LESS THAN (DATE '2023-01-01'),
    PARTITION p2023 VALUES LESS THAN (DATE '2024-01-01'),
    PARTITION p2024 VALUES LESS THAN (DATE '2025-01-01')
  )
  
  장점
  * Partition Pruning → 특정 연도만 스캔
  * 파티션 단위 백업/삭제 가능
  * 병렬 쿼리 가능

┌──────────────┬──────────────────────┬────────────────────────┐
│ 리프레시 방식│         설명         │ 적합한 경우            │
├──────────────┼──────────────────────┼────────────────────────┤
│ COMPLETE     │ 전체 재생성          │데이터 적음, 복잡한 쿼리│
│     FAST     │ 변경분만 반영        │ MV 로그 필요, 빠름     │
│ FORCE        │ FAST 시도 → 실패 시  │ 일반적 권장            │
│              │ COMPLETE             │                        │
├──────────────┼──────────────────────┼────────────────────────┤
│ ON COMMIT    │ 원본 커밋 시 자동    │ 실시간 정합성 필요     │
│ ON DEMAND    │ 수동/스케줄 리프레시 │ 배치 작업에 적합       │
└──────────────┴──────────────────────┴────────────────────────┘

FAST 리프레시를 위한 MV 로그:
CREATE MATERIALIZED VIEW LOG ON orders
  WITH ROWID, SEQUENCE (order_date, total)
  INCLUDING NEW VALUES;

┌──────────────────┬──────────────────┬──────────────────┐
│                  │ Materialized View│ 요약 테이블      │
├──────────────────┼──────────────────┼──────────────────┤
│ 갱신 관리        │ DBMS 자동        │수동 (배치/트리거)│
│ 쿼리 투명성      │ Query Rewrite    │ 직접 참조 필요   │
│      정합성      │리프레시 방식 의존│ 구현에 의존      │
│      유연성      │ SQL로 정의       │     자유로움     │
│      디버깅      │ DBMS에 위임      │ 직접 확인        │
│ 멀티 DBMS        │ Oracle/PostgreSQL│ 모든 DBMS        │
│ MySQL 지원       │      미지원      │ 요약 테이블 사용 │
└──────────────────┴──────────────────┴──────────────────┘

┌──────────────────────────────────────────────────────┐
│               성능 개선 우선순위                     │
├──────────────────────────────────────────────────────┤
│                                                      │
│  1순위: SQL 최적화 (인덱스, 실행 계획 개선)          │
│         → 가장 기본적, 부작용 없음                   │
│                                                      │
│  2순위: 애플리케이션 캐시 (Redis, Memcached)         │
│         → DB 부하 감소, 정합성은 TTL로 관리          │
│                                                      │
│  3순위: Materialized View                            │
│         → DBMS가 관리, 투명한 쿼리 최적화            │
│                                                      │
│  4순위: DB 반정규화 (중복 컬럼, 요약 테이블)         │
│         → 마지막 수단, 갱신 이상 주의                │
│                                                      │
└──────────────────────────────────────────────────────┘

시나리오: 상품 목록에 카테고리명 표시

방법 A: DB 반정규화
  products 테이블에 category_name 컬럼 추가
  → 카테고리명 변경 시 모든 상품 UPDATE 필요

방법 B: Redis 캐시
  // 카테고리 정보를 Redis에 캐시
  redis.set('category:1', { name: '전자제품' });
  redis.set('category:2', { name: '의류' });

  // 상품 조회 시 캐시에서 카테고리명 조합
  const product = await db.query('SELECT * FROM products');
  const category = await redis.get(`category:${product.category_id}`);

  장점: DB 정규화 유지, 캐시 무효화가 UPDATE보다 간단
  한계: 캐시 서버 장애 시 대비 필요

RDB (정규화)
  users { id, name }
  orders { id, user_id, date }
  order_items { id, order_id, product_id, qty }
  products { id, name, price }
  → 4개 테이블, JOIN으로 조합

MongoDB (반정규화 = 임베딩)
  orders {
    _id: ObjectId,
    user: { name: "홍길동" },          ← 중복 저장
    date: ISODate,
    items: [
      { product: "노트북",             ← 중복 저장
        price: 1500000, qty: 1 },
      { product: "마우스",
        price: 35000, qty: 2 }
    ],
    total: 1570000                     ← 파생 컬럼
  }
  → 단일 문서로 모든 정보 포함
  → JOIN 불필요, 읽기 매우 빠름
  → 상품 이름/가격 변경 시 주문에는 주문 시점 값 유지

┌──────────────────┬──────────────────┬──────────────────┐
│                  │       OLTP       │ OLAP (DW)        │
├──────────────────┼──────────────────┼──────────────────┤
│       목적       │ 트랜잭션 처리    │ 분석/리포트      │
│ 정규화 수준      │ 3NF (정규화)     │ 스타 스키마      │
│                  │                  │ (반정규화)       │
│ 조인 빈도        │       보통       │ Dimension JOIN   │
│ 읽기/쓰기        │ 50:50 ~ 80:20    │       99:1       │
│ 쿼리 패턴        │ 단일 행 CRUD     │ 대량 집계/스캔   │
│      무결성      │      최우선      │ 일부 허용        │
│      인덱스      │      선별적      │ 비트맵/컬럼나    │
│     실시간성     │      실시간      │ 배치/준실시간    │
└──────────────────┴──────────────────┴──────────────────┘

스타 스키마 (OLAP 반정규화 설계)
            dim_product
                │
dim_date ── fact_sales ── dim_customer
                │
            dim_store

* Fact 테이블: 측정값 (매출, 수량 등)
* Dimension 테이블: 분석 축 (시간, 상품, 고객 등)
* Dimension은 반정규화 (조인 최소화)

1. 갱신 이상 (Update Anomaly)
   → 중복 데이터 불일치 위험
   → 대응: 트리거, 배치 동기화, CDC

2. 삽입 이상 (Insert Anomaly)
   → 불필요한 데이터도 함께 입력해야 함
   → 대응: NULL 허용 또는 기본값 설정

3. 삭제 이상 (Delete Anomaly)
   → 연관 데이터 의도치 않은 삭제
   → 대응: 소프트 삭제, 히스토리 테이블

4. 저장 공간 증가
   → 중복 데이터만큼 공간 사용
   → 대응: 비용-효과 분석 (디스크 vs 성능)

5. 애플리케이션 복잡도
   → 동기화 로직 추가 필요
   → 대응: 문서화, 테스트 코드 작성

┌─────────────────────────────────────────────────────────┐
│              반정규화의 5가지 원칙                      │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  1. 정규화가 먼저다                                     │
│     → 3NF까지 정규화 → 성능 문제 확인 → 반정규화 검토   │
│                                                         │
│  2. 측정 없이 반정규화하지 않는다                       │
│     → 실행 계획과 성능 지표로 병목 확인 후 적용         │
│                                                         │
│  3. 최소 범위로 적용한다                                │
│     → 문제가 되는 쿼리/테이블만 대상으로                │
│     → 전체 스키마를 반정규화하는 것은 위험              │
│                                                         │
│  4. 정합성 전략을 반드시 수립한다                       │
│     → 중복 데이터의 동기화 방법 명확히 정의             │
│     → 동기화 실패 시 대응 방안 포함                     │
│                                                         │
│  5. 문서화한다                                          │
│     → 왜 반정규화했는지, 어떤 트레이드오프인지 기록     │
│     → 향후 유지보수/리팩토링의 근거 자료                │
│                                                         │
└─────────────────────────────────────────────────────────┘