# パーティションキーを設計してワークロードを DynamoDB で分散する テーブルの主キーのパーティションキー部分は、テーブルのデータが格納されている論理パーティションを決定します。これにより、基本的な物理パーティションに影響を及ぼします。I/O リクエストを効率的に分散しないパーティションキー設計では、「ホット」パーティションが作成される場合があります。これにより、スロットリングが発生することや、プロビジョニングされた I/O 容量が効率的に使用されないことがあります。 テーブルのプロビジョニングされたスループットの最適な使用は、個々の項目のワークロードパターンだけでなく、パーティションキー設計にも左右されます。この操作によって、スループットレベルを達成するためにすべてのパーティションキーバリューにアクセスしたり、アクセスされるパーティションキーバリューの割合を高くしたりする必要があるわけではありません。これは、ワークロードがアクセスするパーティションキーバリューが大きくなるほど、リクエストが分割された空間に分散されることを意味します。一般的に、パーティションキー値の総数に対するアクセスされたパーティションキー値の比率が高くなるほど、プロビジョンドスループットの使用がより効率的になります。 一般的なパーティションキースキーマのプロビジョニングされたスループット効率の比較を次に示します。 **** | パーティションキーバリュー | 均一性 | | --- | --- | | ユーザー ID (アプリケーションに多くのユーザーが存在する場合) | 良好 | | ステータスコード (可能性のあるステータスコードが少しだけある場合) | 不良 | | 項目の作成日。直近の期間 (日、時、分など) に切り上げられます。 | 不良 | | デバイス ID (各デバイスが比較的類似した間隔でデータにアクセスする場合)。 | 良好 | | デバイス ID (追跡中のデバイスが多数あり、そのうちの 1 つのデバイスが他のすべてのデバイスよりも頻繁に使用される場合) | 不良 | 単一のテーブル内にあるパーティションキーバリューの数が少ない場合は、より明確に区別できるパーティションキーバリュー全体を対象として、書き込みオペレーションを分散することを検討してください。つまり、「ホット」パーティションキーバリュー (何度もリクエストされるパーティションキーバリュー) が原因で全体のパフォーマンス速度が低下する場合があるので、このようなパーティションキーバリューを回避するようにプライマリキー要素を構築してください。 例えば、複合プライマリキーを持つテーブルがあるとします。パーティションキーは項目の作成日を表します (直近の日付に切り上げられます)。ソートキーは項目の識別子を表します。特定の日付 (`2014-07-09` など) で、**すべて**の新しい項目が 1 つのパーティションキーバリュー (およびその物理パーティション) として書き込まれます。 テーブル全体が単一のパーティションに収まり (時間の経過に伴うデータの増加を考慮)、アプリケーションで必要となる読み込みスループットと書き込みスループットが単一のパーティションにおける読み込みと書き込みの容量を超過しない場合は、パーティション分割をしても、アプリケーションが予想外のスロットリングを受けることはありません。 NoSQL Workbench for DynamoDB を使用してパーティションキー設計を視覚化する方法については、「[NoSQL Workbench を使用したデータモデルの構築](workbench.Modeler.md)」を参照してください。