# DynamoDB에서 효과적으로 파티션 키를 설계해 사용하는 모범 사례입니다.
<a name="bp-partition-key-design"></a>

Amazon DynamoDB 테이블에서 각 항목을 고유하게 식별하는 기본 키는 간단하거나(파티션 키만) 복합적일(정렬 키가 통합된 파티션 키) 수 있습니다.

테이블과 보조 인덱스의 모든 파티션 키에서 균일하게 활동을 하도록 애플리케이션을 설계해야 합니다. 애플리케이션에 필요한 액세스 패턴을 결정하고, 각 테이블 및 보조 인덱스에 필요한 읽기 및 쓰기 유닛을 결정할 수 있습니다.

**참고**  
조정 용량은 온디맨드 모드 및 프로비저닝된 용량에 적용됩니다.

DynamoDB 테이블의 모든 파티션은 초당 3,000회의 읽기 단위 및 초당 1,000회의 쓰기 단위의 최대 용량을 제공하도록 설계되었습니다. 읽기 단위 1은 초당 강력히 일관된 읽기 1 또는 초당 최종적으로 일관된 읽기 2(최대 4KB 크기 항목의 경우)를 나타냅니다. 쓰기 단위 1은 최대 1KB 크기의 항목에 대해 초당 1회 쓰기 작업을 나타냅니다.

테이블의 파티션 처리량 한도를 평가할 때는 항목 크기를 고려해야 합니다. 예를 들어 테이블의 항목 크기가 20KB인 경우 일관된 단일 읽기 작업에는 읽기 단위 5가 사용됩니다. 즉, 파티션 한도에 도달하기 전에 해당 단일 항목에 대해 초당 600회의 일관된 읽기 작업을 동시에 실행할 수 있습니다. 테이블의 모든 파티션에 걸친 총 처리량은 프로비저닝된 모드의 프로비저닝된 처리량 또는 온디맨드 모드의 테이블 수준 처리량 한도에 의해 제한될 수 있습니다. 자세한 내용은 [Service Quotas](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ServiceQuotas.html)를 참조하세요.

**Topics**
+ [DynamoDB에 워크로드가 배포되도록 파티션 키 설계](bp-partition-key-uniform-load.md)
+ [쓰기 샤딩을 사용해 DynamoDB 테이블에 워크로드를 고르게 배포](bp-partition-key-sharding.md)
+ [DynamoDB에 데이터 업로드 중 효율적으로 쓰기 활동 배포](bp-partition-key-data-upload.md)

# DynamoDB에 워크로드가 배포되도록 파티션 키 설계
<a name="bp-partition-key-uniform-load"></a>

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

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

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


****  

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

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

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

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

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

# 쓰기 샤딩을 사용해 DynamoDB 테이블에 워크로드를 고르게 배포
<a name="bp-partition-key-sharding"></a>

Amazon DynamoDB의 파티션 키 공간에 더 효과적으로 쓰기 작업을 배포하는 방법 중 하나는 공간 확장입니다. 여러 방법을 사용할 수 있습니다. 파티션 키 값에 난수를 추가하여 여러 파티션으로 항목을 배포할 수 있습니다. 또는 쿼리하는 항목을 기반으로 계산된 숫자를 사용할 수 있습니다.

## 임의의 접미사를 사용하는 샤딩
<a name="bp-partition-key-sharding-random"></a>

여러 파티션 키 공간에 로드를 더 골고루 배포할 수 있는 전략 중 하나는 파티션 키 값 끝에 난수(임의의 수)를 추가하는 것입니다. 그러면 더 큰 공간으로 쓰기를 무작위화 할 수 있습니다.

예를 들어, 오늘 날짜를 나타내는 파티션 키의 경우, `1`부터 `200` 사이의 난수를 선택하고, 날짜의 접미사로 연결시킬 수 있습니다. 이는 `2014-07-09.1`, `2014-07-09.2`에서 `2014-07-09.200`까지의 파티션 키 값을 생성합니다. 파티션 키를 임의 지정했기 때문에, 각 날짜의 테이블에 대한 쓰기가 모든 파티션 키 값에 고르게 분산됩니다. 이는 병렬 처리를 개선하고 전반적인 처리량을 높입니다.

하지만 지정된 날짜의 모든 항목을 읽으려면, 모든 접미사의 항목을 쿼리해 결과를 병합해야 합니다. 예를 들어 먼저 파티션 키 값 `Query`에 대한 `2014-07-09.1` 요청을 생성합니다. 그런 다음 `Query`에서 `2014-07-09.2`까지에 대해 또 다른 `2014-07-09.200` 요청을 생성합니다. 마지막으로 애플리케이션은 모든 `Query` 요청 결과를 병합해야 합니다.

## 계산한 접미사를 사용하는 샤딩
<a name="bp-partition-key-sharding-calculated"></a>

임의 지정 전략으로 쓰기 처리량을 크게 향상시킬 수 있습니다. 그러나 특정 항목을 쓸 때 어떤 접미사 값이 사용되었는지 모르기 때문에 해당 항목을 읽기 어렵습니다. 개별 항목을 더 쉽게 읽을 수 있도록 만들려면 다른 전략을 사용합니다. 난수(임의의 수)를 사용해 여러 파티션으로 항목을 배포하는 대신, 쿼리하고 싶은 내용을 토대로 계산할 수 있는 수를 사용합니다.

테이블의 파티션 키에 오늘 날짜를 사용한 앞의 예를 가정하겠습니다. 이제 각 항목에 액세스가 가능한 `OrderId` 속성이 있고, 날짜에 더해 주문 ID로 항목을 찾아야 하는 경우가 많다고 가정하겠습니다. 애플리케이션이 테이블에 항목을 쓰기 전에 주문 ID를 기준으로 해시 접미사를 계산하고 파티션 키 날짜에 추가할 수 있습니다. 계산 결과 임의 지정 전략에서 생산되는 결과와 유사하게 골고루 배포된 1-200 사이의 숫자가 생성될 것입니다.

주문 ID의 문자에 대한 UTF-8 코드 포인트 값의 제품이나 모듈로 200 \$1 1과 같이 간단한 계산으로 충분합니다. 파티션 키 값은 계산 결과와 연결된 날짜가 됩니다.

이러한 전략을 통해 쓰기가 파티션-키 값 및 물리적 파티션에 고르게 분산됩니다. 특정 항목과 날짜에서 `GetItem` 작업을 손쉽게 수행할 수 있습니다. 특정 `OrderId` 값에 대한 파티션-키 값을 계산할 수 있기 때문입니다.

지정된 날의 모든 항목을 읽으려면 각 `2014-07-09.N`(여기서 `N`은 1\$1200) 키를 `Query`해야 하며, 애플리케이션은 모든 결과를 병합해야 합니다. 장점은 모든 워크로드를 취하는 하나의 '핫' 파티션 키 값이 발생하지 않도록 만든다는 것입니다.

**참고**  
볼륨이 많은 시계열 데이터를 더 효율적으로 처리할 수 있는 전략에 대한 자세한 내용은 [시계열 데이터](bp-time-series.md) 섹션을 참조하세요.

# DynamoDB에 데이터 업로드 중 효율적으로 쓰기 활동 배포
<a name="bp-partition-key-data-upload"></a>

일반적으로 다른 데이터 소스에서 데이터를 로드할 때, Amazon DynamoDB는 여러 서버의 테이블 데이터를 파티션합니다. 테이블에 데이터를 업로드할 때 할당된 모든 서버에 데이터를 동시에 업로드하면 성능이 향상됩니다.

예를 들어, `UserID`를 파티션 키로, `MessageID`를 정렬 키로 사용하는 복합 기본 키를 사용하는 DynamoDB 테이블로 사용자 메시지를 업로드하는 경우를 가정합니다.

데이터를 업로드하는 방법 중 하나는 각 사용자 별로 한 명씩 모든 메시지 항목을 업로드하는 것입니다.


****  

| UserID | MessageID | 
| --- | --- | 
| U1 | 1 | 
| U1 | 2 | 
| U1 | ... | 
| U1 | ... 최대 100 | 
| U2 | 1 | 
| U2 | 2 | 
| U2 | ... | 
| U2 | ... 최대 200 | 

이 경우 문제는 DynamoDB에 대한 쓰기 요청을 파티션 키 값에 분산하지 못한다는 것입니다. 한 번에 파티션 키 값 하나를 취하고 모든 항목을 업로드한 후 다음 파티션 값에서 동일한 작업을 반복합니다.

표시되지는 않지만 DynamoDB는 테이블의 데이터를 여러 서버에 분할합니다. 테이블에 대해 프로비저닝된 모든 처리량 용량을 완전히 활용하려면 워크로드를 파티션 키 값에 분산해야 합니다. 이 경우 불균일한 업로드 작업 양을 파티션 키 값이 모두 동일한 항목으로 전달하면 DynamoDB가 테이블에 대해 프로비저닝한 모든 리소스를 완전히 활용하지 못할 수 있습니다.

정렬 키를 사용하여 업로드 작업을 배포, 각 파티션 키 값으로부터 하나 씩 항목을 로드할 수 있습니다.


****  

| UserID | MessageID | 
| --- | --- | 
| U1 | 1 | 
| U2 | 1 | 
| U3 | 1 | 
| ... | ... | 
| U1 | 2 | 
| U2 | 2 | 
| U3 | 2 | 
| ... | ... | 

이 시퀀스에서 모든 업로드는 서로 다른 파티션 키 값을 사용하므로, 더 많은 DynamoDB 서버를 동시에 사용하도록 하여 처리량 성능을 향상합니다.