何时在 DynamoDB 中使用多个表？

Question

DyanmoDB最佳实践明确指出：

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

我觉得很有趣，我见过的处理 DyanmoDB 的几乎每个教程都有多表设计。

但这在实践中意味着什么？

让我们考虑一个具有三个主要实体的简单应用程序：用户、项目和文档。一个用户拥有多个项目，一个项目可以有多个文档。我们通常必须查询用户的项目和项目的文档。读取数量大大超过写入数量。

一个天真的教程的表格设计将使用三个表格：

Users
Hash key
user-id

Projects
Hash key       Global Index
project-id     user-id

Documents
Hash key       Global Index
document-id    project-id

我们可以很容易崩溃Project，并Document为一个Documents表：

Documents
Hash key    Sort key        Global Index
project-id  document-id     user-id

但为什么要停在那里？为什么不用一张桌子来统治他们呢？既然User是一切的根源...

Users
Hash key    Sort key
user-id     aspect
---------   ---------
foo         user                   email: foo@bar.com ...
foo         project:1              title: "The Foo Project"
foo         project:1:document:2   document-id: 2     ...

然后我们将有一个全局索引，例如，email用于用户记录查找的document-id字段，以及另一个用于直接文档查找的字段。

这是它应该如何工作？将如此大相径庭的数据放入同一张表是否合法？还是第二种，双表设计是更好的方法？

在什么时候添加第二个表是正确的？

Answer 1

是的，按照你说的去做是合法的。两者实际上都是。有一些变量在这里没有，它们可以帮助指导数据模型应该如何完成。

1. 您希望使用此应用程序和数据模型达到什么样的规模？
2. 在应用程序的访问模式中，这些模式之间的读取比率是多少。意思是哪一个比其他人受到的打击最大。
3. 在您列出的访问模式中，它们每秒执行多少次？

例如，如果所有读取的 80% 是为了找到项目中的用户，并且需要以 30,000/秒的速度发生，但在您的应用程序中，没有多少人会更进一步并找出项目的文档，那么它是总读取数的 20%，可能只有 2000 次读取/秒。第一个是应用程序的“热路径”，应该对其进行优化。

也可以这样想，对于像 DynamoDB 这样的非关系型数据库，您可以针对应用程序使用和访问数据的方式进行优化，而不是像关系型数据库那样，您必须非常担心它是如何存储在数据库中的。