amazon-web-services - AWS Amplify - AppSync 和多个 DynamoDB 表

Question

当initializing a new GraphQL backend via the Amplify CLI ，示例模式使用 @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 表(每个模型一个)。因此，在此示例中，创建了三个单独的 DynamoDB 表(博客、帖子和评论)

在我们的例子中，我们有一个 Users模型，我们将有二十个左右的小集合与用户相关联。当感觉这些小集合都属于单个表中的 User 对象时，我对必须管理 20 个不同的 DynamoDB 表感到不安。

从我阅读的所有内容来看，AppSync 似乎在鼓励使用多个表。例如， 备注 在下面来自 AWS AppSync 文档的屏幕截图中，特别指出博客评论应该放在生产环境中的单独表格中。



这与 DynamoDB documentation 中列出的最佳实践相矛盾。 :

You should maintain as few tables as possible in a DynamoDB application. Most well designed applications require only one table.

当使用 AppSync 时，每种类型都属于单独的 DynamoDB 表，真的是这样吗？

Answer 1

正如您所提到的，DynamoDB 文档建议“大多数设计良好的应用程序只需要一个表”。当开发人员随着时间的推移了解了他们的数据访问模式、确定了数据模型并且有一定的规模要求需要优化时，这对许多应用程序都是有效的。许多开发人员从第一天起就对他们的应用程序没有这种程度的理解，或者不一定是相同的要求。此外，关于单表设计的演示文稿中提到的一些要点(例如，存储成本与计算之间的权衡)可能会根据您的应用程序而变得主观。

当您正在构建一个新应用程序或不了解您的数据访问模式时，使用单表设计模式的好处会逐渐减少，而多表策略则更加灵活。

AWS amplify 是一个固执己见的客户端框架，为具有不同规模和复杂性的开发人员提供合理的默认设置，因此它在以最基本的形式利用 @model 转换器时采用了多表策略。随着您的需求不断发展，您可以通过使用 Transformer 的附加功能来扩充此设计，例如 @key (用于创建单表索引和复合键)甚至是来自 DynamoDB 的全文搜索和流式传输，使用 @searchable .

我们确实认识到大型或成熟的应用程序可能会受益于单表方法。从多个表转到单个表可能是一次性的“合并”操作，在原型(prototype)设计阶段之后，并且当开发人员已经理解了数据访问模式时。实际上，没有“一刀切的方法”，这就是为什么 Amplify 的 GraphQL Transformer 会根据您的应用程序在其发展中所处的位置为您提供不同级别的灵 active 。

正如 Luis 在另一个答案中提到的那样:AWS AppSync 确实支持独立于 GraphQL Transformer 生成模式的任何类型的表结构。即使您确实有多个表，您也可以使用 schema design 在单个客户端请求中轻松实现 GraphQL 关系模式。 , nested resolvers ，甚至实现Pipeline resolvers .

(此回复在 Richard 的帮助下进行了编辑)