时间戳

首页 > 解决方案 > DynamoDB 一对多关系非规范化或邻接？

amazon-web-services - DynamoDB 一对多关系非规范化或邻接？

问题描述

我正在为代表业务操作的数据结构设计一个表，该业务操作既可以临时执行，也可以作为批处理的一部分执行。作为批处理一起执行的操作必须是链接和可查询的，并且批处理上的元数据将被持久化。

该表必须支持 2 个查询：检索历史，即席和批处理实例。

Amazon 提出了 2 种方法，邻接和非规范化。

我不确定哪种方法最好。速度将是一个优先事项，成本次要。这将是一个多租户数据库，拥有多个组织，拥有数百万以上的运营。（Orgs 将成为分区键的一部分，用于跨节点隔离这些）

以下是我提出的想法：

有标准的最佳实践吗？关于设置/生成密钥的任何建议？

标签： amazon-web-servicesnosqlamazon-dynamodb

解决方案

老实说，在 NoSQL 最具体的 DynamoDB 中用这些术语来理解这个概念让我感到困惑。对我来说，很难根据整个业务流程逐个设计dynamodb表。准确地说，我更担心数据大小而不是 DynamoDB 请求的速度，因为我们对每个请求有 1MB 的限制。换句话说，在使用 dynamodb 时，我应该忘记所有关于关系数据库概念的事情，并将数据视为 json 对象。

但是，对于非常简单的一对多（即人们喜欢一些水果）设计，我将有我最好的方案选择字符串 PartitionKey。所以我的桌子会是这样的：

|---------------------|---------------------------------------|
|     PartitionKey    |                Infos                  |
|---------------------|---------------------------------------|
|       PersonID      | {name:String, age:Number, loveTo:map} |
|---------------------|---------------------------------------|
|       FruitID       | {name:String, otherProps}             |
|---------------------|---------------------------------------|

样本数据：

|---------------------|---------------------------------------|
|     PartitionKey    |                Infos                  |
|---------------------|---------------------------------------|
|      person123      | {                                     |
|                     |  name:"Andy",                         | 
|                     |  age:24,                              |
|                     |  loveTo:["fruit123","fruit432"]       |
|                     | }                                     |
|---------------------|---------------------------------------|
|      personABC      | {                                     |
|                     |  name:"Liza",                         | 
|                     |  age:20,                              |
|                     |  loveTo:["fruit432"]                  |
|                     | }                                     |
|---------------------|---------------------------------------|
|      fruit123       | {                                     |
|                     |  name:"Apple",                        | 
|                     |  ...                                  |
|                     | }                                     |
|---------------------|---------------------------------------|
|      fruit432       | {                                     |
|                     |  name:"Manggo",                       | 
|                     |  ...                                  |
|                     | }                                     |
|---------------------|---------------------------------------|

但是，让我们看看更复杂的案例，示例聊天应用程序。每个频道允许多个用户，每个用户都可以加入任何频道。应该是一对多还是多对多，如何建立关系？我会说我不在乎他们。如果我们将其视为关系数据库，那真是令人头疼！在这种情况下，我将使用复合 SortKey 甚至二级索引来加速特定查询。

所以，你工作的整个业务流程是什么的问题将帮助我们设计表格，而不是一块一块地

推荐阅读