워크로드가 배포되도록 파티션 키 설계

테이블 기본 키의 파티션 키 부분은 테이블의 데이터가 저장되는 논리적 파티션을 결정합니다. 이는 기본 물리적 파티션에 영향을 줍니다. I/O 요청을 효과적으로 분산시키지 않는 파티션 키 설계는 '핫' 파티션을 발생시킬 수 있으며, 이는 제한을 발생시키고 프로비저닝된 I/O 용량을 비효율적으로 사용하게 되는 문제를 초래합니다.

테이블의 프로비저닝된 처리량의 최적 사용량은 개별 항목의 워크로드 패턴과 파티션 키 설계가 결정합니다. 이는 모든 파티션 키 값에 액세스하여 효율적인 처리량 수준을 달성해야 한다는 의미는 아닙니다. 또한 액세스된 파티션 키 값의 백분율이 높아야 한다는 의미도 아닙니다. 워크로드가 액세스 하는 고유 파티션 키 값이 많을 수록 요청이 여러 파티션 공간으로 더 많이 분산된다는 의미입니다. 일반적으로 총 파티션 키 값에 액세스한 파티션 키 값의 비율이 증가할수록 처리량을 보다 효율적으로 활용할 수 있습니다.

다음은 몇몇 범용 파티션 키 스키마의 프로비저닝된 처리량 효율성을 비교한 내용입니다.

파티션 키 값	균일성
사용자 ID, 애플리케이션의 사용자가 많은 경우.	좋음
상태 코드, 가능한 상태 코드가 몇 개 없는 경우.	나쁨
항목 생성 날짜, 가장 가까운 시간(예: 날, 시, 분)으로 반올림.	나쁨
디바이스 ID, 각 디바이스가 비교적 비슷한 간격으로 데이터에 액세스하는 경우.	좋음
디바이스 ID, 추적되는 디바이스는 많지만 다른 디바이스보다 한 디바이스가 훨씬 더 인기 있는 경우.	나쁨

단일 테이블에 파티션 키 값의 수가 매우 적은 경우, 쓰기 작업을 더 많은 고유 파티션 값에 배포하는 것이 좋습니다. 다시 말해 전반적인 성능 저하를 야기하는 하나의 ‘핫’한(자주 요청되는) 파티션 키 값이 발생하지 않도록 기본 키 요소를 구성합니다.

복합 기본 키가 하나만 있는 테이블을 예로 들어 보겠습니다. 파티션 키는 항목의 생성 날짜를 나타내며 가장 가까운 날로 반올림됩니다. 정렬 키는 항목 식별자입니다. 지정된 날, 예를 들면 2014-07-09에 모든 새 항목이 동일한 파티션-키 값(및 상응하는 물리적 파티션)에 작성됩니다.

테이블이 단일 파티션에 꼭 맞으며(시간 경과에 따른 데이터 증가 고려) 애플리케이션의 읽기 및 쓰기 처리량 요구 사항이 단일 파티션의 읽기 및 쓰기 능력을 초과하지 않으면, 애플리케이션에 파티셔닝으로 인한 예상치 않은 제한(병목) 현상이 발생하지 않습니다.

DynamoDB용 NoSQL Workbench를 사용하여 파티션 키 설계를 시각화하려면 NoSQL Workbench로 데이터 모델 빌드 섹션을 참조하세요.