3단계 — 테이블·인덱스·연결 풀을 조회 예산으로 설계하기

인덱스 개수나 pool size를 크게 만드는 것은 최적화가 아닙니다. 실제 조회 조건, 데이터 분포, 쓰기 비용, DB 연결 상한을 함께 보고 결정해야 합니다.

쿼리에서 거꾸로 설계

1. 목록·검색·상세 등 사용자의 경로와 필요한 컬럼을 적습니다.
2. EXPLAIN (ANALYZE, BUFFERS)로 대표 쿼리의 계획·읽기량·시간을 측정합니다.
3. 언어·종류·발행 여부처럼 반복되는 조건에는 partial/composite index를 검토합니다.
4. 배열·trigram 검색은 실제 연산자와 GIN 인덱스를 맞춥니다.
5. staging 데이터에서 전후 계획을 비교한 뒤 적용합니다.

Warragon에서는 Codingstairs 목록이 본문 전체가 아닌 PostSummary를 읽고, keywords 배열은 GIN이 이해하는 @> 조건을 사용합니다. 제목·설명·slug와 발행된 lesson 본문의 ILIKE '%term%'에는 pg_trgm GIN 인덱스를 두되, 기존 DB에는 Admin migration이 같은 정의를 멱등 보강합니다. DMDDKSL RAG는 processed = TRUE인 완료 파일만 노출하고 vector·HIRA join 축에 partial index를 둡니다. 준비 중인 검색 사본을 사용자 근거로 섞지 않는 것이 성능과 정확성 모두에 중요합니다.

연결 풀도 예산이다

Admin 5개 PostgreSQL pool, Python pool, Java Hikari, Next.js TypeORM이 같은 DB 자원을 나눕니다. 각 풀에 명시적 연결 대기 상한을 두되, 크롤러·백업처럼 오래 걸릴 수 있는 업무에 전역 query timeout을 무심코 걸지 않습니다. 최종 합산은 staging/운영 max_connections와 pooler 한도를 확인해야 합니다.

직접 해 보기

느린 화면 하나를 골라 “필요한 컬럼·조건·정렬·예상 행 수·실제 계획·변경 후 계획” 표를 작성합니다. 인덱스 추가 후 쓰기와 백업 시간도 함께 확인합니다.

연결 읽기

• 멱등 마이그레이션과 복구
• 완료 파일만 RAG 검색에 공개하기
• Codingstairs 검색과 pg_trgm
• 다음 단계