Dynamo DB 的数据架构最佳实践？

Question

我有使用 PostgreSQL 等工具的关系数据库背景。最近，在探索 DynamoDB 时，我发现从架构的角度来看，最好将相关数据填充到单个表中，而不是将其分解为不同的表并引用链接数据的键。

例如

客户信息表

客户 ID |名字 |姓氏 |地址

订单表

订单ID |订单名称 |订单状态 |客户信息

CustomerInfo 将包含来自客户表的数据，例如名字、姓氏、地址等。

我的直觉告诉我，我应该将 customerID 与订单一起存储，然后在我的服务端点中查询客户信息表以获取相应的客户信息；然而，DynamoDB 的工作方式至少从成本角度来看，将所有信息填充到 Order 表中（尽管是多余的）似乎要好得多，但消除了对 Customer Info 表的额外调用。

针对这种常见场景（特别是在 DynamoDB 中）的最佳实践是什么？其他非关系数据库的最佳实践是否有所不同，或者这是关系型与 NoSQL 设计模式所固有的？

Answer 1

您正在通过单表设计走上正确的道路。

DynamoDB 没有连接操作的 SQL 概念，因此将数据存储在 DynamoDB 中的单独表中并不是对数据进行建模的最有效方法。相反，最佳实践是将相关信息存储在一起。这可以有效地按照应用程序所需的形状预先连接数据。

以这种方式对数据进行建模允许您在单个高性能查询中获取多个对象类型（例如用户、他们的订单和订单商品）。与 SQL 数据库不同，有多种方法可以对您描述的一对多关系进行建模。您采用哪种方法取决于您的应用程序访问模式，包括数据的速度（只是一种奇特的方式来表示“您读取或写入数据的频率”）。

您的观察是正确的！查看Alex Debrie 关于 DynamoDB 数据模型的演讲。 Alex 的演讲是通过几个示例快速了解 DynamoDB 数据建模的最佳方式。他的书 The DynamoDB Book 非常棒。

Answer 2

域实体和查询模式以及数据分布和成本决定了数据库设计。 从根本上来说，设计时需要考虑两个方面：写入和读取。

首先，定义在写入时可用的数据/属性/实体组。通常，实体将具有共享属性。 决定实体之间应共享哪些属性是这里最大的挑战之一。

剩下的就是弄清楚如何存储数据以进行高效查询。有工具可以帮助完成这部分设计。 例如，volisoft.org 上提供的NoSQL Architect，可以自动导出用于低成本数据检索和存储的最佳索引结构。 它对于单表设计特别有用。

对于您的特定用例，根据具体情况有多种设计 - 查询模式、频率、数据分布等。 以下是您的设计的示例：

读取优化索引

| :table | :pk  | :sk | :entity  |
|--------+------+-----+----------|
| MAIN   | c/id |     | Customer |
| MAIN   | o/id |     | Order    |

查询

|          :query | :query-tbl | :query-cost |
|-----------------+------------+-------------|
|     order by id |       MAIN |        2000 |
| order by o/name |       MAIN |        2000 |

最佳实践可能适用于特定用例，也可能不适用于特定用例。最好使用数据驱动的方法并利用精确工具，考虑查询模式和频率、数据分布和成本。