AWS Amplify - AppSync和多个DynamoDB表

Question

通过 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表（每个模型一个）。因此，在此示例中，创建了三个单独的DynamoDB表（Blogs、Posts和Comments）。

在我们的情况下，我们有一个“Users”模型，我们将与用户关联二十个左右的小集合。当这些小集合感觉都属于单个表中的用户对象时，我对不得不管理二十个不同的DynamoDB表感到不安。

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

这与DynamoDB文档中规定的最佳实践相矛盾：

在DynamoDB应用程序中，您应该尽可能少地维护表。大多数设计良好的应用程序只需要一个表。

使用AppSync时，每种类型都应该放在单独的DynamoDB表中吗？

- Kyle Magilavy

Answer 1

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

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

AWS Amplify是一个基于意见的客户端框架，为具有不同规模和复杂性水平的开发人员提供合理的默认值，因此在其最基本形式中使用@model变压器时采用了多表策略。随着您的要求发展，您可以通过使用Transformer的其他功能（例如@key（用于创建单个表索引和复合键）甚至全文搜索和从DynamoDB流式传输@searchable）来增强此设计。

我们确实认识到大规模或成熟的应用程序可能受益于单表方法。从多个表格转换为单个表格可能是一次“合并”操作，即在原型设计阶段之后，并且开发人员已经理解了数据访问模式。实际上，并没有“一种尺寸适合所有方法”，这就是为什么Amplify的GraphQL变压器根据应用程序演变的不同阶段给您提供不同级别的灵活性。

正如Luis在另一个答案中提到的那样：AWS AppSync支持任何类型的表结构，独立于GraphQL Transformer生成模式。即使您有多个表，您也可以使用schema设计、嵌套解析器或甚至实现管道解析器，在单个客户端请求中轻松实现GraphQL关系模式。

（此响应是在Richard的帮助下编辑的）

- Sébastien Stormacq

Answer 2

使用AppSync时，每种类型是否真的需要放在单独的DynamoDB表中？

不需要，您可以使用单个表来存储服务所需的不同类型（或实体）。只要您为将在服务中使用的数据定义了明确的访问模式，您可能只需使用一个表就可以胜任。但是，这种方法可能有点不灵活，因为您必须事先考虑您的访问模式，并且以后可能很难添加新的访问模式。

目前无法利用Amplify中的@model指令进行此类配置。您必须手动创建表，然后为每个Appsync类型设置相应的解析器，以便查询/变异。

这是一篇很好的文章，其中解释了这种方法：从关系型数据库到单个DynamoDB表：逐步探索

- Luis Felipe Llamas