10

DynamoDB の新機能。

主キー「UserID」、複合キー「DateTime」を使用してテーブルを作成しています。値として次のものがあります（注：以下のデータの詳細を照会する必要はありません-書き込みと読み取りだけです） :

UserID1
UserID2
Message
DateTime

質問:

  1. これらの 4 つの値を個別の項目として、または 1 つの JSON 文字列として保存する利点はありますか?
  2. 保存された値の UserID1 と Datetime もプライマリ/複合キーを構成します-クエリ時に返されたキーからアクセスできるため、これらをデータ/値に保存しても意味がないと思いますか?
4

6 に答える 6

8

したがって、オプションは次のとおりです。

Hash Key | Range Key  | Attributes
----------------------------------
user id  | utc time   | json data
----------------------------------
user123  | 1357306017 | {UserID1:0, UserID2:0, Message:"", DateTime:0}

また

Hash Key | Range Key  | Attributes
--------------------------------------------------------------
user id  | utc time   | UserID1 | UserID2 | Message | DateTime
--------------------------------------------------------------
user123  | 1357306017 | 0       | 0       | ""      | 0

どちらも実行可能なオプションであり、選択はデータの読み取り方法に帰着します。各アイテムの属性がある場合は、それらの属性を個別に要求できます。

私たちは、使用パターンに基づいてハイブリッド アプローチを使用する傾向があります。個別にアクセスする必要がある要素には、独自の属性が与えられます。他の要素のコレクションと一緒にアクセスしたいだけの要素には、すべて単一の属性が割り当てられ、JSON 文字列または base64 でエンコードされたデータの単一のブロブとして保存されます。

パート 2 については、確かにそのとおりです。ユーザー ID と日時を属性の一部として再度保存する必要はありません。これらは、リクエストを行ったときに返されるハッシュ キーと範囲キーであるためです。

于 2013-01-04T12:35:38.373 に答える
3

  1. 「個別のアイテム」とは「個別の属性」を意味すると思いますが、その場合は問題ありません。属性のサブセットを取得できるため、おそらくそれらを個別の属性として保存します（ただし、この機能は今は必要ないと言っていますが）。将来、ユーザーが送信したメッセージの数を確認したいが、低速のネットワークが何 KB ものメッセージを返すのを待ちたくない場合は、個別の属性を使用すると便利です。

  2. はい。

于 2012-12-31T06:53:23.057 に答える
3

DynamoDB は、json オブジェクトの直接保存をサポートするようになりました。読む: http://aws.amazon.com/blogs/aws/dynamodb-update-json-and-more/

于 2014-10-09T07:09:02.193 に答える
2

いつでもデータを JSON として保存し、簡単にクエリを実行できます。

{
  sequence: "number",
  UserID1: "id",
  UserID2: "id",
  Message: "message text",
  DateTime: "1234567890"
}

あなたの目的はある種のメッセージングシステムだと思います。この場合、UserID1 と UserID2 をハッシュ キーにすることはできません。これは、明らかに重複したエントリがあるためです (たとえば、UserID1 には複数のメッセージがあります)。

ある種のセッションIDであるインデックスを持つことができます。

次に、構造の [DateTime] 部分にセカンダリ インデックスを作成して、特定のタイム スタンプよりも古いセッションのメッセージをクエリできるようにします。

于 2015-07-02T18:38:15.453 に答える