3

Amazon DynamoDB を使用して、アクティビティ ストリームのイベント ベースのデータを保存しています。

毎月新しいテーブルを自動的に作成し、関連する各テーブルにイベント データを格納するつもりです。このようにして、必要に応じて古いテーブルを削除するだけで古い月をすばやく取り除くことができ、より新しいテーブルへの負荷をより適切にプロビジョニングできます。

ただし、Amazon ドキュメントを読むと、ハッシュ キー自体が非常に重要であることがわかります。

プロビジョニングされたスループットは、主キーの選択と、個々の項目のワークロード パターンに依存します。データを保存するとき、Amazon DynamoDB はテーブルの項目を複数のパーティションに分割し、主にハッシュ キー要素に基づいてデータを分散します。テーブルに関連付けられたプロビジョニング済みスループットもパーティション間で均等に分割され、パーティション間でプロビジョニング済みスループットが共有されることはありません。

私はこれを理解するのに苦労しています。

したがって、上記の私の質問は、これら2つの間でどのハッシュキーが優れているかということです。

1382465533_john.doe

また：

john.doe_1382465533

上記のキーは、ユーザー ID とイベントのタイムスタンプを組み合わせたものです。

これらのテーブルのクエリ方法...

これらのテーブルには範囲キーはありません。このユース ケースでは必要ありません。

このデータは、ユーザーのアクティビティ フィードを作成するために使用されます。

イベントが発生すると、個々のアクティビティ ID がユーザーのフォロワーredisリスト (ユーザーごとに 1 つのリスト) にプッシュ (ファンアウト) されます。

したがって、ユーザーがストリームをリクエストすると、次の処理が行われます。

  1. Redisから activityid のリストを取得する
  2. activityid をループし、BatchGetItem クエリを作成して DynamoDB からプルします。

以上のことを念頭に置いて、アクティビティ テーブルでハッシュ キーを定義する最善の方法を理解する必要があります。タイムスタンプが最初か、ユーザー ID が最初です。ハッシュキーを自動的に分割するために DynamoDB が使用するロジックは何ですか?

アドバイスをよろしくお願いします。

4

1 に答える 1

4

あなたの質問によると、ハッシュキーの正確な値を使用してテーブルをクエリする必要があるため、ハッシュキーをどのように作成するかは問題ではないと言います.DynamoDBはとにかくそれを文字列として扱います. 別のことは、範囲キーを構成している場合、おそらく次のように構成することです

john.doe_1382465533

このようにテーブルを簡単にクエリできます

ハッシュ キー = なんでも、範囲キー >= john.doe_1382460000

とはいえ、次のように DynamoDB に直接統合することで、Redis アクティビティ フィードを取り除くことができるかもしれません。

ハッシュキー: ユーザー ID

範囲キー: タイムスタンプ

残りの活動データ

したがって、アクティビティを DynamoDB にプッシュし、アクティビティ ID を Redis にプッシュする代わりに、プッシュして同じ DynamoDB テーブルからクエリするだけで済みます。これがアプリケーションの残りの部分と互換性があるかどうかはわかりませんが、ここにアイデアがあります。

于 2013-10-28T22:48:49.353 に答える