Dynamodb 架构设计（将关系数据映射到 nosql）答案

【问题标题】：Dynamodb schema design (map relational data to nosql)Dynamodb 架构设计（将关系数据映射到 nosql）
【发布时间】：2019-02-07 12:15:33
【问题描述】：

试图从 AWS 中了解这个示例，以将关系模型映射到 nosql

这里强调的一个关键概念是：

重要

.... 大多数精心设计的应用程序只需要一个桌子。 ...

鉴于此，示例表如下

它解释了，

您定义以下支持关系顺序的实体入口架构：

HR-员工 - PK：员工 ID，SK：员工姓名

HR-Region - PK：RegionID，SK：区域名称

...

但是，示例表中的实体HR-Employee - PK: EmployeeID, SK: Employee Name 的SK 值不是Employee Names。

另外，它建议以下查询

但 GSI-1 没有 Employee Name 的 PK。

我知道这可能是 AWS 文档中的一个差异，我应该向他们提出（我有，而且他们在跟进方面出了名的糟糕），但我不确定文档是否正确，我的理解是错误（我倾向于相信后者，因为 AWS 文档通常是准确的）。

有人可以指导我在 nosql 模式映射方面的正确方向吗？上述链接中模式的正确示例（带有发电机表的示例记录）将非常有价值。

【问题讨论】：

【解决方案1】：

所以我会尽量让你更清楚，如果还有什么不明白的，请告诉我。

首先，您提到以下事实：

但是，示例表中的实体 HR-Employee - PK: EmployeeID, SK: Employee Name 的 SK 值不是 Employee Names。

存在 SK 值不是“员工姓名”的原因是因为 SK 不仅用于“员工姓名”，还用于其他查询（例如地区名称、国家/地区名称等）。将 SK 视为它所代表的确切含义，即排序键。文档似乎错过了对他们拥有的额外 SK 的解释，所以让我总结一下您正在查看的内容。

您有 HR-Employee1，员工姓名 = Employee1，QuotaID（猜猜这个键是什么）= QUOTA-2017-Q1，其他键 = HR-CONFIDENTIAL

这些键名实际上并没有在表中定义，它们都在排序键下，并且只是隐含的“员工姓名”或“配额ID”或“地区名称”。

这允许您做的是查询员工数据，使用employeeID 作为PK 和员工姓名作为SK，但它还允许您通过使用employeeID 作为PK 和quotaID 作为SK 来查询员工配额数据（或任何它） .

这同样适用于您关于 GSI-1 的第二个问题。本质上，他们在这种情况下设计表格的方式是您有一个 SK“SortKey”，如果有意义的话，您可以在其中对各种类型的值进行排序。

【讨论】：

谢谢，这是有道理的。但是，如果 SK 名称是“SortKey”，值是员工姓名、地区等，那么您如何处理冲突？例如。 ID=123，名称和地区都是 'Austin'
在他们的案例中，他们指定了这些冲突不会发生的条件；例如，他们不会将区域名称 SK 放在员工名称 PK 下，因此如果您在 SK = "Austin" 的 EmployeeID PK 上进行搜索，结果永远不会找到 regionName SK，因为 regionName 仅存在于 regionID PK 下。跨度>
但是他们怎么能在设计时知道如果它们不是不同的类型，多个 SK 会发生冲突呢？如果多行包含不同类型的典型场景没有冲突？即使 SK 是不同类型的 ID（QuotaID 和 ProductID），它们也可能会发生冲突，不是吗？
就个人而言，如果它们可能发生冲突，那么我建议将它们放在单独的表中。您需要为容量使用付费，而不是为每张桌子付费，因此拥有额外的桌子应该不是问题。
混合数据时，在属性值前面加上其类型会很有帮助。例如，ID:123、FIRSTNAME:Austin、CITY:Austin。这样，如果您查询“Austin”，您可以在其前面加上 FIRSTNAME 或 CITY，这样您就知道您会得到正确的结果。