📘

3단계: 데이터베이스 & 데이터 시스템

인덱스/트랜잭션/락/캐시/메시징으로 데이터 시스템의 성능·정합성·확장성을 다지는 모듈

타임라인 Learning 메인
모듈형 학습 자동 정렬

🧠 모듈 개요

이 단계에서 얻는 것

이 단계는 “스프링을 안다”에서 한 단계 더 나아가, 데이터/정합성/성능을 근거 있게 다룰 수 있게 만드는 구간입니다.

  • DB 성능 감각: 인덱스/실행 계획을 보고 “왜 느린지”를 추적하고, 튜닝 방향을 세울 수 있습니다.
  • 정합성 감각: 트랜잭션/격리 수준/락/데드락을 이해해서 “깨지지 않는” 설계를 할 수 있습니다.
  • 캐시/메시징 감각: Redis 캐시 패턴, Kafka/Outbox 같은 비동기 설계를 “언제/왜” 쓰는지 연결할 수 있습니다.
  • 데이터 관측/운영 감각: “느린 쿼리/락 대기/캐시 미스/컨슈머 지연” 같은 신호를 지표/로그로 연결합니다.

이 모듈을 보는 방법

이 페이지 아래에 연결된 글이 순서대로 정렬됩니다.

  1. 인덱스/실행 계획으로 “느림”을 해부하고
  2. 트랜잭션/락으로 “정합성”을 확보하고
  3. 캐시/메시징으로 “확장/운영”을 설계하는 흐름으로 읽으면 좋습니다.

각 글의 연습은 “완성 프로젝트”가 목표가 아니라, 작은 재현/관찰로 감각을 만드는 것이 목표입니다.

왜 이런 순서인가

데이터 관련 문제는 결국 다음 순서로 좁혀집니다.

  • 쿼리가 느리다 → 실행 계획/인덱스/풀/락 대기 중 어디가 원인인지 분해
  • 정합성이 깨진다 → 트랜잭션 경계/격리 수준/동시성 제어를 재설계
  • 트래픽이 커진다 → 캐시/비동기/샤딩 같은 확장 전략을 선택

그래서 “인덱스/EXPLAIN → 트랜잭션/락 → 캐시/메시징 → 설계 문제” 순서를 기본으로 둡니다.

이 단계의 핵심 주제

  • 인덱스/실행 계획/쿼리 튜닝
  • 트랜잭션/격리 수준/락/데드락
  • 캐시 전략(Cache-Aside/Write-Through/Stampede)
  • 메시징/이벤트 기반 설계(Kafka, Outbox)
  • 데이터 관측(슬로우 쿼리/락 대기/컨슈머 지연)

미니 실습

  • EXPLAIN 읽기: 느린 쿼리를 만들고 실행 계획으로 병목 찾기
  • 락/데드락 재현: 트랜잭션 두 개로 락 대기 상황 만들기
  • 캐시 스탬피드 방지: TTL 지터 또는 락으로 붐 방지 실험

완료 기준 (다음 단계로 넘어가기 전)

  • EXPLAIN을 보고 ALL/filesort/temporary 같은 위험 신호를 읽고, 인덱스/쿼리 개선 방향을 말로 설명할 수 있다
  • 격리 수준/락 때문에 생기는 현상(데드락/락 대기)을 로그/지표로 구분할 수 있다
  • 캐시를 “붙여서 빨라졌다”가 아니라, 키/TTL/무효화/스탬피드까지 포함해 설계할 수 있다

📑 이 모듈의 학습 노트

Redis

Redis 캐시 패턴 모음

Cache-Aside, Write-Through, Write-Behind, 분산락 패턴을 코드 예시와 함께 정리

Redis Cache Aside Write Through
Database Internals

스토리지 엔진 내부: B-Tree vs LSM-Tree

DB 성능의 핵심인 스토리지 엔진. MySQL의 B-Tree와 Cassandra/RocksDB의 LSM-Tree 구조를 비교하고 장단점을 파헤칩니다.

Database B-Tree LSM-Tree