🚨문제 상황
DB가 단일 테이블, 단일 DB 구조가 한계에 도달했다.
- I/O 병목 심화: 데이터 증가로 인덱스 깊이 증가, 디스크 접근 비용 상승
- 동시성 충돌 증가: 트랜잭션 경합 및 대기 시간 증가
- 운영 비용 폭증: 백업, 복구, 배포 시간이 기하급수적으로 증가
- 물리적 한계 도달: CPU,메모리,디스크 확장의 한계
해결책: 데이터를 논리적으로 또는 물리적으로 나누어야 한다.
DB파티셔닝이란?
한 지붕 아래 여러 방을 만든다. 단일 DB 서버 내부에서 하나의 거대한 테이블을 여러 파티션(저장단위)으로 나누어 저장한다. 개발자는 하나의 테이블처럼 사용하지만, DB 내부에서는 여러 파티션으로 분리되어 저장된다. 그리고 이는 DB 엔진 수준에서 알아서 관리해준다.
파티셔닝 종류
- Range(범위): 날짜나 숫자 범위를 기준으로 분할(ex: 월별 로그, 연도별 데이터)
- List(목록): 특정 값의 목록을 기준으로 분할(ex: 지역코드- 서울, 부산)
- Hash(해시): 해시 함수를 통해 데이터를 균등하게 분산(특정 값의 쏠림을 방지하기 위한 전략)
- Composite(복합): 두 개 이상의 파티션 전략을 조합(Range+Hash)
DB는 파티션 정보를 메타데이터로 관리한다. 이걸 Partition Prunning이라고 한다.**
파티셔닝은 언제 사용할까?
- 로그테이블: 시간 기준으로 지속적으로 누적되는 대용량 테이블
- 날짜 기반 데이터: 최신 데이터 조회 성능이 중요할 때(조회 조건에 날짜 칼럼이 자주 사용될때)
- 대량 데이터 정리 효율: 오래된 데이터를 통째로 정리하고 싶을때(Drop Paritioning)
샤딩이란?
옆 동네에 새 집 짓기. 데이터를 서로 달느 물리적 서버(인스턴스)들에 분산 저장한다. 각 서버를 샤드라고 부르며 수평적 확장의 핵심 기술이다.
샤딩은 언제 사용할까?
- 대규모 트래픽/ 데이터 규모: 단일 DB 한계 넘을 때
- 글로벌 서비스: 한국 서버, 미국 서버 등 지역별 데이터 물리 분산(데이터 로컬리티 확보)
- 성능 극한(Scale-Up 한계): 단일 서버의 사양을 아무리 높여도 성능이 안 나올 때
- 주의: 샤딩을 하면 Join 연산이 매우 힘들어지므로 데이터 모델링이 중요하다
샤딩이라고 하면 보통 수평 분할(행 단위)를 의미한다. 수직 분할(열 단위)는 자주 쓰는 컬럼과 안 쓰는 컬럼을 분리할 때 사용한다.
샤딩 vs 파티셔닝
-
물리적 위치가 다르다.
파티셔닝은 같은 DB 인스턴스 안에서 분리되지만, 샤딩은 서로 다른 DB 인스턴스로의 분산이다. -
확장 방향이 다르다.
파티셔닝은 단일 서버 안에서의 최적화(Scale-Up 한계 내), 샤딩은 여러 서버로의 확장(Scale-Out) 전략 -
책임 주체가 다르다.
파티셔닝은 DB엔진이, 샤딩은 대게 애플리케이션(또는 미들웨어)이 어디로 보낼지 결정한다.(샤딩은 Shard Key 기반 라우팅 로직이 필요)
요점 정리
파티셔닝은 단일 DB 서버 내에서 조회성능과 관리 효율을 위해 테이블을 쪼개는 내부 최적화이다. 샤딩은 하드웨어 한계를 넘기 위해 데이터를 여러 대의 서버에 분산하는 물리적 확장이다.
파티셔닝은 SQL 변경 없이 투명하게 적용 가능하지만, 샤딩은 애플리케이션 레벨에서 데이터 분산 로직을 신경 써야 하며 Join 제약이 생긴다.
샤딩은 선택이 아니라 최후의 수단에 가깝다. 단일 DB의 한계를 넘었을 때 도입한다.
출처: 코딩하는 기술사 - 대량 데이터를 나누는 기술, 파티셔닝과 샤딩
