AWS Amplify-AppSync&多个DynamoDB表 [英] AWS Amplify - AppSync & Multiple DynamoDB Tables

问题描述

当

这与 DynamoDB文档:

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

使用AppSync时，每种类型确实属于一个单独的DynamoDB表吗?

解决方案

正如您提到的，DynamoDB文档建议设计最完善的应用程序只需要一个表".当开发人员逐渐了解其数据访问模式，建立在数据模型上并且具有一定的规模需求需要进行优化时，这对于许多应用程序都是有效的.从第一天开始，许多开发人员就没有对他们的应用程序有这种了解，或者没有相同的要求.另外，关于单表设计的演讲中提到的一些要点(例如，存储成本与计算之间的权衡)可能会因您的应用程序而有所主观.

在构建新应用或不知道数据访问模式时，使用单表设计模式的好处会减少结果，并且多表策略更加灵活.

AWS Amplify是一个自以为是的客户端框架，可为具有不同级别的规模和复杂性的开发人员提供明智的默认设置，因此，在采用最基本形式的@model转换器时，它已采用了多表策略.随着需求的发展，您可以使用Transformer的其他功能(例如@key (用于创建单个表索引和组合键)，甚至是全文本搜索&通过 @searchable 从DynamoDB流式传输.

我们确实认识到大型或成熟的应用程序可能会受益于单表方法.在原型开发阶段之后以及开发人员已经理解了数据访问模式之后，从多个表转到单个表可能是一次合并"操作.实际上，没有一种万能的方法"，这就是Amplify的GraphQL Transformer为您提供不同级别的灵活性的原因，具体取决于您应用程序在开发过程中所处的位置.

正如Luis在另一个答案中提到的那样:AWS AppSync确实支持任何类型的表结构，而与GraphQL Transformer生成模式无关.即使您有多个表，也可以通过 Richard 的帮助下进行了编辑)

When initializing a new GraphQL backend via the Amplify CLI, the sample schema defines multiple types with the @model annotation. For example...

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")
}

When pushed, this results in the creation of multiple DynamoDB tables (one per model). So in this example, three separate DynamoDB tables are created (Blogs, Posts, and Comments)

In our case we have a Users model and we're going to have twenty or so small collections associated to the user. I feel uneasy about having to manage twenty different DynamoDB tables when it feels like these small collections all belong with the User object in a single table.

From everything I'm reading it seems like AppSync is encouraging the use of multiple tables. For example, the Note in the screenshot below from the AWS AppSync documentation specifically calls out that the blog comments should go into a separate table in a production environment.

This contradicts the best practice laid out in the DynamoDB documentation:

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

Is it truly the case that when using AppSync each type belongs in a separate DynamoDB table?

解决方案

As you mentioned, the DynamoDB documentation suggests that "most well designed applications only require a single table". This is valid for many applications when developers have learned, over the course of time, their data access patterns, settled on a data model, and have certain scale requirements that need to be optimized. Many developers do not have this level of understanding of their application from day 1 or necessarily the same requirements. Additionally some of the points mentioned in the presentations on single table design (e.g. tradeoffs between storage costs vs compute) can be subjective based on your application.

When you are building a new app or do not know your data access pattern, the benefits of using the single table design pattern has diminishing results and the multiple tables strategy is much more flexible.

AWS amplify is an opinionated client framework providing sensible defaults for developers who have different levels of scale and complexity, as such it has adopted a multiple table strategy when leveraging the @model transformer in its most basic form. As your requirements evolve, you can augment this design by using additional features of the Transformer such as @key (for creating single table indexes and composite keys) or even full text search & streaming from DynamoDB with @searchable.

We do recognize that large scale or mature apps might benefit of a single table approach. Going from multiple tables to single table is probably a one time "merge" operation, after the prototyping phase, and when data access patterns have been understood by the developer. In reality there is not a "one size fits all approach" which is why Amplify’s GraphQL Transformer gives you different levels of flexibility depending on where your app is at in its evolution.

As Luis mentioned in another answer: AWS AppSync does support any type of table structure independent of the GraphQL Transformer generation pattern. Even if you do have more than one table, you can easily implement GraphQL relational patterns in a single client request either with schema design, nested resolvers, or even implementing Pipeline resolvers.

(this response was redacted with the help of Richard)

这篇关于AWS Amplify-AppSync&多个DynamoDB表的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！