[DB] Sharding vs Partitioning: 수평 확장의 두 얼굴

Sharding, Partitioning, horizontal sharding, vertical partitioning, shard key, consistent hashing, Citus, Vitess

정의

	Partitioning	Sharding
범위	한 DB 안	여러 DB 노드
목적	큰 테이블 관리	수평 확장 (write/storage)
투명성	DB 가 처리	보통 애플리케이션 인지
예	PostgreSQL PARTITION BY	Citus, Vitess, MongoDB

둘 다 “데이터를 여러 조각으로 나눈다”. 경계 가 DB 노드 안인지 밖인지 차이.

Partitioning (한 DB 안)

-- PostgreSQL: 시간 기준 range partition
CREATE TABLE events (
  id BIGSERIAL,
  created_at TIMESTAMPTZ,
  body JSONB
) PARTITION BY RANGE (created_at);

CREATE TABLE events_2026_06 PARTITION OF events
  FOR VALUES FROM ('2026-06-01') TO ('2026-07-01');

CREATE TABLE events_2026_07 PARTITION OF events
  FOR VALUES FROM ('2026-07-01') TO ('2026-08-01');

종류	의미
Range	시간, 숫자 범위
List	미리 정한 값 (region 등)
Hash	해시 (균등 분포)

장점:

• 큰 테이블 → 작은 partition (VACUUM, index 작음)
• 오래된 partition drop = 빠른 보관 정리
• partition pruning = WHERE 조건이 partition 키면 그것만 스캔

Sharding (여러 DB 노드)

flowchart TB
    Client --> Router[Router / Coordinator]
    Router -->|shard_key % N| S1[(Shard 1)]
    Router -->|shard_key % N| S2[(Shard 2)]
    Router -->|shard_key % N| S3[(Shard 3)]

Shard Key 선택

키 선택	결과
user_id hash	고른 분포, 한 user 가 한 shard
created_at range	hot shard (최근만 트래픽)
tenant_id	멀티 테넌트. 큰 테넌트 = hot
geographic	data residency

Consistent Hashing

자세한 건 Load Balancer 의 consistent hashing 절.

flowchart LR
    Ring((Hash Ring)) --> N1[Node A]
    Ring --> N2[Node B]
    Ring --> N3[Node C]
    Key1["hash(user:42)"] -->|시계방향| N2

노드 추가/제거 시 N/M 만 재분배. Cassandra, DynamoDB, Redis Cluster 의 토대.

Cross-shard Query 의 비용

sequenceDiagram
    Client->>Router: SELECT count(*) FROM users
    par fan-out
        Router->>S1: SELECT count(*)
        Router->>S2: SELECT count(*)
        Router->>S3: SELECT count(*)
    end
    S1-->>Router: 1234
    S2-->>Router: 1567
    S3-->>Router: 1198
    Router->>Router: SUM
    Router-->>Client: 3999

쿼리	비용
WHERE shard_key = X	1 shard
WHERE shard_key IN (X, Y)	2 shard
WHERE other_field = ...	전 shard fan-out
JOIN cross-shard	매우 비쌈 (피하기)
GROUP BY cross-shard	router 가 merge

Vitess (MySQL sharding) 아키텍처

flowchart TB
    App[App] --> VTGate["VTGate (router)"]
    VTGate --> VTTablet1[VTTablet 1]
    VTTablet1 --> MySQL1[(MySQL)]
    VTGate --> VTTablet2[VTTablet 2]
    VTTablet2 --> MySQL2[(MySQL)]
    VTGate --> Topo["Topology Service<br/>(etcd / Zookeeper)"]

• YouTube 가 만들고 기여.
• MySQL 호환 (Vitess client 가 MySQL 프로토콜).
• re-sharding 자동화.

Citus (PostgreSQL extension)

SELECT create_distributed_table('events', 'user_id');
SELECT create_reference_table('countries');   -- 모든 노드 복제

• PostgreSQL 의 extension 으로 동작.
• PG 의 모든 기능 + sharding.
• Microsoft Azure Cosmos DB for PostgreSQL 이 기반.

다른 sharding 전략

전략	의미
Hash-based	hash(key) % N. 균등하지만 N 변경 어려움
Range-based	키 범위. hot shard 위험
Directory-based	lookup table. 유연 + 단일 장애
Consistent hash	hash ring. N 변경 friendly

Re-sharding

shard 추가/제거 시 데이터 이동. 가장 어려운 운영.

flowchart LR
    Old[기존 3 shard] -->|N=4 추가| Migrate[데이터 이동]
    Migrate --> New[4 shard 분배]
    Note["traffic 처리 *지속* 가운데<br/>일관성 유지 어려움"] -.-> Migrate

• 온라인 re-sharding 은 몇 주 ~ 몇 달 운영.
• Vitess, Citus, MongoDB 가 자동 도구 제공.
• 수동 sharding (애플리케이션 레벨) 은 매우 고통.

흔한 함정

Shard 전략 선택 가이드

flowchart TD
    Start["시작: 데이터 분산 필요?"] -->|"단일 DB 안"| P[Partitioning 검토]
    Start -->|"여러 DB 노드 필요"| S[Sharding 검토]
    P -->|"시간 기준"| PR[Range Partition]
    P -->|"균등 분산"| PH[Hash Partition]
    P -->|"지역 / 카테고리"| PL[List Partition]
    S -->|"주요 쿼리에 shard key 포함 가능?"| SK{"shard key 결정"}
    SK -->|"user_id"| SH["Hash-based Shard"]
    SK -->|"날짜 / 범위"| SR["Range-based Shard"]
    SK -->|"멀티 테넌트"| ST["Tenant-based Shard"]

Hot Shard 탐지와 해소

한 shard 에 트래픽 집중 = 전체 성능 병목.

-- Citus: shard 별 크기 확인
SELECT shardid, shard_size(shardid) AS size_bytes
FROM pg_dist_shard
ORDER BY size_bytes DESC;

증상	원인	해결
특정 shard CPU 100%	shard key 쏠림	key 재설계 / sub-sharding
write 지연 특정 시간대만	range shard 의 최신 hot	hash shard 전환
특정 테넌트 slow	대용량 테넌트	해당 테넌트 전용 shard

Partition 관리 자동화

PostgreSQL 의 pg_partman 을 이용한 자동 파티션 생성:

-- pg_partman 설정
SELECT partman.create_parent(
    p_parent_table => 'public.events',
    p_control      => 'created_at',
    p_type         => 'range',
    p_interval     => 'monthly',
    p_premake      => 3              -- 3개월 미리 생성
);

-- 유지보수 함수 (cron 으로 실행)
SELECT partman.run_maintenance();

오래된 파티션 드롭:

UPDATE partman.part_config
SET retention = '6 months', retention_keep_table = false
WHERE parent_table = 'public.events';

• 오래된 partition drop 은 TRUNCATE 급 속도, DELETE 와 비교 불가.
• VACUUM / ANALYZE 도 파티션 단위, 전체 테이블 잠금 없음.

Partition Pruning 검증

-- partition pruning 작동 확인
EXPLAIN ANALYZE
SELECT * FROM events
WHERE created_at >= '2026-06-01' AND created_at < '2026-07-01';
-- "Seq Scan on events_2026_06" 만 나타나야 함
-- "Seq Scan on events" 가 나타나면 pruning 미작동

EXPLAIN 결과	의미
Seq Scan on events_2026_06	pruning 정상 작동
Seq Scan on events (partitions: ...)	pruning 실패, 쿼리 수정 필요
Bitmap Heap Scan on events_2026_06	인덱스 사용 + pruning

운영 체크리스트

• shard key 결정 전 access pattern 목록 작성
• 전체 쿼리 중 shard key 포함 비율 70% 이상 확인
• cross-shard JOIN 최소화 (비정규화 또는 application-side join)
• re-sharding 시뮬레이션 테스트 환경에서 수행
• Hot shard 모니터링 대시보드 (Grafana + Prometheus)
• Partition pruning 동작 EXPLAIN ANALYZE 로 확인
• pg_partman 또는 automated retention 정책 설정

관련 위키

• postgresql, mysql-innodb
• dynamodb, mongodb
• distributed-systems-consensus
• transaction-isolation-levels
• cassandra