埋もれたパーティションから読み取らないようにします。商品の取引に関する情報を持つテーブルを考えてみましょう。ブラック・フライデーやサイバー・マンデーのような大規模なセールス・イベントでは、セール対象の商品は、他の商品よりも多くのアクセスが予想されます。書き込みの多いユースケースの場合は、あらかじめ決められた範囲の乱数/数字を追加します。パーティションキーに大量の書き込みが必要な場合は、プレフィックスやサフィックス(あらかじめ指定された範囲の固定数、たとえば1〜10)を使用して、パーティションキーに追加します。請求書トランザクションのテーブルを考えてみましょう。単一の請求書には、クライアントごとに数千のトランザクションが含まれることがあります。大規模なクライアントの請求書の詳細を照会/更新する場合の一意性と能力をどのように担保すれば良いでしょうか。このシナリオで推奨されるテーブルレイアウトは以下のとおりです。01.36.15この組み合わせにより、各パーティションを有効利用できます。10回のクエリを行う必要があります。始まるという条件でクエリをかける必要があります。繰り返し、結果をマージする必要があります。一部(曜日、月、年(DDMMYYYY)など)を追加して書き込みに際してのパーティションの有効活用ができます。ClientTransactionidがClient1で始まるという条件で、30回クエリを発行する必要があります。アクセスパターンとして、特定の日付の請求書を確認する場合は、パーティションキーを使用して直接照会することができます。その後、その範囲の拡張することは容易ではありません。いうのも、プレフィックスの変更はアプリケーションレベルでの変更が必要になるからです。それゆえ、予期される将来の成長に対応するために、各パーティションキーがどの程度ホットになり、(バッファも含めて)十分なランダムプレフィックスをつけるよう検討しましょう。X回の読み込みリクエストが発生するので、読み込みに追加のレイテンシーがかかります。大小のユースケースごとにテーブルを分割する。ある場合は、パーティションキーに乱数を使用するのが効果的です。Itemが混在している場合はどうなるでしょうか?たとえば、パーティションキーごとに数万のアイテムを持つ顧客/製品が1つあり、パーティションキーごとにわずか数のアイテムを持つ顧客がある場合はどうなるでしょう?このシナリオでは、小さなプレフィックスを使用することは、小規模な顧客にとって効果的ではありません。テーブルを考えてみましょう。クライアントの情報を事前に知っていて、その規模感を分類できるものとします。10,000件の取引があります。その場合、以下のようにテーブルを分割するアプローチが推奨されます。ClientTransactionidこの場合、ランダムプレフィックスはクライアントごとに数万の請求取引が予想される大きいテーブルにだけ適用すればよいでしょう。コールを必要ありません。パーティションキーとして使用する。利用して、一意性を確保しようとするのはよくあることです。これらはデータアクセスには利用されません。DynamoDBに移行された注文テーブルのスキーマレイアウトの例です。メインテーブルのパーティションキー(TransactionID)にはUIDが設定されます。クエリを実行するため、OrderIDとOrder_Dateにグローバルセカンダリインデックス(GSI)が作成しています。クエリの目的で利用することができません。したがって、データの高速な読み取りのためにパーティションキーを使う能力を失っています。結果整合性のみをサポートし、読み込みと書き込みに追加のコストが発生します。上書きを防止するために条件付き書き込みを利用できます。パーティションキー(例.product_code)やソートキー(例.order_date)として利用する。この設計により、ホットパーティションとなる可能性が大幅に高まります。ある製品が非常に人気がある場合、そのキーの読み込みと書き込みが高くなり、スロットリングの問題が発生します。API操作では、テーブル、GSIのパーティションキーに等価演算子(EQ)が必要です。MBという制限があります。LastEvaluatedKeyを使用したイテレートアクセスが必要となってしまいます。DynamoDBに格納する前にcustomer_idのようなキーに対して独自にハッシュ化しないでください。DynamoDBはキーをハッシュし、パーティション間で配布します。ダブルハッシングは、単にお客様のアプリケーション設計を複雑にするだけです。DynamoDBテーブルのデータモデルとアクセスパターンを分析せずに、移行元のデータベースからプライマリキーをそのまま持ってくることは避けましょう。パーティションキー戦略を考えるにあたって、すべてのユースケースにあてはまる唯一のソリューションはありません。格納したデータとアクセスパターンに基づいて、様々なアプローチを検証すべきです。スロットリングを起こす可能性が最も小さい適切なキーを選択してください。Facebookこのブログの最新情報はTwitter、Facebookでもお知らせしています。お気軽にフォローください。