파티셔닝
고친 사람 github-actions[bot]
파티셔닝은 커다란 데이터 하나를 작은 조각 여럿으로 나눠 담는 일입니다. 조회는 필요한 조각만 읽고, 지울 때는 조각을 통째로 버립니다. 앱에서는 여전히 데이터 하나로 보입니다. 디스크를 여러 구역으로 나누는 일도 같은 이름으로 부르지만 이 문서는 데이터를 나누는 쪽을 다룹니다.
쉽고 빠른 이해
파티셔닝은 큰 표를 달마다, 지역마다 같은 기준으로 잘라 따로 보관하는 일입니다. 이렇게 나뉜 조각 하나하나를 파티션이라고 합니다. 주문 기록을 달마다 나눠 두면 「9월 주문」을 찾을 때 9월 조각만 펼칩니다.
나누지 않으면 곤란한 일이 생깁니다. 몇 년 치가 한 덩어리에 쌓이면 한 달 치를 찾을 때도 전부를 뒤집니다. 오래된 기록을 지울 때도 한 줄씩 골라 지우느라 오래 걸립니다.
어떻게 도나:
- 나누는 기준이 될 열 하나를 고릅니다. 주문일 같은 열입니다
- 새 기록이 들어오면 그 열의 값을 보고 들어갈 조각을 정합니다
- 찾을 때 조건에 그 열이 있으면 맞는 조각만 읽습니다
대가가 있습니다. 조건에 기준 열이 없으면 모든 조각을 다 읽습니다. 기준을 잘못 고르면 한 조각에만 데이터가 몰립니다. 조각이 많아지면 관리할 것도 늘어납니다.
그래서 테이블이 충분히 크고, 조회 대부분이 같은 열로 범위를 좁힐 때 씁니다. 테이블이 작거나 조회 조건이 제각각이면 나누지 않는 편이 낫습니다.
상세
서류가 가득 찬 캐비닛 하나를 떠올려 봅시다. 몇 년 치 영수증을 한 서랍에 쌓아 두면 지난달 영수증 한 장을 찾을 때 서랍 전체를 뒤집니다. 서랍마다 달을 적어 나눠 두면 그 달 서랍만 열면 됩니다.
파티셔닝은 논리적으로 하나인 데이터를 물리적으로 여러 조각에 나눠 담는 일입니다. 여기서 「논리적으로 하나」는 앱이 이름 하나로 부른다는 뜻입니다. 「물리적으로 여럿」은 실제 저장이 조각마다 따로 된다는 뜻입니다. 이렇게 나뉜 조각 하나하나를 파티션이라고 부릅니다.
가장 흔한 대상은 데이터베이스의 테이블입니다. 예를 들어 주문 테이블을 달마다 나누면 7월 주문, 8월 주문, 9월 주문이 각각 다른 파티션에 들어갑니다. 앱이 보내는 SQL(Structured Query Language, 구조화 질의 언어) 문장은 나누기 전과 같습니다. 어느 파티션을 읽을지는 데이터베이스가 정합니다.
이 절은 먼저 왜 나누는지 봅니다. 그다음 무엇을 기준으로 어떻게 나누는지, 나눠서 조회가 어떻게 빨라지는지 봅니다. 끝으로 비슷한 말들과 어떻게 갈리는지, 무엇을 대가로 치르는지 봅니다.
한 덩어리로 둘 때 생기는 문제
테이블이 작을 때는 나눌 이유가 없습니다. 문제는 데이터가 계속 쌓이기만 할 때입니다. 주문 기록, 접속 로그, 센서 측정값 같은 데이터가 그렇습니다. 이런 데이터는 지우지 않으면 끝없이 커집니다.
첫째 문제는 조회입니다. 최근 한 달 치만 보고 싶어도 테이블이 하나면 전체를 뒤져야 할 수 있습니다. 인덱스가 있으면 덜 뒤지지만, 인덱스 자체도 테이블을 따라 커집니다.
둘째 문제는 지우기입니다. 오래된 기록을 버리려면 조건에 맞는 행을 하나씩 찾아 지워야 합니다. 행이 많으면 이 작업이 오래 걸립니다. 그동안 다른 쓰기와 부딪힙니다.
셋째 문제는 관리입니다. 테이블 전체를 백업하거나 정리하는 작업이 한 번에 너무 커집니다. 한 달 치만 따로 다루고 싶어도 쪼갤 단위가 없습니다.
파티션 키
데이터를 나누려면 행마다 「어느 파티션에 넣을지」를 정할 기준이 있어야 합니다. 그 기준으로 쓰는 열을 파티션 키라고 부릅니다. 주문 테이블이라면 주문일이 흔한 파티션 키입니다.
새 행이 들어오면 데이터베이스가 그 행의 파티션 키 값을 봅니다. 그리고 값에 맞는 파티션 하나를 골라 거기에 넣습니다. 행 하나는 언제나 파티션 하나에만 들어갑니다. 파티션끼리는 겹치는 행이 없습니다.
파티션 키를 고르는 일이 파티셔닝의 성패를 가릅니다. 조회 조건에 자주 나오는 열이어야 뒤에서 볼 「필요한 조각만 읽기」가 됩니다. 값이 고르게 퍼지는 열이어야 한 파티션에만 데이터가 몰리지 않습니다.
나누는 방식
파티션 키 값으로 파티션을 고르는 방법은 크게 셋입니다. 셋은 키 값을 파티션에 짝짓는 규칙만 다릅니다.
| 방식 | 파티션을 고르는 규칙 | 예 |
|---|---|---|
| 범위 | 값이 어느 구간에 드는가 | 주문일이 9월이면 9월 파티션 |
| 목록 | 값이 어느 목록에 들어 있나 | 지역이 서울·경기면 수도권 파티션 |
| 해시 | 값을 숫자로 바꾼 뒤 파티션 수로 나눈 나머지 | 사용자 번호를 4로 나눈 나머지 |
범위 파티셔닝은 날짜처럼 순서가 있는 값에 맞습니다. 「9월 1일부터 9월 30일까지」 같은 구간 조회가 파티션 하나에 딱 떨어집니다. 대신 새 데이터가 늘 가장 최근 파티션에만 들어갑니다. 쓰기가 한 파티션에 쏠리니 그 파티션 하나가 쓰기 부하를 다 받습니다.
목록 파티셔닝은 값의 종류가 몇 개로 정해져 있을 때 씁니다. 지역, 나라, 상품 분류 같은 열입니다. 목록에 없는 값이 들어오면 받을 파티션을 따로 정해 둬야 합니다.
해시 파티셔닝은 데이터를 고르게 퍼뜨리려고 씁니다. 해시 함수는 입력을 받아 고르게 흩어진 숫자로 바꾸는 함수입니다. 그 숫자를 파티션 수로 나눈 나머지가 파티션 번호가 됩니다. 해시를 거치는 까닭은 키 값에 규칙이 있을 때 나머지도 따라 몰리기 때문입니다. 번호가 모두 짝수로만 매겨지면 4로 나눈 나머지는 0과 2뿐이라 파티션 둘이 빕니다. 해시 함수는 이런 규칙을 흐트러뜨리고, 글자로 된 키도 숫자로 바꿔 줍니다.
아래는 해시를 빼고 사용자 번호를 그대로 숫자로 쓴 가장 단순한 모습입니다. 나머지로 파티션을 고르는 부분만 보려는 것입니다.
N = 4 # 파티션 수
1027 % N # 3
1028 % N # 0
사용자 1027 은 3번 파티션에, 사용자 1028 은 0번 파티션에 들어갑니다. 번호가 이웃해도 다른 파티션으로 흩어집니다.
그래서 해시 방식은 「사용자 1027 의 주문」처럼 키 하나를 콕 집는 조회에 맞습니다. 「번호 1000 부터 2000 까지」 같은 구간 조회에는 모든 파티션을 읽어야 합니다.
필요한 조각만 읽기
파티셔닝으로 조회가 빨라지는 까닭은 읽지 않아도 되는 파티션을 미리 빼기 때문입니다. 이것을 파티션 프루닝이라고 부릅니다. 프루닝은 가지치기라는 뜻입니다.
데이터베이스는 조회 조건을 보고 파티션 키에 대한 조건을 찾습니다. 조건이 「주문일이 9월」이면 7월과 8월 파티션에는 맞는 행이 있을 수 없다는 것을 압니다. 그래서 9월 파티션만 읽습니다.
flowchart TD
Q["조회 · 9월 주문만"]
subgraph T["주문 테이블 · 앱에는 하나로 보인다"]
P7["7월 파티션"]
P8["8월 파티션"]
P9["9월 파티션"]
end
Q -->|읽는다| P9
Q -.->|건너뛴다| P7
Q -.->|건너뛴다| P8
그림에서 앱은 주문 테이블 하나에 물었습니다. 실제로 읽힌 것은 9월 파티션 하나입니다. 파티션이 서른여섯 개여도 읽는 양은 한 달 치로 같습니다.
반대로 조건에 파티션 키가 없으면 프루닝이 안 됩니다. 「고객 이름이 김철수인 주문」은 어느 달에 있을지 모르니 모든 파티션을 읽습니다. 파티션 키를 조회 패턴에 맞춰 골라야 하는 까닭이 이것입니다.
파티션을 통째로 버리기
쌓이는 데이터는 대개 오래된 것부터 버립니다. 달마다 나눠 두었다면 오래된 달의 파티션을 통째로 떼어 내면 됩니다. 행을 하나씩 찾아 지우는 대신 조각 하나를 버리는 일이라 금방 끝납니다.
이 방식은 데이터 보존 기간을 지키는 데 잘 맞습니다. 「주문 기록은 3년만 둔다」면 달이 바뀔 때마다 가장 오래된 파티션 하나를 떼어 냅니다. 떼어 낸 파티션을 지우지 않고 값싼 저장소로 옮겨 아카이빙하기도 합니다.
수평 파티셔닝과 수직 파티셔닝
지금까지 본 것은 행을 기준으로 나누는 수평 파티셔닝입니다. 표를 가로줄 단위로 자르는 모습이라 이런 이름이 붙었습니다. 보통 파티셔닝이라고 하면 이쪽을 가리킵니다.
수직 파티셔닝은 열을 기준으로 나눕니다. 자주 읽는 열과 가끔 읽는 큰 열을 다른 테이블로 떼어 내는 식입니다. 회원 테이블에서 이름·이메일은 남기고 긴 자기소개 글은 따로 두면, 목록 조회가 큰 글을 끌고 다니지 않습니다. 다만 떼어 낸 열은 대개 이름이 다른 테이블에 가므로 앱이 두 테이블을 알아야 합니다. 「이름 하나로 부른다」는 앞의 정의에서 이 점이 벗어납니다.
수직 파티셔닝은 정규화로 테이블을 나누는 것과 겉모습이 비슷하지만 목적이 다릅니다. 정규화는 중복을 없애려고 나눕니다. 수직 파티셔닝은 읽는 양을 줄이려고 나눕니다.
데이터 파이프라인에서의 파티셔닝
데이터 엔지니어링에서는 테이블 대신 쌓인 파일들을 나눕니다. 날마다 쌓이는 로그 파일을 날짜별 폴더에 나눠 두는 식입니다. 폴더 이름에 dt=2026-09-18 처럼 열 이름과 값을 넣는 꼴을 흔히 씁니다.
원리는 데이터베이스와 같습니다. Apache Hive 나 Apache Spark 같은 분석 도구가 「9월 18일 로그」를 읽을 때 폴더 이름만 보고 그 날짜 폴더만 엽니다. 파일 수천 개를 열어 볼 필요가 없습니다. 데이터 레이크처럼 파일이 끝없이 쌓이는 곳에서는 이 나눔이 없으면 조회 한 번이 전부를 읽습니다.
샤딩과의 차이
샤딩도 데이터를 겹치지 않는 조각으로 나눕니다. 흔히 가르는 기준은 조각이 어디에 사느냐입니다. 파티셔닝은 조각들이 서버 한 대 안에 있어도 파티셔닝입니다. 샤딩은 조각을 여러 서버에 나눠 둡니다.
그래서 샤딩은 서버 한 대의 디스크와 처리 능력을 넘어서려고 씁니다. 한 서버 안의 파티셔닝은 조회와 관리를 가볍게 하려고 씁니다. 다만 문헌과 제품에 따라 두 낱말을 같은 뜻으로 쓰기도 합니다. Apache Kafka 는 여러 서버에 흩어진 조각을 파티션이라고 부릅니다.
같은 이름의 다른 뜻
디스크 파티션은 저장 장치 하나를 여러 구역으로 나누는 일입니다. 구역마다 따로 파일 시스템을 올립니다. 데이터를 나눈다는 점은 같지만 나누는 대상이 테이블이 아니라 디스크입니다.
분단은 네트워크가 끊겨 서버들이 서로를 못 보게 갈라지는 사고입니다. 영어로는 network partition 이라 같은 낱말이 들어갑니다. 사람이 설계로 고른 나눔이 아니라 저절로 일어나는 장애라는 점에서 파티셔닝과 다릅니다.
대가
파티셔닝은 조회 패턴과 맞을 때만 이득이 납니다.
| 대가 | 무엇이 곤란해지나 |
|---|---|
| 키 없는 조회 | 조건에 파티션 키가 없으면 모든 파티션을 읽습니다. 나누기 전보다 느려질 수도 있습니다 |
| 쏠림 | 값이 한쪽에 몰리는 키를 고르면 파티션 하나만 커집니다 |
| 파티션 수 | 너무 잘게 나누면 파티션마다 드는 관리 비용이 쌓입니다 |
| 테이블 전체의 중복 금지 | 주문 번호가 테이블 전체에서 하나뿐이어야 한다는 규칙을 지키기 어려워집니다. 파티션마다 따로 저장되니 새 번호를 넣을 때 다른 파티션의 번호까지 함께 봐야 합니다 |
| 키 바꾸기 | 이미 나눈 뒤에 파티션 키를 바꾸려면 데이터를 전부 옮겨야 합니다 |
한 파티션에만 읽기나 쓰기가 몰리는 것을 핫스팟이라고 부릅니다. 범위 방식에서 최신 날짜 파티션에 쓰기가 몰리는 것이 대표적인 예입니다. 해시 방식은 이 쏠림을 줄이는 대신 구간 조회를 포기합니다.
그래서 파티셔닝은 테이블이 충분히 크고, 조회 대부분이 같은 열로 범위를 좁힐 때 씁니다. 테이블이 작거나 조회 조건이 제각각이면 인덱스만으로 충분한 경우가 많습니다.
관련 항목
파티셔닝을 이루는 구성 요소
파티션 · 파티션 키 · 파티션 프루닝 · 기본 파티션 · 하위 파티션
파티셔닝의 하위 종류
범위 파티셔닝 · 목록 파티셔닝 · 해시 파티셔닝 · 수평 파티셔닝 · 수직 파티셔닝 · 복합 파티셔닝
파티셔닝에서 자주 겪는 문제와 처방
핫스팟 · 데이터 쏠림 · 전체 파티션 스캔 · 리파티셔닝
파티셔닝과 견주어 고르는 확장·조회 기법
샤딩 · 샤드 · 복제 · 일관성 해싱 · 정규화 · 인덱스
파티셔닝을 실제로 구현·채택한 제품
PostgreSQL · MySQL · Oracle Database · Apache Hive · Apache Spark · Apache Kafka · BigQuery
파티셔닝이 적용되는 데이터
테이블 · 시계열 데이터 · 로그 · 데이터 레이크 · 데이터 웨어하우스 · 데이터 보존 기간 · 아카이빙
파티셔닝이라는 이름이 겹치는 이웃
디스크 파티션 · 파일 시스템 · 분단 · 네트워크 파티션
파티셔닝이 속하는 상위 분류
다른 이름: 분할 · 데이터 파티셔닝 · partitioning