같은 조회 성능 문제라도 먼저 SQL과 캐시를 보고, 그다음 DB가 관리할 수 있는 구조를 검토한 뒤, 마지막에 직접 반정규화를 선택하는 이유를 한눈에 정리한 순서입니다.
오른쪽 설명으로 갈수록 데이터 중복과 정합성 관리 책임이 커집니다. 읽기 속도만 보지 말고 쓰기 경로와 갱신 비용까지 함께 비교해야 합니다.
인덱스, 조인 순서, 실행 계획처럼 쿼리 자체를 먼저 고칩니다.
중복 데이터가 생기지 않아 부작용이 가장 적고, 이후 단계의 필요성도 여기서 다시 줄어드는 경우가 많습니다.
Redis, Memcached에 자주 읽는 값을 두어 DB 조회를 줄입니다. 예: 상품 목록의 카테고리명.
DB 스키마를 바꾸지 않고도 부하를 줄일 수 있어, 반정규화보다 운영 리스크가 작습니다.
자주 필요한 결과를 DB 내부에 미리 계산해 두고, 리프레시 정책으로 최신성을 맞춥니다.
애플리케이션이 중복 컬럼을 직접 맞추는 것보다 투명하고, 쿼리 최적화 포인트가 명확합니다.
중복 컬럼이나 요약 테이블을 만들어 원본 스키마 안에 조회용 데이터를 직접 넣습니다.
카테고리명 변경처럼 원본 값이 바뀔 때 여러 행을 함께 갱신해야 하므로, 갱신 이상과 운영 복잡도가 늘어납니다.
캐시도 일종의 반정규화이지만, 데이터 중복을 DB 밖에서 관리합니다. 그래서 반정규화가 필요해 보여도 먼저 캐시를 검토하라는 문맥이 자연스럽게 이어집니다.