날짜 파티션 테이블에서 주문 ID를 전역 유일하게 만들려 합니다. 파티션별 고유 인덱스만으로 충분한가요?

각 파티션 내부의 유일성은 서로 다른 파티션에 같은 ID가 들어오는 것을 막지 못할 수 있습니다. 엔진이 지원하는 글로벌 제약인지, 파티션 키를 포함해야 하는 로컬 제약인지 구분해야 합니다.

동작 원리와 전제

(date,id)가 유일하면 같은 날짜 안 중복은 막지만 날짜가 다른 같은 id는 허용할 수 있습니다. 업무상 id 하나로 주문을 식별한다면 제약 의미가 달라집니다. PostgreSQL 등의 파티션 제약 조건을 다른 제품에 그대로 일반화하지 않고 실제 버전을 확인합니다.

선택과 실패 처리

전역 등록 테이블에서 ID를 예약하거나 파티션 키가 포함된 식별자를 외부 계약으로 쓰는 대안이 있습니다. UUID 생성은 충돌 가능성을 매우 낮추지만 중복 요청이 같은 주문을 두 번 만드는 문제와는 별개입니다. ID 생성 전략과 요청 멱등성·DB 제약을 함께 둡니다.

구체적인 사례와 검증

주문 번호 42가 9월 파티션과 10월 파티션에 각각 들어갈 수 있다면 외부 API의 /orders/42는 모호해집니다. 날짜까지 API 키에 포함할지 전역 registry에서 번호를 관리할지 결정해야 합니다. 로컬 제약에 날짜를 추가하고도 사용자에게는 ID 하나가 전역 유일하다고 설명하면 계약이 어긋납니다. registry와 상세 삽입을 다른 transaction으로 처리하면 예약만 남거나 상세만 생기는 실패가 있을 수 있어 상태와 복구를 설계합니다. 유일성을 생성기의 확률에만 맡길지 DB에서 최종 강제할지 오류 비용에 맞춰 판단하고, 가져오기·백필 같은 비정상 경로도 동일 규칙을 지키게 합니다.

다른 파티션에 동시에 같은 ID 삽입, 날짜 수정으로 이동, 지연 데이터·복구를 시험합니다. 전역 등록 지점은 병목·원자성 경계가 될 수 있어 비용을 측정합니다. 파티션 관리 편의 때문에 원래 유일성 규칙을 몰래 약화하지 않는 것이 중요합니다.