DB performance at scale

Opendoor JD 명시 요건: “relational databases + reason about performance at scale.” 각 사다리 = 증상 → 왜 → EXPLAIN으로 보기 → boring 해법 → at-scale 해법 → 트레이드오프. 진짜 SQL/EXPLAIN과 함께, 단계마다 영어 한 줄.

🛠 손으로 직접: 레포의 infra/dblab — Opendoor 모양 스키마(3M offers, 인덱스 일부러 빠짐)를 Docker Postgres로 깔고 EXERCISES.md의 8개 훈련(EXPLAIN→인덱스→재측정, 락 경합 2세션, pgbench 은행 부하)을 노트북에서 돌려라. 실측: 복합 인덱스로 46ms→0.3ms.

EXPLAIN + indexes — why is this query slow?6 steps
10만 건일 땐 30ms였던 쿼리가 2,000만 건이 되니 4초가 걸린다. 추측하지 말고 EXPLAIN으로 직접 보고, 인덱스로 고치고, 그 대가까지 말할 수 있게 한 계단씩 올라간다.
N+1 queries — the hidden loop of round-trips6 steps
집 100채 목록 페이지가 600ms 걸립니다. 그런데 쿼리 하나하나는 0.4ms로 빠릅니다. 범인은 코드 속 숨은 반복문 — 목록 쿼리 1번 뒤에 집마다 1번씩, 총 1 + 100 = 101번 DB를 왕복하는 N+1 문제입니다. 증상 → 원인 → 눈으로 확인 → 기본 해결 → 대규모 해결 → 트레이드오프 순서로 올라갑니다.
Lock contention — writers blocking writers6 steps
쓰기가 쓰기를 막는 문제입니다. 100명이 같은 row를 동시에 UPDATE하면 Postgres는 한 명씩 줄을 세웁니다. 첫 트랜잭션이 COMMIT할 때까지 나머지 99명은 그냥 기다립니다. CPU는 한가한데 응답만 느려지는, "바쁜 게 아니라 기다리는" 문제입니다. 증상 → 원인 → 보는 법 → 기본 수정 → 스케일 수정 → 트레이드오프 순서로 올라갑니다.
Pagination at scale — OFFSET dies, keyset lives6 steps
매물(listings) 테이블 1,000만 행. 같은 목록 쿼리인데 1페이지는 5ms, 5,000페이지는 2초가 걸린다. 증상 → 원인 → 눈으로 확인(EXPLAIN) → 당장 막는 법 → 스케일에서 사는 법(keyset) → 그 대가, 이 순서로 올라간다.
Hot rows + partitioning — when one row/table melts7 steps
쿼리 자체는 멀쩡한데 DB가 느려질 때가 있다. 범인은 보통 둘 중 하나다: 모두가 같은 행 하나를 두드리거나(hot row), 테이블 하나가 너무 커졌거나. 초당 3,000번 UPDATE 맞는 조회수 행에서 시작해서 5억 행 이벤트 테이블까지 — 증상 → 원인 → 눈으로 확인 → 지루한 해결 → 스케일 해결 → 비용 순서로 올라간다.
Connection pooling — why the DB ran out of connections6 steps
월요일 아침 배포 직후, 모든 API가 500을 뱉기 시작한다. 로그에는 "sorry, too many clients already" 한 줄. Postgres 기본 연결 한도는 100개인데, 앱 서버 10대가 각자 20개씩 연결을 열려고 했다. 이 사다리는 그 사고를 숫자 그대로 따라간다: 증상 → 원인 → 눈으로 확인 → 당장 고치기 → 규모에서 고치기 → 그 대가.
Serialization failures (40001) + retry6 steps
SERIALIZABLE(또는 REPEATABLE READ)에서 동시에 도는 두 트랜잭션이 직렬화 순서를 깰 것 같으면, Postgres는 둘 중 하나를 SQLSTATE 40001(serialization_failure)로 그냥 죽인다 — 데드락은 40P01. 이건 버그가 아니라 DB가 정합성을 지키는 정상 동작이다. 핵심은 앱이 40001을 잡아서 트랜잭션을 통째로 재시도해야 한다는 것, 그리고 재시도해도 안전하도록 트랜잭션이 멱등(idempotent)해야 한다는 것이다. 증상 → 원인(MVCC write-skew) → 눈으로 확인 → 재시도 루프 → 멱등성 → SERIALIZABLE vs 낙관적 버전 트레이드오프 순서로 올라간다.
VACUUM, autovacuum, dead tuples, bloat, VACUUM FULL vs pg_repack7 steps
아무도 DELETE를 많이 안 했는데 테이블·인덱스가 계속 커지고, 인덱스가 멀쩡한데도 쿼리가 점점 느려진다. 원인은 Postgres의 MVCC다 — UPDATE/DELETE는 행을 그 자리에서 안 고치고 옛 버전을 죽은 튜플(dead tuple)로 남긴다. 죽은 튜플이 안 치워지면 디스크가 부풀고(bloat), VACUUM이 따라잡지 못하면 트랜잭션 ID 소진(wraparound)까지 간다. 증상 → 원인(MVCC) → 눈으로 확인 → autovacuum 튜닝(지루한 정답) → 스케일 처방(파티셔닝/HOT) → bloat 회수(VACUUM FULL vs pg_repack) 순서로 올라간다.
Index types beyond B-tree: BRIN, GIN, partial, expression indexes7 steps
B-tree는 기본값일 뿐, 만능이 아니다. 시계열처럼 자연 정렬된 거대 테이블엔 BRIN이 B-tree보다 1000배 작고, JSONB·배열·전문검색엔 GIN, '활성 행만'이나 '소문자 이메일'처럼 조건·표현식 위에 거는 쿼리엔 partial/expression 인덱스가 맞는 도구다. 핵심은 '쿼리가 무엇을 묻는가'에 인덱스 종류를 맞추는 것 — 증상 → 왜 B-tree로 부족한가 → EXPLAIN으로 확인 → 맞는 인덱스 처방 → 스케일 처방 → 그 대가 순서로 올라간다.