정규화된 테이블 구조를 의도적으로 되돌려 조회 성능을 개선하는 기법. 데이터 중복을 감수하고 JOIN을 줄이거나 집계 연산을 미리 계산해두는 방식이다.
정규화는 데이터 무결성과 저장 공간 효율을 위한 것이다. 하지만 정규화가 높을수록 조회 시 여러 테이블을 JOIN해야 한다. 데이터가 많아지면 이 JOIN 비용이 성능 병목이 된다.
정규화 우선: 쓰기 성능 좋음, 읽기 성능 나쁠 수 있음
역정규화: 읽기 성능 좋음, 쓰기 복잡도 증가 + 데이터 중복
역정규화는 "읽기가 쓰기보다 훨씬 많은" 상황에서 고려한다.
자주 함께 조회되는 두 테이블을 하나로 합친다.
-- before: 매번 JOIN 필요
SELECT u.name, p.bio FROM users u JOIN profiles p ON u.id = p.user_id;
-- after: 단일 테이블 조회
SELECT name, bio FROM users;
-- users 테이블에 bio 컬럼 추가
단점: users 테이블에 nullable 컬럼이 늘어난다.
자주 쓰는 컬럼과 드물게 쓰는 컬럼을 분리한다.
users → users(기본 정보) + user_details(부가 정보)매번 집계 연산하는 값을 컬럼으로 저장한다.
-- before: 주문 수를 매번 COUNT
SELECT u.id, COUNT(o.id) as order_count
FROM users u LEFT JOIN orders o ON u.id = o.user_id
GROUP BY u.id;
-- after: users 테이블에 order_count 컬럼 추가
-- 주문 생성/삭제 시 order_count 업데이트
UPDATE users SET order_count = order_count + 1 WHERE id = ?;
장점: 사용자 목록 조회 시 JOIN 없이 집계값 바로 반환 단점: 쓰기 시 두 곳 업데이트 필요, 동기화 오류 위험
Redis 같은 캐시를 도입하기 전에, 집계값을 DB에 미리 계산해두는 방식으로 먼저 해결하는 경우가 있다. 좋아요 수, 댓글 수, 팔로워 수 등이 대표적이다.
-- posts 테이블에 like_count 컬럼 유지
-- like 이벤트 발생 시 atomic하게 업데이트
UPDATE posts SET like_count = like_count + 1 WHERE id = ?;
OpenSearch나 Elasticsearch에 문서를 색인할 때, RDB의 여러 테이블에 흩어진 데이터를 하나의 문서로 합쳐서 저장한다. 이것도 역정규화의 일종이다.
{
"doc_id": "123",
"title": "...",
"author_name": "김철수", // users 테이블에서 가져온 값
"project_name": "프로젝트A", // projects 테이블에서 가져온 값
"content": "..."
}
Command(쓰기)와 Query(읽기) 모델을 분리하는 CQRS에서, 읽기 전용 모델은 역정규화된 형태로 관리한다. 쓰기는 정규화된 DB에, 읽기는 역정규화된 Read Model(RDB 또는 검색엔진)을 사용한다.
역정규화는 데이터 정합성 관리 비용을 증가시킨다. 원본 데이터가 바뀔 때 역정규화된 컬럼도 함께 업데이트해야 한다. 트랜잭션으로 묶지 않으면 불일치가 발생한다.