S(*). Architect

이 글의 목적데이터베이스 따라잡기 본편 24편을 마쳤다. 이 글은 시리즈 전체를 압축·연결하고 다음에 어디로 갈지 짚는 에필로그다.24편 동안 본 개념을 한 장 지도로 다시 본다DB에서 뻗어 나가는 주제와 블로그 내 다른 시리즈를 연결한다DB 지식이 어떤 직업·역할과 맞닿는지 정리한다손으로 확인하는 방법과 읽을거리를 남긴다1. 24편이 만든 큰 그림데이터베이스는 한 쿼리가 아니라 저장·인덱스·트랜잭션·복제·운영이 겹친 시스템이다.Part핵심 질문기억할 키워드0~1 관계형 기초데이터를 어떻게 모델링하고 질의하나릴레이션, SQL, 정규화, 쿼리 처리 파이프라인2 저장·인덱스디스크에서 어떻게 빨리 찾나페이지, B+ Tree, EXPLAIN, ACID3 동시성·복구동시에 쓰면 뭐가 깨지고 어떻게 복구하나격리 수..

학습 목표Debezium 커넥터 토폴로지(Connect worker·slot·topic·SMT)를 설명할 수 있다.Schema registry와 스키마 진화(backward/forward compatibility)를 설계할 수 있다.ordering·exactly-once 보장 범위와 한계를 DB·sink 관점에서 구분할 수 있다.DLQ·재처리·slot lag 복구 런북을 작성할 수 있다.snapshot·incremental 전환·DDL 장애를 운영할 수 있다.문제 상황ALTER TABLE products ADD COLUMN — Debezium Avro deserialize 실패 · consumer 전부 stopconnector 재시작 — offset earliest 실수 — 과거 6개월 replay · ..

학습 목표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..

학습 목표슬로우 쿼리가 CPU·I/O·lock·네트워크 중 어디서 시간을 쓰는지 구분할 수 있다.slow query log·pg_stat_statements로 빈도·총 시간 기준 후보를 찾을 수 있다.pg_stat_activity·lock wait로 대기·blocking 세션을 진단할 수 있다.EXPLAIN ANALYZE로 실행 계획 편의 플랜·추정 오차를 검증할 수 있다.영향도·수정 비용 기준 튜닝 우선순위를 정할 수 있다.문제 상황API p99 2.4s — 앱 프로파일은 얕음 · DB CPU 85%SELECT * FROM orders 수천 번 — ORM N+1 (pool·ORM 편)pg_stat_statements 없음 — 어느 SQL이 느린지 모름EXPLAIN만 보고 인덱스 추가 — actual t..

학습 목표Dual write가 DB COMMIT과 메시지 publish 불일치를 만드는 이유를 설명할 수 있다.Transactional outbox로 로컬 TX 안에 비즈니스 row·이벤트 row를 함께 COMMIT하는 이유를 설명할 수 있다.CDC가 WAL/binlog logical 스트림에서 row change를 캡처함을 설명할 수 있다.Debezium connector·envelope·slot 개념을 개요 수준에서 설명할 수 있다.At-least-once 전달에서 순서·중복·멱등 처리를 설계할 수 있다.문제 상황INSERT orders COMMIT 후 Kafka publish timeout — DB 있음 · 재고 미반영publish 성공 → DB ROLLBACK — 유령 이벤트캐시 DEL 앱 코드 ..

학습 목표애플리케이션 캐시가 DB read 부하·connection·버퍼 풀 압력을 어떻게 줄이는지 설명할 수 있다.Cache-aside·read-through·write-through 의 DB I/O·일관성 차이를 비교할 수 있다.TTL·invalidation으로 stale read 창을 통제할 수 있다.Cache stampede가 DB spike를 만드는 메커니즘과 완화를 설명할 수 있다.DB = source of truth, 캐시 = 파생 — 복제 lag·캐시 중첩 stale을 설명할 수 있다.문제 상황상품 상세 API — PostgreSQL 동일 SELECT 매 요청 · p99 380msRedis TTL 5분 — 가격 UPDATE 후 4분 구 가격 노출캐시 무효화 없이 DB만 수정 — 영구 sta..

학습 목표Connection pool이 TCP·인증 비용을 줄이고 동시 요청을 제한하는 이유를 설명할 수 있다.Pool 고갈(exhaustion)·connection leak·timeout 증상과 대응을 설명할 수 있다.ORM이 SQL 생성·객체 매핑·1차 캐시(session) 를 담당함을 설명할 수 있다.N+1 쿼리가 어디서 생기는지 탐지하고 JOIN·fetch·batch 로 줄일 수 있다.지연 로딩 vs 즉시 로딩·배치 fetch·bulk insert 트레이드오프를 설명할 수 있다.문제 상황API 100 RPS — PostgreSQL max_connections=100 포화 · 새 연결 거부요청마다 DriverManager.getConnection() — TCP+SSL+auth 수 msHikariCP..

학습 목표NoSQL 네 가지 데이터 모델(KV·문서·와이드컬럼·그래프)과 대표 제품을 구분할 수 있다.스키마 유연성과 정규화·JOIN 트레이드오프를 access pattern 기준으로 설명할 수 있다.CAP에서 분할(partition) 시 일관성 vs 가용성 선택을 설명할 수 있다.워크로드(lookup·range·관계 탐색·ad-hoc 집계)별 적합한 모델을 고를 수 있다.RDB와 NoSQL이 공존하는 이유 — polyglot persistence — 를 설명할 수 있다.문제 상황상품 속성이 매주 바뀌는데 ALTER TABLE 배포가 월 1회 — 스키마 병목피드 쓰기 TPS 8만 — 단일 PostgreSQL WAL·connection 한계 (샤딩 비용 큼)MongoDB에 주문·결제 원장 — 다중 문서 T..

학습 목표분산 트랜잭션이 여러 DB·서비스에 걸친 원자성 문제를 만든다는 것을 설명할 수 있다.2PC(Two-Phase Commit) 의 prepare·commit 단계와 블로킹·조정자 SPOF 한계를 설명할 수 있다.3PC가 2PC를 개선하려다 복잡도만 늘리는 이유를 설명할 수 있다.Saga(오케스트레이션·코레오그래피)와 보상 트랜잭션으로 ** eventual consistency**를 설계할 수 있다.Transactional outbox로 DB COMMIT과 이벤트 발행을 한 로컬 TX에 묶는 이유를 설명할 수 있다.문제 상황주문 DB COMMIT 후 결제 API 타임아웃 — 주문만 생성됨두 시스템 하나의 ROLLBACK 불가샤드 A·B에 한 번에 INSERT — cross-shard ACID 기대P..