DynamoDBテーブルのセカンダリグローバルインデックスを最適化して、すべてのレコードをソート可能にしたままレコードを均等に分散させる方法を教えてください。

Question

this questionに関連する、より具体的な答えを探しています。これを非主観的に保つために、ここでは、簡単な例の回答で終わることができる固執点を持つ活動表を作成するための完全な思考プロセスがあります。

DynamoDBをよりよく理解するために、私はDynamoDBテーブルからのアクティビティフィードを含む個人用Webサイトを作成しています。目標はパーティションキーを均等に分散しながら、すべてのパーティションキーをソートできるようにすることです（私はこの部分で苦労しています）。

ブログの投稿、プロジェクト、twitter投稿の参照、LinkedInの投稿の参照など、さまざまな種類のアクティビティが含まれます。アクティビティタイプをパーティションキーとして使用することは、ブログ投稿を作成することはほとんどありません。

DynamoDBパーティション間でアクティビティを均等に分散させるために、一意のアクティビティIDが最適なオプションのようです。しかし、これは、クエリが最初にパーティションIDを知っている必要があるため、アクティビティを開始するためのソート機能を完全に削除します。これはセカンダリグローバルインデックス（SGI）が役立つところです。これにより、ソートキーはプライマリパーティションキーでは必要なくなりますが、SGIでペアになります。

これは私が立ち往生している部分です。 SGIパーティションキーの基礎は何ですか？現時点では、「日付」のソートキーを持つすべてのアクティビティの単一の値「アクティビティ」を考えていますが、それはすべてのエントリの単一のパーティションです。 単一のSGIパーティションキーの値でこのプロジェクトのパフォーマンスが制限されますか？

これは小規模なプロジェクトです。しかし、私は大規模プロジェクトについて考えています。これを構築し、すべてのテーブルレコードを柔軟にソートできるように、最適化されたパーティション分配に関して最高のDynamoDBテーブルを作成しようとしています。

Answer 1

スキーマを設計する際にメインテーブルのインデックスと同じGSI（グローバルセカンダリインデックス）を検討すると、読み取り/書き込みのプロビジョニングの制限があり、ホットパーティションの制限も受けます。あなたのメインテーブルが要求の絞り込みを開始します。

単一のSGIパーティションキーの値でこのプロジェクトのパフォーマンスが制限されますか。

完全なテーブルの単一パーティションは、間違いなくDDBスケーラブル機能の誤用です。

目標は、すべてのパーティションキーを並べ替えることができるうちにパーティションキーを均等に分散することです（私はこの部分で苦労しています）。

GSIを使用してパーティションを並べ替えることはできますが、GSIのパーティションキーが必要になります。そのパーティションキーが十分に分散されていない場合は、上記の問題が発生します。

DDBは、モデル化された場合はput/get操作に、いくつかのフィルタではかなり単純なクエリの場合は強力です。一般に、テーブル内のパーティションキー値の合計数にアクセスされたパーティションキー値の比率が増加するにつれ、より効率的にスループットを利用します。あなたの特定のために

DDBからスケーラブルなソリューションを取得するために直接ことができ、その必要はありませんが、我々はまだいくつかのオプションに

オプション1持っている：

を私たちは、それはかなりの書き込みのために配布されるようなデータをモデル化することができますそれを読んでいる間に余分な作業が必要になると、このパターンは複数のパーティションキー値の間でランダム化とも呼ばれます。指定した時間に特定のアイテムにアクセスしたくないので、これは私たちのために機能します。

アイデアは固定されたセット（たとえば1〜100）を作成し、そこからランダムに番号を選択して作成日（タイムスタンプではない）に追加し、作成タイムスタンプをソートキーとして使用します。

これにより、複数のランダムなパーティションに負荷が分散されますが、すべてのパーティションを照会してその日付の最終的なソート・ビューを取得する必要があるため、読み取りの複雑さが増します。

オプション2：

使用ホットとコールドデータのための複数のテーブルには、時系列に基づくデータであるとして。

スキャン：情報について http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GuidelinesForTables.html#GuidelinesForTables.TimeSeriesDataAccessPatterns

オプション3をお読みになりましたか？スケーラビリティーとデータの拡大について話をするのであれば、良い選択ではありませんが、データのほんの僅かなセットについて言えば、それに言及するのには間違いありません。

これらは、あなたの使用目的に適した例ではありません。 ここでは、あなたの思考プロセスの質問です：すべてのユースケースとアクセスパターンを書き留めます。最終的な一貫性とは無縁であり、DDBが最初の場所に適しているかどうかを確認し、DDBを使用してアクセスパターンのスケーラビリティに悩まされないようにしてください。

さらに詳しい質問はhttps://stackoverflow.com/a/38790120/962545を参照してください.DDBから必要なアクセスパターンを自分で制限する前に、あなた自身が尋ねる必要があります。

ベストプラクティスを読むことを忘れないでください。http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GuidelinesForTables.html