DynamoDB M-M隣接リストデザインパターン

Question

https://docs.aws.Amazon.com/amazondynamodb/latest/developerguide/bp-adjacency-graphs.html を参照します。誰かが私を助けることができるかどうか疑問に思っていました。

最初の画像はテーブルのもので、2番目の画像はGSIです。表は次のとおりです。

テーブルで、ソートキーを作成する方法がわかりませんか？これはBill-IDとInvoice-IDの両方を格納する1つの属性ですか？または2つの別々の属性？私はそれが1つの柔軟な属性であると感じていますが、そうであれば、どのように1つを他と区別しますか？そして、ソートキーでクエリを作成する方法は何ですか？

接頭辞「Bill-」または「Invoice-」を見ているだけですか？ DynamoDBの実践では、ダッシュ（ "-"）を使用して属性の値を分離しているようです。誰かがそのようなことのユースケースを私に与えることができれば、私も感謝しますが、この場合重要でない限り、私は接線を離れます。

今、これは非常に関連性があり、非常に興味深いです https://youtu.be/xV-As-sYKyg?t=1897 、プレゼンターはONEを使用していますさまざまな種類のアイテムを保存する製品テーブル：書籍、歌のアルバム、映画。それぞれに独自の属性があります。

繰り返しますが、そこで使用されるソートキーの理解に問題があります。 productID = 1はbookIDであり、productID = 2はアルバムであることを理解しています。今混乱するところは、赤で囲んだものです。これらはアルバム2のトラックです。ただし、ソートキーの構造は「albumID：trackID」です。さて、「trackID」はどこにありますか？ Wordの「trackID」を実際のIDに置き換えることを意図していますか？または、これは「albumID：trackID」とまったく同じテキストであることを意図していますか？.

特定のtrackIDを照会する場合はどうなりますか？私のクエリの構文は何ですか？

YouTubeの画像をご覧ください：

よろしくお願いします!!! :-)

F_SO_K · Answer

最初の写真では、base table（primary key）のアイテムを投稿しましたが、このようになります

First_id(Partition key) Second_id(Sort Key) Dated ------------- ---------- ------ Invoice-92551 Invoice-92551 2018-02-07 Invoice-92551 Bill-4224663 2017-12-03 Invoice-92551 Bill-4224687 2018-01-09 Invoice-92552 Invoice-92552 2018-03-04 Invoice-92552 Bill-4224687 2018-01-09

[〜＃〜] gsi [〜＃〜]の同じアイテムは、アイテムは次のようになります。

Second_id(Partition Key) First_id ---------- --------------- Invoice-92551 Invoice-92551 Bill-4224663 Invoice-92551 Bill-4224687 Invoice-92551 Invoice-92552 Invoice-92552 Bill-4224687 Invoice-92552

彼らはかなり紛らわしい方法でそれを描きました。

パーティションキーは1つのボックスにマージされていますが、別々のアイテムです。
彼らはまた、同じ写真にGSIを表示しようとしました。基本テーブルとGSIは、多くの点で同期が保たれている2つの独立したテーブルと考えることができます。
実際には、キー属性に名前を付けていません。私の例では、First_idとSecond_idという名前を付けています。

ベーステーブルでクエリを実行する場合、パーティションキーInvoice-92551そして、請求書アイテムとそれに属するすべての請求書アイテムの両方を取得します。

請求書を表示していると想像してくださいInvoice-92551アプリケーションで、2つの請求書が関連付けられていることがわかります（Bill-4224663およびBill-4224687）。請求書をクリックすると、アプリケーションはおそらくGSIでクエリを実行します。 GSIクエリにはパーティションキーBill-4224687。上記のGSIテーブルを見ると、2つのアイテムが返され、Bill-4224687は2つの請求書の一部です（Invoice-92551およびInvoice-92552）

2番目の図では、「bookID」や「albumID」などの単語は実際のIDを表していると想定されています（293847および3340876と言います）。

彼の例を次のように描きます。

ProductID(Partition Key) TypeID(Sort Key) Title Name --------- ------ ------ ------ Album1 Album1 Dark Side Album1 Album1:Track1 Speak to me Album1 Album1:Track2 Breathe Movie8 Movie8 Idiocracy Movie8 Movie8:Actor1 Luke Wilson Movie8 Movie8:Actor2 Maya Rudolph

クエリは次のとおりです。

Partition key: Album1

アルバム1（ダークサイド）のすべての情報（トラックを含む）を提供します

Partition key: Album1 and Sort Key: Album1:Track2

呼吸に関する情報のみを提供します。

Partition key: Movie8

Movie8（Idiocracy）に関するすべての情報（俳優）を提供します

テーブルを作成する場合、Movie、Albumなどの単語が実際のID（Movie018274やAlbum983745987など）の一部になるようにしますが、それは必須ではなく、IDを人間が読みやすくするだけです。

mixja · Answer

Stuの答えはまったく正しくありません。テーブルは実際には図のように見えます。

First_id(Partition key) Second_id(Sort Key) Dated ------------- ---------- ------ Invoice-92551 Invoice-92551 2018-02-07 Invoice-92551 Bill-4224663 2017-12-03 Invoice-92551 Bill-4224687 2018-01-09 Invoice-92552 Invoice-92552 2018-03-04 Invoice-92552 Bill-4224687 2018-01-09 Bill-4224663 Bill-4224663 2018-12-03 Bill-4224687 Bill-4224687 2018-01-09

上の表では、Billアイテム（パーティションキー= Bill-xxxxx）が請求書の共通情報を保持しています。Billアイテムをソートキーとして持つInvoiceアイテムは、特定の請求書に固有の請求書の情報を保持しています。

請求書を完全に再構築するには、請求書の完全な情報（つまり、共通レコード+請求書固有のレコード）を検索できるGSIが必要です。

Second_id(Partition Key) First_id Data ---------- --------------- ----------- Bill-4224663 Bill-4224663 Common bill data Bill-4224663 Invoice-92551 Bill data for Invoice-92551 Bill-4224687 Bill-4224687 Common bill data Bill-4224687 Invoice-92551 Bill data for Invoice-92551 Bill-4224687 Invoice-92552 Bill data for Invoice-92552 Invoice-92551 Invoice-92551 Redundant data! Invoice-92552 Invoice-92552 Redundant data!