결정: 어떤 파티셔닝 전략인가?

파티셔닝은 큰 테이블을 하나의 논리적 이름 아래 여러 물리적 조각으로 나누어 오래된 데이터 삭제를 쉽게 하고, 쿼리가 관련 조각만 보도록 한다(partition pruning). 그러나 작은 테이블에서는 복잡성만 늘린다. 이 트리는 먼저 파티셔닝이 정말 필요한지 묻고, 접근 및 분포 패턴에 따라 Range, List, Hash, Composite 중 선택을 안내한다.

테이블이 파티셔닝이 필요할 만큼 정말 큰가?

파티셔닝은 성능 마법이 아니라 규모와 유지보수(수명 주기) 도구다. 테이블이 충분히 크지 않거나 쿼리가 이미 인덱스로 잘 동작한다면 파티셔닝은 실행 계획 복잡성과 관리 부담만 가져온다. 테이블이 수천만 행 이상/수백 GB에 이르는가, 아니면 아직 소/중규모인가?

• 예, 매우 크고/또는 오래된 데이터를 일괄 삭제/아카이브해야 함
• 아니요, 소/중규모 테이블이거나 확실하지 않음

데이터에 어떻게 접근하며, 어떻게 분할해야 하는가?

파티션 키는 대부분의 쿼리가 필터링하는 컬럼이어야 한다. 그래야만 pruning이 동작한다. 지배적인 접근 패턴은 무엇인가? 날짜/순차 범위(최근 30일)인가, 특정 카테고리/리전 값인가, 아니면 명확한 필터 없이 부하를 균등하게 분산하려는가?

• 날짜/시퀀스 번호 같은 순차 범위(최근 X일, 월별)
• 카테고리/리전/테넌트 같은 이산 값 집합
• 명확한 범위/카테고리 없음, 부하 균등 분산이 목표
• 날짜와 대용량 모두, 두 차원으로 분할 필요

권장: (아직) 파티셔닝하지 않는다

소/중규모 테이블에서 파티셔닝은 이점이 없다. 잘 선택한 인덱스와 일반적인 유지보수로 충분하다. 성급한 파티셔닝은 쿼리 실행 계획을 복잡하게 하고, 잘못된 키로 pruning을 놓치며, 운영 부담을 더한다.

권장: Range 파티셔닝

Range 파티셔닝은 컬럼의 순차 범위(예: 날짜 범위: 월/분기마다 파티션 하나)로 행을 분할한다. 시계열과 계속 증가하는 테이블에 가장 일반적이고 강력한 전략이다.

권장: List 파티셔닝

List 파티셔닝은 컬럼의 이산적이고 알려진 값(예: region = 'TR','EU','US' 또는 tenant ID)으로 행을 그룹화한다. 자연스럽고 유한한 카테고리가 있으면 접근과 관리가 명확해진다.

권장: Hash 파티셔닝(균등 분산)

Hash 파티셔닝은 키 컬럼의 해시를 기준으로 미리 정한 수의 파티션에 행을 비교적 균등하게 분산한다. 자연스러운 범위/카테고리가 없을 때 핫스팟을 피하고 부하를 균형 있게 하는 데 사용한다.

권장: Composite(다단계) 파티셔닝

Composite 파티셔닝은 두 가지 전략을 결합한다: 먼저 상위 수준에서 분할한 뒤 각 파티션을 서브파티션으로 나눈다(예: Range-by-Hash 또는 Range-by-List). 시간 기반 수명 주기와 균등 분산/카테고리 분리가 동시에 필요할 때 사용한다.