DynamoDB 表设计

Question

【以下的问题经过翻译处理】 关于DynamoDB表设计的一个具体问题：

选项1：

选项2：

内容表CONTENT_TABLE
| 内容ID | 内容信息… |

考虑到在TAGS\_TABLE中，content\_info在许多条目中经常相同，是否将表拆分成两个表是有意义的？但是，content\_info本身不会从标签中单独请求。

Answer

【以下的回答经过翻译处理】 一般来说，使用单个表来处理给定的用例/应用/微服务最为合适。

使用双表方法需要在应用程序层面上进行额外的工作，例如在两个表之间查询，汇总结果等等。你试图将关系型模式应用到非关系型数据库中。如果在DDB中使用多个表，则通常可以通过重新考虑键选择将它们合并为一个，或者也许关系数据库可能是更好的选择。

在给出关键选择建议之前，需要对客户特定的读写模式和数据量进行深入了解。

新接触DDB的客户通常会陷入赋予他们主键和排序键以特定属性名称的关系模式中，例如tag_id或sched_id。虽然这完全可以接受并适合许多用例，但也有些其他的思路。

例如，你可以将主键命名为primary_key，将排序键命名为sort_key。通过这样做，可以清晰地表明单个DDB表可以从关系世界中容纳多个概念表。例如，你的一个表可以持有客户数据，其中主键属性格式为`cust_123`，同时在同一表中，持有订单数据，其中主键属性为`order_xyz`。

以下是一个持有客户主数据和订单历史记录的DDB表的示例。在关系世界中，这需要（至少）两个表，但在DDB中可以是一个：

```
primary_key             (其他属性)
------------------      ------------------------------------------
cust_123                name=matt, state=AZ
cust_124                name=sam , state=NY
order_1                 customer=cust123   order_date=12/31/2015, order_items=[......]

```

建议观看DynamoDB高级设计模式视频：

考虑到 TAGS_TABLE 中的许多条目中的 content_info 通常是相同的，将表分成两部分是否有意义？但是，content_info 本身不会与标签分开请求。
如果 content_info 与每个项目一起存储：

读取逻辑更简单，只需获取单个项目
重复内容消耗更多存储空间
需要更少的 GetItem() 调用来检索数据 = 更快的响应，可能更少的 RCU
如果 content_info 发生变化，则会在所有受影响的项目中更新更多 WCU

如果 content_info 存储为单独的项目：

应用层的读取逻辑更加复杂
消耗更少的存储空间
每次逻辑读取需要两次 GetItem() API 调用
如果content_info改变，只需要一次写入

DynamoDB 表设计

相关内容