web-dev-qa-db-ja.com

アプリケーションごとに1つのDynamoDBテーブルのみを持つようにキースキーマを設計するにはどうすればよいですか？

DynamoDBドキュメントによると： https://docs.aws.Amazon.com/amazondynamodb/latest/developerguide/bp-general-nosql-design.html

"DynamoDBアプリケーションで維持するテーブルはできるだけ少なくする必要があります。適切に設計されたアプリケーションのほとんどは、1つのテーブルのみを必要とします。"

しかし、私の経験によれば、パーティションキーの設計により、常に反対のことを実行する必要があります。

次の状況を考えてみましょう。 「admin」、「manager」、「worker」など、いくつかのユーザーロールがあります。管理者の通常のワークフローは、マネージャーデータをCRUDすることです。ここで、読み取り操作は、1つのマネージャーではなく、すべてのマネージャーリストを取得することです。マネージャーについても同じことが言えます。彼はワーカーデータをCRUDします。どちらの場合も、キーの使用シナリオは2つしかありません。

  • すべてのアイテムのリストを取得します（アイテムキーは関係ありません）
  • フルキーを使用して特定のアイテムを操作します。

当然、（ドキュメントで強調されているように）パーティションキーを均一に分散する必要があるため、ユーザーロールを選択できず、ユーザーIDを使用する必要があります。すでにパーティションキーとしてランダムなIDを持っているので、ソートキーはまったく機能しないため、ソートキーはまったく必要ありません。パーティションキーの部分だけを使用して、1人のユーザーにアクセスできます。この時点で、ユーザーIDがCUD操作の魅力のように機能していることがわかりますが、すべてのR操作について、すべてのテーブルをスキャンしてから、効果のないユーザーロールで結果をフィルター処理する必要があります。これをどのように改善できますか？当然のことながら、ユーザータイプごとに独自のテーブルを作成しましょう。次に、admin APIからマネージャーリストをスキャンし、マネージャー1からワーカーリストをスキャンします。

DynamoDBをほぼ1年間使用していますが、それでも取得できません。私にとって現実は、実際のシナリオではソートキーは決して使用できないものです（私が持っていた唯一の実際のケースは、異なるタイプの2人のユーザーに同時に属する「契約」などのアイテムにアクセスすることでした。主キーは{partion： "managerId"、sort： "userId"}で、セカンダリグローバルインデックスは{partition： "userId"、sort： "managerId"}だったので、すべての特定のマネージャー契約リストまたはすべての特定のユーザーを効果的にクエリできました。クエリに対応するマネージャーまたはユーザーIDのみを提供する契約リスト。アプローチについては、こちらのドキュメントで説明されています： https://docs.aws.Amazon.com/amazondynamodb/latest/developerguide/bp-adjacency-graphs.html ）。

コンセプトが全くわからない気がします。提供されている例で、両方のユーザータイプに1つだけのDynamoDBテーブルを使用するためのキースキーマの効果的な方法は何でしょうか？

amazon-web-servicesamazon-dynamodbdynamodb-queries
13
Arsenii Fomin

この場合に必要なのは、グローバルセカンダリインデックス（ https://docs.aws.Amazon.com/amazondynamodb/latest/developerguide/GSI.html ）であり、パーティションキーはユーザーロール。このようにして、そのUserRoleIndexを介して特定の役割を持つすべてのユーザーにクエリを実行し、ユーザーIDの並べ替えキーを使用して、その役割内の特定のユーザーを1人選び出すことができます。

または、新しいテーブルを最初から作成する場合は、インデックスが必要ない場合もあります（削除するときのユーザーの役割がわからない場合を除く）。 「複合主キー」（ https://docs.aws.Amazon.com/amazondynamodb/latest/developerguide/HowItWorks.CoreComponents.html#HowItWorks.CoreComponents.PrimaryKey ）を使用できます。キーとソートキーは、上記で提案したインデックスと同じになります。

質問で使用したのと同じ表記法を使用して、{ partition: "userRole", sort: "userId" }をお勧めします。

DynamoDBは理解しにくい場合があり、従来のSQLデータベースの方が理にかなっている場合もあります。 AWS re：Invent 2018のこのビデオは、2つの違いを理解するのに最適です： https://www.youtube.com/watch?v=HaEPXoXVf2k&feature=youtu.be 。

ただし、あなたの場合は、非常に明確なアクセスパターンがあるように見えるので、DDBが役に立ちます。

1
Yves Gurcan

あなたは次のようなスキーマを持つことができます

user_id, role, <other columns>

どこ

  • user_id =ハッシュキー
  • 役割= GSIハッシュキー

このように、GSIにクエリを実行することで、すべてのマネージャーのリストを読み取って取得できます。

[〜＃〜] gsi [〜＃〜]を使用すると、DynamoDbは別のテーブルを作成して維持するため、複数のテーブルを維持する必要はありません。

ご不明な点がありましたらお知らせください

0
dDarkLORD