web-dev-qa-db-ja.com

AWS Amplify-AppSyncと複数のDynamoDBテーブル

Amplify CLIを介して新しいGraphQLバックエンドを初期化する の場合、サンプルスキーマは@modelアノテーションを使用して複数のタイプを定義します。例えば...

type Blog @model {
  id: ID!
  name: String!
  posts: [Post] @connection(name: "BlogPosts")
}
type Post @model {
  id: ID!
  title: String!
  blog: Blog @connection(name: "BlogPosts")
  comments: [Comment] @connection(name: "PostComments")
}
type Comment @model {
  id: ID!
  content: String
  post: Post @connection(name: "PostComments")
}

プッシュされると、複数のDynamoDBテーブル（モデルごとに1つ）が作成されます。したがって、この例では、3つの個別のDynamoDBテーブルが作成されます（ブログ、投稿、コメント）。

私たちの場合、Usersモデルがあり、ユーザーに関連付けられた20個程度の小さなコレクションがあります。これらの小さなコレクションがすべて1つのテーブルのUserオブジェクトに属しているように感じるとき、私は20の異なるDynamoDBテーブルを管理する必要があることに不安を感じています。

私が読んでいるすべてのものから、AppSyncは複数のテーブルの使用を奨励しているようです。たとえば、AWS AppSyncドキュメントからの以下のスクリーンショットのNoteは、ブログのコメントを本番環境の別のテーブルに入れる必要があることを明確に示しています。

enter image description here

これは、 DynamoDBのドキュメント で説明されているベストプラクティスと矛盾します。

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

AppSyncを使用するときに、各タイプが個別のDynamoDBテーブルに属しているのは本当ですか？

amazon-web-servicesamazon-dynamodbgraphqlaws-amplifyaws-appsync
8
Kyle Magilavy

あなたが述べたように、DynamoDBのドキュメントは「ほとんどの適切に設計されたアプリケーションは単一のテーブルのみを必要とする」と示唆しています。これは、開発者が時間の経過とともにデータアクセスパターンを学習し、データモデルで解決し、最適化が必要な特定のスケール要件がある場合に、多くのアプリケーションに有効です。多くの開発者は、1日目からこのレベルのアプリケーションを理解していないか、必ずしも同じ要件を満たしていません。さらに、単一テーブルの設計に関するプレゼンテーションで言及されているいくつかのポイント（ストレージコストとコンピューティングのトレードオフなど）は、アプリケーションに基づいて主観的になる場合があります。

新しいアプリを構築しているとき、またはデータアクセスパターンがわからないときは、単一​​テーブルのデザインパターンを使用するメリットが少なくなり、複数テーブルの戦略ははるかに柔軟になります。

AWS amplifyは、@ modelトランスフォーマーを最も基本的な形式で活用するときに複数のテーブル戦略を採用しているため、スケールと複雑さのレベルが異なる開発者に適切なデフォルトを提供する、意欲的なクライアントフレームワークです。要件の変化に応じて、 @ key （単一のテーブルインデックスと複合キーを作成するため）または-を使用したDynamoDBからの全文検索とストリーミングなど、Transformerの追加機能を使用して、この設計を強化できます。 @ searchable 。

大規模なアプリや成熟したアプリでは、シングルテーブルアプローチのメリットが得られることを認識しています。複数のテーブルから単一のテーブルへの移行は、プロトタイピングフェーズの後、データアクセスパターンが開発者によって理解されたときに、おそらく1回の「マージ」操作です。実際には、「1つのサイズですべてのアプローチに対応」できるものはありません。そのため、AmplifyのGraphQL Transformerは、アプリの進化の段階に応じて、さまざまなレベルの柔軟性を提供します。

Luisが別の回答で述べたように：AWS AppSyncは、GraphQL Transformerの生成パターンに関係なく、あらゆるタイプのテーブル構造をサポートします。複数のテーブルがある場合でも、 schema design 、 nested resolvers 、または---のいずれかを使用して、単一のクライアント要求でGraphQLリレーショナルパターンを簡単に実装できます パイプラインリゾルバー 。

（この応答は Richard の助けを借りて編集されました）

7
Sébastien Stormacq

AppSyncを使用するときに、各タイプが個別のDynamoDBテーブルに属しているのは本当ですか？

いいえ。1つのテーブルを使用して、サービスに必要なさまざまなタイプ（またはエンティティ）を保存できます。サービスで使用するデータのアクセスパターンが明確に定義されている限り、1つのテーブルのみを使用して問題を回避できます。ただし、事前にアクセスパターンを検討する必要があり、将来的に新しいパターンを追加するのが難しいため、このアプローチは少し柔軟性がない場合があります。

現在、Amplifyの@modelディレクティブを利用してこのような構成にする方法はありません。テーブルを手動で作成し、Appsyncタイプごとにリゾルバーを設定して、それに応じてクエリ/変更を行う必要があります。

これはアプローチを説明する良い記事です： リレーショナルDBから単一のDynamoDBテーブルへ：段階的な調査

4
Luis Felipe Llamas