通常、他のデータソースからデータをロードする場合、Amazon DynamoDB がテーブルデータを複数のサーバーでパーティション化します。割り当てられたすべてのサーバーに同時にデータをアップロードするとパフォーマンスが向上します。
例えば、パーティションキーとして UserID
とソートキーとして MessageID
を含む複合プライマリキーを使用する DynamoDB テーブルにユーザーメッセージをアップロードするとします。
データをアップロードする場合、1 つのアプローチとして、ユーザーごとにすべてのメッセージ項目を別々にアップロードできます。
UserId | MessageID |
---|---|
U1 |
1 |
U1 | 2 |
U1 | ... |
U1 | ... 最大 100 |
U2 |
1 |
U2 | 2 |
U2 | ... |
U2 | ... 最大 200 |
この場合の問題は、パーティションキーバリュー全体で DynamoDB への書き込みリクエストを分散していないことです。一度に 1 つのパーティションキーバリューを取得し、そのすべての項目をアップロードした後に、次のパーティションキーバリューに移動して同じ処理が行われます。
その裏では、DynamoDB がテーブル内のデータを複数のサーバーでパーティション化しています。テーブルにプロビジョニングされたすべてのスループットキャパシティを完全に使用するには、ワークロードをパーティションキーバリューに分散する必要があります。同じパーティションキーバリューを持つ項目に対して不均等な量のアップロード作業を指示すると、DynamoDB がテーブル用にプロビジョニングしたすべてのリソースを完全に使用することはできません。
アップロード作業を分散するには、ソートキーを使用して各パーティションキーバリューから 1 つの項目をロードし、次に各パーティションキーバリューから別の項目をロードします。
UserId | MessageID |
---|---|
U1 |
1 |
U2 | 1 |
U3 | 1 |
... | ... |
U1 |
2 |
U2 | 2 |
U3 | 2 |
... | ... |
このシーケンスの各アップロードでは、それぞれ異なるパーティションキーバリューが使用されるので、多くの DynamoDB サーバーが同時にビジー状態になり、スループットパフォーマンスが向上します。