【问题标题】:AWS Amplify - AppSync & Multiple DynamoDB TablesAWS Amplify - AppSync 和多个 DynamoDB 表
【发布时间】:2019-10-19 09:14:57
【问题描述】:

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 文档的屏幕截图中的 Note 明确指出,博客 cmets 应在生产环境中放入单独的表中。

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

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

当使用 AppSync 时,每种类型是否都属于单独的 DynamoDB 表?

【问题讨论】:

    标签: amazon-web-services amazon-dynamodb graphql aws-amplify aws-appsync


    【解决方案1】:

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

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

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

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

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

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

    【讨论】:

      【解决方案2】:

      当使用 AppSync 时,每种类型是否都属于单独的 DynamoDB 表?

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

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

      这是一篇很好的文章,解释了这种方法: From relational DB to single DynamoDB table: a step-by-step exploration

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2018-10-27
        • 1970-01-01
        • 2018-12-15
        • 2021-03-21
        • 2018-08-19
        • 1970-01-01
        • 2018-06-23
        • 2020-08-30
        相关资源
        最近更新 更多