대용량 테이블 분할 전략 — 파티셔닝과 샤딩의 차이와 선택 기준

데이터가 수천만 건을 넘어가면 단일 테이블 구조는 점점 한계에 부딪힌다.
인덱스 크기가 커지고, 백업·복구 시간이 길어지며, 특정 쿼리의 응답 속도가 급격히 저하된다.

이 시점에서 고려하는 전략이 파티셔닝(Partitioning)과 샤딩(Sharding)이다.
두 방법은 목적과 적용 범위가 다르므로 혼용해서 이해하면 안 된다.

1. 파티셔닝(Partitioning)

파티셔닝은 하나의 테이블을 내부적으로 여러 파티션으로 나누는 방식이다.
물리적으로는 분리되지만 논리적으로는 하나의 테이블처럼 동작한다.

CREATE TABLE log_data (
    id BIGINT NOT NULL,
    created_at DATETIME NOT NULL,
    message TEXT,
    PRIMARY KEY (id, created_at)
)
PARTITION BY RANGE (YEAR(created_at)) (
    PARTITION p2023 VALUES LESS THAN (2024),
    PARTITION p2024 VALUES LESS THAN (2025),
    PARTITION pmax VALUES LESS THAN MAXVALUE
);

연도 기준으로 데이터를 나누면 특정 기간 조회 시 해당 파티션만 스캔한다.
이를 파티션 프루닝(Partition Pruning)이라고 한다.

파티셔닝의 특징

• DB 서버는 그대로 유지
• 쿼리 수정 없이 사용 가능
• 관리와 백업이 상대적으로 단순
• 물리적 분산은 아님

즉, 단일 서버 내에서 관리 효율과 일부 조회 성능을 개선하는 전략이다.

2. 샤딩(Sharding)

샤딩은 데이터를 여러 DB 서버로 물리적으로 분산하는 방식이다.
애플리케이션 레벨에서 어느 서버에 데이터를 저장할지 결정해야 한다.

예를 들어 사용자 ID 기준으로 나누는 방식이 있다.

샤딩의 특징

• 물리적으로 서버 분산
• 수평 확장 가능
• 애플리케이션 수정 필요
• 운영 복잡도 증가

샤딩은 단일 서버 성능 한계를 넘기 위한 구조적 확장 전략이다.
하지만 트랜잭션 처리와 조인 구조가 복잡해진다.

3. 언제 파티셔닝을 선택하는가

다음과 같은 경우 파티셔닝이 적합하다.

• 로그·이력 데이터처럼 시간 기반 분리 가능
• 서버 자원은 충분하나 관리 효율을 높이고 싶은 경우
• 쿼리 구조를 크게 변경하고 싶지 않은 경우

예를 들어 연도별 로그 조회가 많다면 RANGE 파티셔닝이 효과적이다.

4. 언제 샤딩을 선택하는가

다음 상황에서는 샤딩을 고려해야 한다.

• 단일 DB 서버가 CPU·I/O 한계에 도달
• 트래픽이 지속적으로 증가
• 수평 확장이 필요한 구조

단, 샤딩은 설계 단계부터 고려해야 한다.
중간에 도입하면 데이터 이동과 구조 변경 비용이 매우 크다.

5. 자주 발생하는 오해

파티셔닝하면 무조건 빨라진다?

조건절에 파티션 키가 포함되지 않으면 전체 파티션을 스캔한다.
설계 기준과 쿼리 구조가 맞지 않으면 효과가 없다.

샤딩하면 성능 문제가 모두 해결된다?

샤딩은 분산일 뿐, 잘못된 쿼리 구조는 그대로 느리다.
기본적인 인덱스 설계와 쿼리 최적화가 선행되어야 한다.

6. 선택 기준 정리

• 서버 내부 최적화 → 파티셔닝
• 물리적 확장 필요 → 샤딩
• 운영 복잡도 감당 가능 여부 고려
• 트랜잭션 범위와 조인 구조 점검

대용량 대응은 단순 기술 선택이 아니라 아키텍처 판단이다.
현재 병목이 어디인지 먼저 확인한 뒤 전략을 결정해야 한다.

한 줄 요약

파티셔닝은 단일 서버 내 데이터 분할, 샤딩은 여러 서버로 물리적 분산. 관리 효율 개선이면 파티셔닝, 수평 확장이 필요하면 샤딩을 선택하되 기본 쿼리 최적화가 선행되어야 한다.