데이터베이스 파티셔닝 전략 — 샤딩, 수평/수직 분할
[Single DB]
|
+--> [Partitioning]
| same DB / same schema / split by key or range
|
+--> [Sharding]
multiple DBs / split by shard key파티셔닝은 한 데이터베이스 안에서 물리적 또는 논리적 조각을 나누는 방식이고, 샤딩은 데이터베이스 자체를 여러 노드로 나누는 방식입니다. 둘 다 “데이터를 쪼갠다”는 공통점은 있지만, 운영 복잡도와 확장 한계가 완전히 다르기 때문에 먼저 이 구조 차이를 머리에 두고 읽는 것이 중요합니다.
파티셔닝 vs 샤딩
| 구분 | 파티셔닝 | 샤딩 |
|---|---|---|
| 범위 | 단일 DB 내 테이블 분할 | 여러 DB 서버로 분산 |
| 복잡도 | 낮음 | 높음 |
| 확장성 | 수직 확장 | 수평 확장 |
MySQL 파티셔닝
RANGE 파티션 (날짜 기반)
CREATE TABLE orders (
id BIGINT,
created_at DATE,
amount INT
)
PARTITION BY RANGE (YEAR(created_at)) (
PARTITION p2023 VALUES LESS THAN (2024),
PARTITION p2024 VALUES LESS THAN (2025),
PARTITION p2025 VALUES LESS THAN (2026),
PARTITION p_future VALUES LESS THAN MAXVALUE
);LIST 파티션 (상태 기반)
PARTITION BY LIST (status) (
PARTITION p_pending VALUES IN (1),
PARTITION p_paid VALUES IN (2),
PARTITION p_shipped VALUES IN (3),
PARTITION p_done VALUES IN (4)
);HASH 파티션 (균등 분배)
PARTITION BY HASH(user_id) PARTITIONS 8;파티션 관리
-- 파티션 정보 조회
SELECT * FROM information_schema.PARTITIONS
WHERE TABLE_NAME = 'orders';
-- 특정 파티션 조회 (파티션 프루닝)
SELECT * FROM orders PARTITION (p2024);
-- 파티션 추가
ALTER TABLE orders ADD PARTITION (
PARTITION p2026 VALUES LESS THAN (2027)
);
-- 오래된 파티션 삭제 (빠른 데이터 정리)
ALTER TABLE orders DROP PARTITION p2023;샤딩 전략
Range Sharding
user_id 1~1000000 → Shard 1
user_id 1000001~ → Shard 2Hash Sharding
int shardIndex = userId % NUM_SHARDS;
DataSource ds = shards.get(shardIndex);수직 분할 (Vertical Partitioning)
자주 조회되지 않는 대용량 컬럼 분리:
-- 원본: users (id, name, email, profile_image_blob, bio)
-- 분리 후:
-- users (id, name, email)
-- user_profiles (user_id, profile_image_blob, bio)운영 환경에서 어려워지는 지점
- 파티셔닝은 데이터 규모, 보관 정책, 쿼리 라우팅이 추가 운영 복잡도를 정당화할 때만 도움이 된다.
- 팀은 종종 너무 일찍 파티셔닝을 도입하고 실제 병목이 인덱스, 쿼리 형태, 하드웨어 한계였다는 사실을 뒤늦게 발견한다.
- 파티셔닝이 생기는 순간 유지보수, pruning, backfill 경로는 일상 운영 일부가 된다.
중요한 아키텍처 결정
- 파티션 키는 가장 빨리 커지는 컬럼이 아니라 보관 정책과 접근 경로 기준으로 고른다.
- 애플리케이션 쿼리가 실제로 파티션 pruning을 활용할 수 있게 설계한다.
- 첫 파티션을 만들기 전에 archive, drop, rebalance 절차를 계획한다.
실무 예시
시간 기반 파티셔닝은 쿼리 범위와 보관 작업이 잘 맞아 많이 쓰인다.
events_2026_01
events_2026_02
events_2026_03
...피해야 할 안티패턴
- pruning 이득이 거의 없는 테이블에 파티셔닝을 도입하는 것.
- 공통 쿼리를 너무 많은 파티션으로 흩뿌리는 키를 고르는 것.
- 지연 도착 데이터와 재파티셔닝 운영 도구를 무시하는 것.
운영 체크리스트
- 실제 실행 계획으로 pruning 여부를 검증한다.
- 파티션 생성과 퇴역을 자동화한다.
- backfill과 과거 데이터 조회 동작을 테스트한다.
- 파티션 수 증가에 따른 메타데이터 비용과 유지보수 시간을 감시한다.
최종 판단
파티셔닝은 확장성과 보관 운영을 함께 단순화할 때 정당화된다. 보통 쿼리만 더 복잡하게 만들 뿐이라면 대개 잘못된 첫 수다.
Continue Reading
다음으로 읽기 좋은 글
MySQL 인덱스 최적화 전략 — EXPLAIN으로 쿼리 분석하기
MySQL 인덱스의 동작 원리와 최적화 전략을 EXPLAIN 분석과 함께 정리합니다. 복합 인덱스, 커버링 인덱스, 인덱스 힌트까지 실무 예제로 알아봅니다.
🗄️ Database데이터베이스 트랜잭션과 격리 수준 완벽 정리
ACID 속성, 트랜잭션 격리 수준(Read Uncommitted, Read Committed, Repeatable Read, Serializable)과 각 레벨에서 발생하는 문제를 실전 예제로 정리합니다.
📈 최신 동향PostgreSQL 18 최신 동향: 실무에서 진짜 중요한 변화
PostgreSQL 18은 단순 업그레이드 뉴스가 아닙니다. AIO, skip scan, 업그레이드 후 성능 회복, OAuth, generated columns까지 운영팀과 개발팀 모두에게 영향이 큰 변화가 들어왔습니다.
🚀 DevOpsKubernetes 심화 — HPA, Resource 관리, Pod Scheduling
Kubernetes 운영을 설정 모음이 아니라 자원 배치와 장애 복원력의 관점에서 정리합니다. requests/limits, HPA, affinity, taint, PDB, probe를 언제 어떻게 써야 하는지 실무적으로 설명합니다.
다음 탐색