파티셔닝은 데이터를 나누는 저장·관리 경계이고, pruning은 질의 시 읽을 경계를 줄이는 실행 최적화입니다. 이 둘을 유일성이나 샤딩의 보장으로 확대하지 않으려면 먼저 시간 경계와 물리 파티션 선택을 확인한 뒤, 남은 행의 인덱스와 전역 식별자 계약을 따로 평가해야 합니다.
파티션 제거와 잔여 파티션 내부 탐색
5년 데이터를 날짜로 나누고 오늘 파티션 하나만 읽으면 나머지를 제외하는 이점이 있습니다. 하지만 그 하루에 수억 행이 있고 고객 한 명의 20개 주문을 찾는다면 내부 인덱스가 여전히 중요합니다. pruning은 읽지 않을 파티션을 고르는 최적화이고 남은 파티션의 접근 방식은 별도입니다.
고객 ID만으로 조회하며 날짜 조건이 없으면 많은 파티션에 같은 탐색을 반복할 수 있습니다. 파티셔닝을 여러 서버로 자동 분산하는 샤딩과 동일하게 설명하지 않습니다. 실제 물리 배치와 관리 구조를 확인해야 합니다.
질의 조건과 파티션 키 경계 표현
| 질의·상태 | 확인할 것 | 남는 비용 |
|---|---|---|
| 최근 날짜 범위 | 필요한 파티션만 선택되는가 | 내부 index·scan |
| 날짜 함수·암묵 변환 | 경계 추론이 가능한가 | 전체 파티션 탐색 가능 |
| prepared parameter | 계획·실행 시 pruning 지원 | 실제 실행 partition 수 |
| 고객 ID 단독 | 날짜 범위가 없는가 | 많은 partition별 lookup |
| 지연 입력 | 오래된·닫힌 partition 처리 | 거절·기본 partition·보정 |
날짜 경계는 start 이상 next_start 미만처럼 시작을 포함하고 끝을 제외하는 half-open 범위로 계산하고, 두 시각을 업무 시간대 기준으로 맞춥니다.
예를 들어 업무 시간대 기준 2026-09-01T00:00 이상 2026-10-01T00:00 미만을 요청하면 9월 파티션만 남아야 하고, 정확히 10월 1일의 행은 포함되지 않아야 합니다. 실행 기록에서 9월만 읽혔더라도 고객 ID 인덱스가 없어 수억 행을 scan할 수 있으므로, 파티션 수와 내부 logical reads를 함께 봅니다. 반대로 날짜를 함수로 감싸거나 타입을 암묵 변환하면 같은 의미의 범위라도 pruning이 약해질 수 있어 실제 실행 통계로 확인합니다.
전역 ID 중복이 문제라면 서로 다른 두 파티션에 같은 id=42를 동시에 넣는 시험을 먼저 설계합니다. 둘 다 성공하면 로컬 UNIQUE(date,id)가 외부 계약을 보장하지 않는다는 뜻이고, registry 예약 또는 엔진의 전역 제약을 같은 동시성 조건에서 다시 검증해야 합니다. 질의를 실행할 때 estimated plan의 파티션 노드 수만 세지 말고, 실제 실행에서 제거된 파티션과 읽은 파티션의 수·각 읽기량을 함께 비교합니다. runtime pruning을 지원하는 엔진에서는 계획에 많은 파티션 노드가 남아도 실행 시 줄어들 수 있으므로 estimated plan만으로 전체 파티션 탐색이라고 단정하지 않습니다.
그림을 글로 읽기
- 9월의 고객 7 주문
- 9월 파티션 선택
- 파티션 내부 고객 인덱스
- 필요 행·반환 컬럼
- 9월의 고객 7 주문 → 9월 파티션 선택: partition pruning
- 9월 파티션 선택 → 파티션 내부 고객 인덱스: 다른 달 제외
- 파티션 내부 고객 인덱스 → 필요 행·반환 컬럼: 행 탐색·lookup
날짜 포함 UNIQUE 제약과 조합 유일성의 의미
UNIQUE(date,id)는 id 단독이 아니라 date를 포함한 조합을 유일하게 만드는 제약입니다. 예를 들어 9월의 id=42와 10월의 id=42는 날짜가 달라 서로 다른 조합으로 함께 존재할 수 있지만, 외부 API가 /orders/42 하나로 주문을 식별한다면 이 로컬 조합 제약만으로는 부족합니다. 전역 unique index를 지원하는지와 partition key를 제약에 포함해야 하는지는 엔진의 실제 버전에서 확인해야 합니다.
외부 ID 42를 어디서나 하나의 주문으로 쓰려면, 상세 row를 넣기 전에 전역 ID registry에서 42를 예약하거나 날짜를 포함한 식별자로 외부 계약을 바꾸거나 엔진이 지원하는 전역 제약을 사용해야 합니다. registry와 상세 삽입이 같은 DB transaction에 들어가면 예약과 상세 row를 함께 commit하고, 다른 저장소라면 예약·확정·실패 재개 상태를 별도로 남겨야 합니다. UUID의 매우 낮은 충돌 확률은 같은 논리 주문의 중복 제출을 막는 멱등성과 다른 문제입니다.
날짜 수정으로 행이 다른 partition으로 이동하거나 backfill·복구가 과거 partition에 삽입할 때도 같은 유일성 규칙을 지켜야 합니다. 정상 웹 쓰기만 검증하고 관리 import를 제외하면 전역 계약이 깨질 수 있습니다.
파티션 관리 이득과 소형 파티션 비용
기간별 detach·drop은 오래된 데이터 정리를 단순하게 할 수 있지만 잠금·외래키·global index·백업과 보관 요구를 확인해야 합니다. 삭제는 단순 메타데이터 최적화가 아니라 데이터 보존 결정입니다. 아직 참조·지연 이벤트·복구 요구가 있는 구간을 임의로 지우지 않습니다.
너무 많은 작은 partition은 계획 시간·메타데이터·파일·통계·운영 비용을 키웁니다. 새 partition 생성 실패·기본 partition의 비대화·통계 편중도 관찰합니다. 보관 관리가 주목적이라면 다른 질의의 비용을 인정하고 별도 읽기 모델을 검토합니다.
파티션 조회와 전역 유일성 시험
날짜 경계·지연 입력·partition 누락·키 단독 조회에서 실행 partition 수와 읽기량을 확인합니다. 서로 다른 partition에 동일 ID를 동시에 넣고 날짜 이동·복구에서도 전역 제약이 유지되는지 봅니다. 현재 작업에서는 제품별 partition DDL·동시 쓰기를 실행하지 않았습니다. 본문은 범위와 제약 의미의 설명입니다.