パーティションキーを設計してワークロードを均等に分散する - Amazon DynamoDB

「翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。」

パーティションキーを設計してワークロードを均等に分散する

テーブルの主キーのパーティションキー部分は、テーブルのデータが格納されている論理パーティションを決定します。これにより、基本的な物理パーティションに影響を及ぼします。テーブルのプロビジョニングされた I/O キャパシティーは、これらの物理パーティション間で均等に分割されます。そのため、I/O リクエストを均等に分散しないパーティションキー設計では、「ホット」パーティションが作成される場合があります。これにより、スロットリングが発生したり、プロビジョニングされた I/O キャパシティーを効率的に使用されないことがあります。

テーブルのプロビジョニングされたスループットを最適に使用することで、個々の項目のワークロードパターンだけでなく、パーティションキー設計にも依存します。この操作によって、スループットレベルを達成するために、すべてのパーティションキー値にアクセスしたり、アクセスされるパーティションキー値の割合を高くしたりする必要があるわけではありません。これは、ワークロードがアクセスするパーティションキーの値が大きくなるほど、リクエストが分割された空間に分散されることを意味します。一般的に、パーティションキー値の合計数に対する、アクセスされたパーティションキー値の割合が大きくなるにつれて、プロビジョニングされたスループットをより効率的に使用することができます。

一般的なパーティションキースキーマのプロビジョニングされたスループット効率の比較を次に示します。

パーティションキーの値 均一性

ユーザー ID(アプリケーションに多くのユーザーがある場合)

良い

ステータスコード(可能性のあるステータスコードが少しだけある場合) 不良
項目の作成日。直近の期間 (日、時、分) に切り上げられます。 不良
デバイス ID(各デバイスが比較的類似した間隔でデータにアクセスする場合). 良い
デバイス ID (追跡中のデバイスが多数あり、そのうちの 1 つのデバイスが他のすべてのデバイスよりもずっと人気がある場合) 不良

単一のテーブル内にあるパーティションキー値の数が少ない場合は、より明確に区別できるパーティションキー値全体を対象として、書き込みオペレーションを分散するように検討してください。つまり、"ホット" パーティションキー値 (何度もリクエストされるパーティションキー値) を回避するように、プライマリキー要素を構築してください。このようなパーティションキー値が原因で、全体のパフォーマンス速度が低下する場合があります。

たとえば、複合プライマリキーを持つテーブルがあるとします。パーティションキーは項目の作成日を表します (直近の日付に切り上げられます)。ソートキーは項目の識別子を表します。特定の日付 (例: 2014-07-09) で、新しい項目がすべて、1 つのパーティションキー値 (およびその物理パーティション) として書き込まれます。

テーブル全体が単一のパーティションに収まり (時間の経過に伴うデータの増加を考慮)、アプリケーションで必要となる読み込みスループットと書き込みスループットが単一のパーティションにおける読み込みと書き込みの容量を超過しない場合は、パーティション分割をしても、アプリケーションが予想外の制限を受けることはありません。

ただし、テーブル全体が単一のパーティションには収まらないことが予想される場合は、テーブルの完全にプロビジョニングされたスループットをより多く使用できるように、アプリケーションを設計する必要があります。