S(*). Architect

학습 목표partition pruning이 실제 쿼리에서 동작하는지 EXPLAIN으로 검증할 수 있다.DETACH·ATTACH·DROP으로 아카이브·복구 절차를 설계할 수 있다.파티션별 크기·통계·vacuum 상태를 모니터링할 수 있다.핫 파티션(latest range·skew) 증상과 완화 전략을 선택할 수 있다.파티션 추가·DEFAULT·constraint exclusion 운영 함정을 피할 수 있다.문제 상황orders RANGE 파티션 24개 — WHERE created_at > now()-7d 인데 전 파티션 scanEXPLAIN Append child 24개2023년 데이터 삭제 — DELETE 3시간 · WAL 폭주 · vacuum 밀림아카이브 팀 — orders_2023_01 통째 S3 이..

학습 목표dead tuple·bloat가 MVCC UPDATE/DELETE 후 성능에 미치는 이유를 설명할 수 있다.autovacuum 트리거·모니터링·장시간 TX 차단을 설명할 수 있다.VACUUM vs VACUUM FULL·ANALYZE 역할과 트레이드오프를 설명할 수 있다.transaction id freeze·wraparound 위험을 설명할 수 있다.InnoDB purge가 undo 정리에 대응함을 개요 수준에서 설명할 수 있다.문제 상황orders UPDATE 대량 후 테이블 크기 동일 · Seq Scan 2배 느림n_dead_tup 40% — autovacuum 안 돔장시간 idle in transaction 하나 — 전 테이블 vacuum 정지VACUUM FULL 피크 실행 — 30분 ex..

학습 목표MVCC(Multi-Version Concurrency Control) 가 읽기·쓰기를 어떻게 분리하는지 설명할 수 있다.스냅샷·버전 체인·가시성(visibility) 규칙을 설명할 수 있다.PostgreSQL VACUUM과 InnoDB purge가 dead tuple·undo를 정리하는 이유를 설명할 수 있다.PostgreSQL·InnoDB MVCC 구현 차이와 격리 수준 동작을 비교할 수 있다.문제 상황SELECT가 많은 서비스에서 읽기마다 락을 걸면 쓰기가 막힌다2PL만 쓰면 읽기·쓰기 상호 블로킹Repeatable Read인데 PostgreSQL과 MySQL 동작이 다르다같은 이름, 다른 스냅샷 규칙UPDATE·DELETE 후 테이블 크기는 그대로인데 느려진다dead tuple·bloat..