데이터베이스 샤딩

같은 사용자 키 8개를 레인지·해시로 쪼개 핫스팟과 균등 분포를 대비시키고, mod 리샤딩의 대량 이동(5/8)과 크로스 샤드 질의의 scatter-gather까지 실행한다.

1 / 7사용자 테이블이 한 대의 DB에 다 안 들어갑니다. 복제(같은 데이터 여러 벌)로는 쓰기가 안 나뉩니다 — 데이터 자체를 쪼개는 것이 샤딩입니다. 문제는 '어떻게 쪼개는가'.

단일 DB (한계 초과)

101102103104105106107108

샤드 키 선택이 전부를 결정한다

단계 목록 · 키보드 ←/→ 이동, Space 재생

샤딩은 '데이터 자체를 여러 DB로 쪼개 쓰기를 나누는 것'이고, 성패는 샤드 키 선택이 결정한다 — 복제가 읽기를 늘린다면, 샤딩만이 쓰기를 늘린다.

왜 헷갈리는가

복제·파티셔닝·샤딩이 자주 섞인다. 복제 = 같은 데이터 여러 벌(읽기 확장·가용성), 파티셔닝 = 한 DB 안에서 테이블 쪼개기, 샤딩 = 서로 다른 데이터가 서로 다른 DB로(쓰기 확장). '읽기가 문제인가 쓰기가 문제인가'를 물으면 갈린다.

애니메이션이 보여주는 것

레인지 샤딩은 범위 질의가 쉽고 위치 계산이 자명하지만, 순차 키(가입 ID·시간)에서는 최신 범위 = 가장 바쁜 데이터가 한 샤드에 몰린다(핫스팟). 해시 샤딩은 그 반대다 — 균등하지만 범위 질의가 전 샤드를 두드리게 된다.

그리고 두 개의 폭탄. mod 리샤딩: 샤드 2→3에서 키 5/8이 집을 옮긴다 — hash % N의 N이 바뀌면 매핑 대부분이 무효가 되므로, 일관 해싱(링+가상 노드)으로 이동을 1/N 수준으로 줄인다. 크로스 샤드 질의: '전체 최근 가입 10명'은 모든 샤드에 묻고 모아 재정렬해야 하며, 샤드를 가로지르는 JOIN·트랜잭션은 사실상 응용 계층의 일이 된다.

샤드 키 고르기 — 실전 규칙

샤딩 설계의 8할이 이 결정이다.

'가장 자주 함께 조회되는 단위'를 키로: SaaS는 테넌트 ID, 커머스는 사용자 ID — 한 요청이 한 샤드에서 끝나게.
카디널리티가 높고 접근이 고른 키: 국가 코드처럼 낮은 카디널리티는 몇 샤드에 몰린다. 유명인 문제(한 키가 초대형)는 그 키만 하위 분할로 푼다.
시간 키가 필요하면 복합 키(테넌트+시간)나 버킷 섞기 — 순수 시간 레인지는 핫스팟 공식이다.
실제 시스템: Vitess(유튜브)·Citus는 SQL 위 샤딩을, DynamoDB·Cassandra는 파티션 키를 강제해 이 결정을 스키마 설계 시점으로 당긴다. MongoDB는 레인지·해시 둘 다 지원.

샤딩은 마지막 카드

샤딩이 들어오는 순간 JOIN·트랜잭션·유니크 제약·시퀀스가 전부 어려워지고 운영 부담(백업·마이그레이션·리밸런싱)이 곱해진다. 인덱스 튜닝, 캐시, 읽기 복제, 테이블 파티셔닝, 수직 분리(기능별 DB)로 버틸 수 있는 데까지 버틴 뒤의 선택이어야 한다.

기억할 것

복제는 읽기를, 샤딩은 쓰기를 확장한다 — 문제가 뭔지부터 확인.
레인지 = 범위 질의 쉬움 + 핫스팟 위험, 해시 = 균등 + 범위 질의 fanout.
hash % N은 리샤딩 폭탄 — 일관 해싱으로 이동을 1/N로 줄인다.
샤드 키는 '함께 조회되는 단위' — 한 요청이 한 샤드에서 끝나게.
샤딩은 인덱스·캐시·복제·파티셔닝을 소진한 뒤의 마지막 카드다.