🗄️
데이터베이스
파티셔닝
Partitioning
테이블을 물리적으로 분할. 범위, 리스트, 해시.
📖 상세 설명
파티셔닝(Partitioning)은 대용량 테이블을 물리적으로 여러 조각(파티션)으로 나누어 저장하는 기법입니다. 단일 DB 서버 내에서 테이블을 분할하여 쿼리 성능을 향상시키고 관리를 용이하게 합니다. 샤딩과 달리 애플리케이션 레벨의 변경 없이 DB 레벨에서 처리됩니다.
Range 파티셔닝은 날짜, 숫자 범위로 분할합니다. 로그, 주문 등 시계열 데이터에 적합하며 오래된 파티션을 빠르게 삭제할 수 있습니다. List 파티셔닝은 특정 값 목록으로 분할하며, 지역이나 카테고리별 분할에 유용합니다.
Hash 파티셔닝은 해시 함수로 균등 분배하며, 특정 값에 데이터가 몰리는 것을 방지합니다. Key 파티셔닝은 MySQL의 해시 함수를 사용합니다. 복합 파티셔닝(Composite)은 여러 방식을 조합합니다.
파티션 프루닝(Partition Pruning)은 쿼리가 필요한 파티션만 스캔하도록 최적화하는 것입니다. WHERE 절에 파티션 키가 포함되어야 프루닝이 작동합니다. 실행 계획에서 partitions 항목으로 확인할 수 있습니다.
💻 코드 예제
-- Range 파티셔닝 (날짜 기준)
CREATE TABLE orders (
id INT,
user_id INT,
order_date DATE,
total DECIMAL(10,2)
)
PARTITION BY RANGE (YEAR(order_date)) (
PARTITION p2022 VALUES LESS THAN (2023),
PARTITION p2023 VALUES LESS THAN (2024),
PARTITION p2024 VALUES LESS THAN (2025),
PARTITION p_future VALUES LESS THAN MAXVALUE
);
-- List 파티셔닝 (지역 기준)
CREATE TABLE users (
id INT,
name VARCHAR(100),
region VARCHAR(10)
)
PARTITION BY LIST COLUMNS(region) (
PARTITION p_asia VALUES IN ('KR', 'JP', 'CN'),
PARTITION p_europe VALUES IN ('UK', 'DE', 'FR'),
PARTITION p_america VALUES IN ('US', 'CA', 'BR')
);
-- Hash 파티셔닝 (균등 분배)
CREATE TABLE sessions (
id INT,
user_id INT,
created_at DATETIME
)
PARTITION BY HASH(user_id)
PARTITIONS 8;
-- 파티션 추가
ALTER TABLE orders ADD PARTITION (
PARTITION p2025 VALUES LESS THAN (2026)
);
-- 오래된 파티션 삭제 (데이터 삭제보다 훨씬 빠름)
ALTER TABLE orders DROP PARTITION p2022;
-- 파티션 프루닝 확인
EXPLAIN SELECT * FROM orders WHERE order_date = '2024-06-15';🗣️ 실무 대화 예시
시니어: 로그 테이블이 10억 건이에요. 90일 지난 데이터는 삭제해야 하는데 DELETE가 너무 오래 걸려요.
주니어: 배치로 나눠서 삭제하면 안 될까요?
시니어: 파티셔닝이 더 좋아요. 월별로 Range 파티션을 만들고 DROP PARTITION하면 순식간에 삭제됩니다.
면접관: 파티셔닝과 샤딩의 차이점은 무엇인가요?
지원자: 파티셔닝은 단일 DB 서버 내에서 테이블을 분할하고, 샤딩은 여러 서버로 분산합니다. 파티셔닝은 DB가 투명하게 처리하지만 서버 한계가 있고, 샤딩은 무한 확장 가능하지만 애플리케이션 변경이 필요합니다.
면접관: 파티션 프루닝이 작동하지 않는 경우는요?
지원자: WHERE 절에 파티션 키가 없거나, 함수로 감싸진 경우입니다. 예를 들어 WHERE YEAR(order_date) = 2024는 프루닝이 안 되고, WHERE order_date >= '2024-01-01'은 됩니다.
리뷰어: 파티션이 1000개가 넘었어요. 너무 많으면 관리가 어렵고 성능도 저하돼요.
작성자: 일별로 파티션을 만들었더니 그렇게 됐네요.
리뷰어: 월별이나 분기별로 변경하고, 서브파티셔닝을 고려해보세요. 파티션 수는 100개 이하가 적당해요.
⚠️ 주의사항
- 파티션 키 쿼리: WHERE 절에 파티션 키를 포함해야 파티션 프루닝이 작동합니다. 그렇지 않으면 전체 파티션 스캔이 발생합니다.
- 파티션 수 제한: 파티션이 너무 많으면 메타데이터 관리 오버헤드가 증가합니다. MySQL은 8192개, PostgreSQL은 더 많지만 적정 수를 유지하세요.
- 유니크 키 제약: 파티션 테이블의 유니크 키나 기본 키에는 파티션 키가 포함되어야 합니다.