何时在DynamoDB中使用多个表？

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用于直接文档查找的字段上创建一个全局索引。

那应该是这样工作的吗？将这些种类繁多的数据放入同一张表中是否合法？还是第二个两表设计是更好的方法？

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

是的，按照您的意思行事是合法的。两者都是。这里没有一些变量，它们可以帮助指导如何完成数据模型。

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

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

也可以这样思考，对于像DynamoDB这样的非关系数据库，您可以优化应用程序使用和访问数据的方式，而不必像关系数据库那样优化关系数据库，因为在关系数据库中，您不得不担心数据如何存储在数据库中。