데이터베이스 파티셔닝 설계: 대용량 테이블을 나누는 기준

테이블이 커질 때 파티션으로 나누는 이유

대규모 데이터베이스에서는 테이블이나 인덱스가 커질수록 성능과 관리 부담이 함께 커진다. 파티셔닝은 논리적으로 하나인 데이터를 물리적으로 여러 조각으로 분리해 이 문제를 다루는 방식이다.

각 파티션은 전체 데이터의 일부를 담으며 독립적으로 관리할 수 있다. 필요한 파티션만 읽도록 쿼리를 유도하면 I/O를 줄일 수 있고, 유지보수·백업·복구도 파티션 단위로 수행할 수 있다. 대용량 데이터를 다룰 때 가용성과 관리 효율성을 함께 확보하려는 목적이 여기에 있다.

행을 나누거나 열을 분리하는 방식

수평 파티셔닝은 행을 분산한다

수평 파티셔닝은 같은 스키마를 유지한 채 행을 여러 테이블이나 파티션에 나눠 담는 방식이다. 샤딩(Sharding)이라고도 부른다.

⤢✕

고객 데이터를 미주·유럽·아시아처럼 지역별로 나누거나, 로그와 트랜잭션을 월별·분기별로 분할하는 구성이 여기에 해당한다. 고객 ID 범위를 기준으로 데이터를 나누면 부하 분산에도 활용할 수 있다.

수직 파티셔닝은 접근 빈도가 다른 열을 갈라낸다

수직 파티셔닝은 열을 기준으로 테이블을 나누는 방식이다. 자주 읽는 열과 그렇지 않은 열을 분리해 접근 경로를 조정한다.

⤢✕

사용자 프로필에서 기본 정보와 상세 정보를 분리하는 경우가 대표적이다. 제품 테이블에서는 기본 정보와 상세 설명·이미지 URL을 나눌 수 있고, 사용자 테이블에서는 인증 정보와 프로필 정보를 분리할 수 있다.

데이터의 분포와 조회 조건에 맞는 분할 전략

범위로 연속된 데이터를 나누는 경우

범위 파티셔닝은 시간, 날짜, 숫자 ID처럼 연속된 값의 구간을 기준으로 데이터를 분리한다. 범위 조회에 유리하고 데이터 지역성을 확보할 수 있지만, 분포가 치우치면 불균형과 핫스팟이 생길 수 있다.

CREATE TABLE sales_data (
    id INT,
    sale_date DATE,
    amount DECIMAL(10,2)
) PARTITION BY RANGE (YEAR(sale_date)) (
    PARTITION p2019 VALUES LESS THAN (2020),
    PARTITION p2020 VALUES LESS THAN (2021),
    PARTITION p2021 VALUES LESS THAN (2022),
    PARTITION future VALUES LESS THAN MAXVALUE
);

값의 집합이 뚜렷할 때는 리스트를 쓴다

리스트 파티셔닝은 지역 코드나 카테고리처럼 이산적인 값의 집합을 기준으로 한다. 비즈니스 규칙에 맞는 분할과 해당 값 기반 쿼리에 적합하지만, 새로운 값이 생기면 파티션을 수정해야 한다.

CREATE TABLE customers (
    id INT,
    name VARCHAR(100),
    region VARCHAR(20)
) PARTITION BY LIST (region) (
    PARTITION p_asia VALUES IN ('KR', 'JP', 'CN', 'SG'),
    PARTITION p_europe VALUES IN ('UK', 'FR', 'DE', 'IT'),
    PARTITION p_america VALUES IN ('US', 'CA', 'MX', 'BR')
);

균등 분산이 우선이면 해시를 선택한다

해시 파티셔닝은 해시 함수로 데이터를 분배한다. 데이터 분포가 고르지 않을 때 균등 분산과 핫스팟 방지에 도움이 된다. 반대로 범위 조회에는 불리하며, 파티션 수를 바꾸려면 재구성이 필요하다.

CREATE TABLE orders (
    order_id INT,
    customer_id INT,
    order_date DATE
) PARTITION BY HASH (order_id) PARTITIONS 4;

복합 파티셔닝으로 분할 기준을 겹친다

복합 파티셔닝은 범위-해시나 리스트-해시처럼 둘 이상의 방식을 결합한다. 복잡한 요구사항에 맞춰 데이터를 더 세분화할 수 있는 대신 설계와 관리 복잡성도 증가한다.

CREATE TABLE transactions (
    id INT,
    trans_date DATE,
    customer_id INT,
    amount DECIMAL(10,2)
) PARTITION BY RANGE (YEAR(trans_date))
SUBPARTITION BY HASH (customer_id) SUBPARTITIONS 4 (
    PARTITION p2020 VALUES LESS THAN (2021),
    PARTITION p2021 VALUES LESS THAN (2022)
);

설계 전에 확인할 파티션 키와 운영 경계

파티션 키는 데이터 분포, 쿼리의 WHERE 절 조건, 조인에 쓰이는 열, 시간에 따른 데이터 증가 패턴을 함께 보고 결정한다. 균등하게 분포하는 열이라고 해서 항상 적합한 것은 아니며, 실제 조회 패턴과 맞지 않으면 파티션 프루닝의 효과를 얻기 어렵다.

파티션 수 역시 성능과 관리 비용 사이에서 정해야 한다. 각 파티션 크기는 10GB 내외를 권장하며, CPU 코어 수와 디스크 I/O 용량 같은 하드웨어 특성, 파티션 증가에 따른 관리 오버헤드, 미래 데이터 증가를 고려한다.

운영 과정에서는 새 파티션의 추가와 오래된 파티션의 삭제뿐 아니라, 데이터 분포 변화에 따른 병합·분할, 스토리지 최적화를 위한 이동, 대량 적재 시의 파티션 교체가 필요할 수 있다.

-- 새 파티션 추가
ALTER TABLE sales_data ADD PARTITION (PARTITION p2022 VALUES LESS THAN (2023));

-- 파티션 삭제
ALTER TABLE sales_data DROP PARTITION p2018;

-- 파티션 교체 (빠른 데이터 로드)
ALTER TABLE sales_data EXCHANGE PARTITION p2022 WITH TABLE temp_sales_2022;

시간·거래·분석 데이터에서의 활용

로그, 센서 데이터, 거래 내역처럼 시간에 따라 쌓이는 데이터에는 일별·월별·분기별 범위 파티셔닝을 적용할 수 있다. 오래된 데이터의 보관 정책과 연결하고, 파티션 단위 압축 또는 아카이브를 수행하는 구성도 가능하다. 금융 거래 시스템은 월별 트랜잭션 파티셔닝으로 감사 효율성을 높이고, IoT 플랫폼은 시간별 센서 데이터 파티셔닝으로 실시간 분석 성능을 개선할 수 있다.

대규모 전자상거래 환경에서는 제품 카테고리별 리스트 파티셔닝, 고객 ID 기반 해시 파티셔닝, 주문 데이터의 시간 기반 범위 파티셔닝을 조합할 수 있다. 글로벌 쇼핑몰은 지역별 고객 데이터 파티셔닝으로 지역화된 쿼리 성능을 높이고, 대형 마켓플레이스는 판매자별 데이터 파티셔닝으로 멀티테넌트 아키텍처를 구현할 수 있다.

데이터 웨어하우스에서는 차원 테이블에 리스트 파티셔닝을, 팩트 테이블에 범위 파티셔닝을 적용하고 파티션 프루닝으로 쿼리를 최적화한다. 부서별·지역별 파티셔닝은 비즈니스 인텔리전스 시스템의 병렬 처리 효율을 높일 수 있으며, 시간 및 고객 세그먼트 기반 파티셔닝은 고객 분석 플랫폼의 타겟팅 쿼리를 가속화할 수 있다.

클라우드와 분산 데이터베이스의 파티션 관리

클라우드 환경에서는 데이터 분포에 맞춘 자동 파티션 관리, 워크로드에 따른 서버리스 확장, 지리적 위치를 고려한 파티션 배치가 활용된다. Amazon DynamoDB는 자동 파티셔닝 및 리밸런싱을, Azure Cosmos DB는 글로벌 분산 파티셔닝을, Google Spanner는 자동 샤딩 및 글로벌 트랜잭션을 사례로 들 수 있다.

NoSQL과 NewSQL 시스템에서는 일관된 해싱으로 데이터 재분배를 줄이고, 온라인 상태에서 동적 재파티셔닝을 수행하며, 데이터 지역성과 액세스 패턴을 고려해 파티션 배치를 조정한다. MongoDB는 샤딩 기반 수평 확장, Cassandra는 일관된 해싱과 토큰 기반 파티셔닝, CockroachDB는 자동 파티셔닝 및 복제를 제공한다.

실시간 워크로드에서는 워크로드 분석에 따른 자동 조정, 핫스팟 감지와 자동 분할, 파티션 간 데이터 밸런싱이 중요해진다. MySQL 8.0+은 개선된 파티션 관리 및 온라인 재구성을, PostgreSQL은 선언적 파티셔닝 및 파티션 프루닝을, Oracle은 히트맵 기반 자동 파티션 관리를 제시한다.