데이터베이스 파티셔닝 설계와 대용량 데이터 관리

대용량 테이블을 관리 가능한 단위로 나누는 방법

파티셔닝은 큰 테이블이나 인덱스를 더 작은 관리 단위로 분할하는 기법이다. 데이터가 늘면서 생기는 확장성 문제에 대응하고, 데이터베이스 성능과 관리 효율을 함께 개선하는 데 사용한다.

다만 파티션을 나눈다는 사실만으로 효과가 보장되지는 않는다. 데이터 특성, 조회 패턴, 유지보수 방식에 맞춰 설계해야 한다.

파티션 단위 운영이 주는 이점

특정 파티션에 장애가 발생하면 전체 테이블 대신 해당 파티션만 영향을 받는다. 유지보수 역시 파티션 단위로 수행할 수 있어 전체 시스템 중단을 줄일 수 있다. 예를 들어 2022년 데이터가 들어 있는 파티션만 대상으로 유지보수할 수 있다.

백업과 복구도 파티션 단위로 수행할 수 있다. 오래된 데이터를 담은 파티션은 단위별로 삭제할 수 있으므로 데이터 관리가 단순해진다. 5년 이상 된 거래 데이터를 포함한 파티션을 한 번에 제거하는 방식이 이에 해당한다.

조회 조건이 파티션 기준과 맞으면 관련 파티션만 스캔하므로 I/O를 줄일 수 있다. 인덱스 크기가 줄어 메모리 사용 효율도 높아지고, 병렬 처리 가능성도 커진다. 특정 날짜 범위를 조회할 때 해당 날짜 파티션만 접근하는 경우가 대표적이다.

분할이 늘리는 비용도 있다

파티션 구조에서는 테이블 간 조인 비용이 커질 수 있다. 특히 날짜 기준으로 나눈 주문 테이블과 지역 기준으로 나눈 고객 테이블처럼, 서로 다른 기준을 가진 테이블을 조인하면 비효율이 발생할 수 있다.

테이블과 인덱스의 파티셔닝을 함께 고려해야 하므로 설계 복잡성도 높아진다. 파티션 키를 잘못 선택하거나 구조를 부적절하게 구성하면 성능이 오히려 떨어질 수 있다.

데이터 분포에 맞춰 고르는 파티셔닝 방식

연속 범위를 나누는 Range 파티셔닝

Range 파티셔닝은 연속된 숫자나 날짜 범위를 기준으로 데이터를 분할한다. 날짜별, 월별, 분기별처럼 시간 기준으로 나누기 적합하며, 이력 데이터 관리에 효과적이다. 거래 테이블을 월별로 파티셔닝하는 구성이 한 예다.

⤢✕

Oracle에서는 다음처럼 날짜 범위를 기준으로 파티션을 정의할 수 있다.

CREATE TABLE sales (
    sale_id NUMBER,
    sale_date DATE,
    amount NUMBER
) PARTITION BY RANGE (sale_date) (
    PARTITION sales_q1 VALUES LESS THAN (TO_DATE('01-APR-2023', 'DD-MON-YYYY')),
    PARTITION sales_q2 VALUES LESS THAN (TO_DATE('01-JUL-2023', 'DD-MON-YYYY')),
    PARTITION sales_q3 VALUES LESS THAN (TO_DATE('01-OCT-2023', 'DD-MON-YYYY')),
    PARTITION sales_q4 VALUES LESS THAN (TO_DATE('01-JAN-2024', 'DD-MON-YYYY'))
);

값 목록을 기준으로 나누는 List 파티셔닝

List 파티셔닝은 명시적으로 지정한 값 목록에 따라 데이터를 분류한다. 지역, 부서, 카테고리처럼 연속되지 않는 범주형 데이터에 적합하다. 국가별 고객 데이터를 나누는 경우를 생각할 수 있다.

⤢✕

PostgreSQL에서는 목록별 파티션을 다음과 같이 구성한다.

CREATE TABLE customers (
    customer_id SERIAL,
    name VARCHAR(100),
    country VARCHAR(50)
) PARTITION BY LIST (country);

CREATE TABLE customers_asia PARTITION OF customers
    FOR VALUES IN ('Korea', 'Japan', 'China', 'India');

CREATE TABLE customers_europe PARTITION OF customers
    FOR VALUES IN ('Germany', 'France', 'UK', 'Italy');

CREATE TABLE customers_america PARTITION OF customers
    FOR VALUES IN ('USA', 'Canada', 'Mexico', 'Brazil');

균등 분산이 필요한 Hash 파티셔닝

Hash 파티셔닝은 파티션 키의 해시값을 기준으로 데이터를 분산한다. 데이터 접근 패턴이 특정 범위나 목록으로 명확히 구분되지 않을 때, 균등한 분할을 위해 사용할 수 있다. 고객 ID를 기준으로 나누는 방식이 예시다.

⤢✕

MySQL의 해시 파티셔닝 예시는 다음과 같다.

CREATE TABLE users (
    user_id INT,
    username VARCHAR(50),
    email VARCHAR(100),
    PRIMARY KEY (user_id)
) PARTITION BY HASH (user_id)
PARTITIONS 4;

기준을 겹쳐 쓰는 Composite 파티셔닝

Composite 파티셔닝은 두 가지 이상 방식을 조합해 복잡한 데이터 분산 요구를 처리한다. Range-List, Range-Hash 조합이 가능하며, 날짜별 범위 파티션 안을 지역별 서브파티션으로 나누는 구성이 예가 된다.

⤢✕

Oracle에서는 Range 파티션 아래에 List 서브파티션을 둘 수 있다.

CREATE TABLE sales (
    sale_id NUMBER,
    sale_date DATE,
    amount NUMBER,
    region VARCHAR2(20)
) PARTITION BY RANGE (sale_date)
SUBPARTITION BY LIST (region) (
    PARTITION sales_q1 VALUES LESS THAN (TO_DATE('01-APR-2023', 'DD-MON-YYYY')) (
        SUBPARTITION q1_asia VALUES ('Asia'),
        SUBPARTITION q1_europe VALUES ('Europe'),
        SUBPARTITION q1_america VALUES ('America')
    ),
    PARTITION sales_q2 VALUES LESS THAN (TO_DATE('01-JUL-2023', 'DD-MON-YYYY')) (
        SUBPARTITION q2_asia VALUES ('Asia'),
        SUBPARTITION q2_europe VALUES ('Europe'),
        SUBPARTITION q2_america VALUES ('America')
    )
);

행을 나눌지, 컬럼을 나눌지

수평 파티셔닝은 튜플, 즉 행 단위로 데이터를 분할한다. 동일한 스키마를 가진 여러 파티션에 데이터를 분산하는 방식이며, 대용량 데이터 처리에 효과적이다. 샤딩(Sharding)이라고도 부른다.

⤢✕

수직 파티셔닝은 컬럼 단위로 데이터를 나눈다. 자주 사용하는 컬럼과 덜 사용하는 컬럼을 분리해 I/O 효율을 높이는 방식으로, 컬럼이 많고 크기가 큰 테이블에서 유용하다. 고객 기본 정보와 상세 정보를 분리하는 사례가 이에 해당한다.

⤢✕

업무 성격에 따른 적용 모습

금융 거래 시스템에서는 거래 테이블을 날짜 기준 Range 파티셔닝으로 나눌 수 있다. 최근 데이터는 SSD에 저장하고 과거 데이터는 저비용 스토리지로 옮기며, 월별 파티션을 활용해 월간 보고서 생성을 최적화한다. 고객 테이블은 지역 기준 List 파티셔닝으로 구성해 지역별 규제 준수를 관리하고 지역별 서비스 중단을 최소화할 수 있다.

전자상거래 플랫폼은 주문일자 기준 Range 파티셔닝으로 시즌별·프로모션별 데이터 분석을 효율화하고, 오래된 주문 데이터의 아카이빙을 단순화할 수 있다. 제품 테이블에는 카테고리 기준 List 파티셔닝을 적용해 카테고리별 재고 관리와 특정 카테고리 제품 검색을 최적화한다.

빅데이터 로그 분석 시스템에서는 로그 테이블에 일자 기준 Range 파티셔닝과 서비스 유형 List 서브파티셔닝을 조합할 수 있다. 일별 로그 관리 자동화, 특정 서비스 로그의 선택적 분석, 로그 보존 정책 적용에 적합하다.

운영 설계에서 확인할 지점

파티션 키는 쿼리 패턴과 자주 사용되는 WHERE 절 조건을 분석해 정한다. 데이터가 균등하게 분포되는지도 함께 고려해야 한다.

파티션 수 역시 데이터 증가율을 반영해야 한다. 지나치게 많으면 관리 오버헤드가 커지고, 너무 적으면 파티셔닝 효과가 줄어든다.

파티션 추가와 삭제를 자동화하는 스크립트를 마련하고, 유지보수 일정을 수립하며, 파티션 상태를 모니터링하는 체계도 필요하다. 인덱스는 로컬 인덱스와 글로벌 인덱스 중에서 선택하고, 파티션과 인덱스 정렬이 일치하는지 확인해야 한다. 불필요한 인덱스는 최소화한다.

제품별 지원 범위

Oracle은 모든 파티셔닝 유형을 지원하며, 인터벌 파티셔닝을 통한 파티션 자동 생성 기능과 파티션 관리 기능을 제공한다.

PostgreSQL은 선언적 테이블 파티셔닝과 상속 기반 파티셔닝을 지원하며, 파티션 프루닝 최적화를 제공한다.

MySQL은 MySQL 5.7 이상에서 파티셔닝을 지원한다. InnoDB, MyISAM 등 스토리지 엔진에서 사용할 수 있고 범위, 목록, 해시, 키 파티셔닝을 지원한다.

SQL Server는 테이블 및 인덱스 파티셔닝을 지원하며, 파티션 함수와 스키마 개념을 사용한다. 슬라이딩 윈도우 전략도 제공한다.

데이터 특성과 접근 패턴에서 출발하는 설계

파티셔닝은 대용량 데이터를 다루기 위한 전략이다. 성능, 가용성, 관리 효율성을 개선할 수 있지만 데이터 특성과 접근 패턴에 맞는 방식 선택이 선행되어야 한다. 적용 전에는 장단점과 비용-효과를 함께 검토해야 한다.