DynamoDB 1 个大表还是多个小表？

Question

我目前面临一些关于我的数据库设计的问题。目前我正在开发一个允许用户执行以下操作的 api：

• 创建一个帐户（1 个用户拥有 1 个帐户）
• 创建个人资料（1 个帐户拥有 1-n 个个人资料）
• 让配置文件上传 2 种类型的项目（1 个配置文件拥有 0-n 个项目；这些项目的类型和用途不同）

调用 API 方法会触发 AWS Lambda 在 DynamoDB 表中执行请求的操作。

我目前的计划是这样的：

应该可以通过指定时间范围和配置文件 ID 来查询项目。但我认为我的设计完全违背了 DynamoDB 的目的。 AWS 文档说，一个设计良好的产品只需要一个表。

• 在一个表中实现此架构的好方法是什么？
• 使用当前设计有什么缺点吗？
• 在当前设计和单表方法中，您会指定什么作为主/分区/排序键/辅助索引？

Answer 1

假设您需要能够执行以下查询，我将给出这个答案。

• 给定一个帐户，查找所有个人资料
• 给定个人资料，查找所有项目
• 给定一个 Profile 和一个特定的 ItemType，查找所有项目
• 给定一个项目，找到拥有的个人资料
• 给定个人资料，找到所有者帐户

DynamoDB 的优点之一（也许也是一个祸根）是它主要是无模式的。您需要为表中的每个项目具有强制性的主键属性，但所有其他属性都可以是您喜欢的任何属性。为了让 DynamoDB 设计只有一张表，您通常需要习惯在同一张表中包含混合类型的对象的想法。

话虽如此，这是您的用例的可能架构。我的建议假设您使用 UUID 之类的东西作为标识符。

分区键是一个简单地称为pkey（或任何你想要的）的字段。我们还将调用排序键skey（但同样，这并不重要）。现在，对于一个帐户，pkey 的值是Account-{{uuid}}，skey 的值将是相同的。对于配置文件，pkey 的值也是Account-{{uuid}}，但skey 的值是Profile-{{uuid}}。最后，对于一个项目，pkey 是Profile-{{uuid}}，skey 是Item-{{type}}-{{uuid}}。对于一个项目的所有属性，不用担心，只要使用你想使用的任何属性。

由于“父”对象始终是分区键，因此您只需查询父对象的 ID 即可获取任何“子”对象。例如，获取配置文件的所有“ItemType2”的关键条件表达式将是

pkey = “Profile-{{uuid}}” AND begins_with(skey, “Item-Type2”)

在此架构中，您的 GSI 具有与表相同的键，但相反。您可以在 GSI 中查询“Item-{{type}}-{{uuid}}”以获取拥有的配置文件，类似地使用配置文件来获取拥有的帐户。

我在这里说明的是adjacency list pattern。 DynamoDB 还有一篇文章描述了如何使用composite sort keys for hierarchical data，这也将适合您的数据，并且根据您的预期查询，它可能比使用邻接列表更适合。

您不必将所有内容都放在一个表中。是的，DynamoDB 推荐它，但更重要的是确保您的应用程序正确且可维护。如果拥有多个表意味着更容易编写无缺陷的应用程序，那么使用多个表。