数据建模

这正是 DynamoDB 与 SQL 分歧最大的地方。你不会按每个实体一张表的方式去做范式化 —— 而是从访问模式出发，设计能为这些模式服务的键，往往把每个实体都打包进一张表里。做得好，你只需一次 Query 就能取回父项及其子项，无需任何连接。

做得不好，你会得到一张查不了的表，以及一次跑不动的迁移。所以其中的权衡很重要，本节会诚实地说明那些单表设计反而是错误选择的情形。

已读 0/7测验

DynamoDB 中的单表设计

DynamoDB 中的单表设计 —— 为什么一张带重载键的表胜过每个实体一张表，附带一个具体的订单/客户示例以及 GSI 重载模式。

进阶阅读约 4 分钟

如何在 DynamoDB 中建模数据

如何以访问模式优先的方式在 DynamoDB 中建模数据——一步步演练，把一个多人对战排行榜的查询转化为分区键和排序键。

进阶阅读约 8 分钟

在 DynamoDB 中何时不要用单表设计

在 DynamoDB 中何时**不要**用单表设计 —— 多表胜出的工作负载（重分析、简单 CRUD、独立扩展），附带具体示例。

进阶阅读约 6 分钟

DynamoDB 中的 Type 属性

DynamoDB 的 Type 属性——为什么要在每个 item 上打一个实体类型，用来识别行、把一个 GSI 过滤到单一实体，并在未来的迁移中存活下来。

进阶阅读约 7 分钟

DynamoDB 中的反范式化

DynamoDB 反范式化 —— 为什么你复制数据而不是连接，附带一个博客作者名示例、陈旧暗坑，以及何时嵌入 vs. 复制。

进阶阅读约 6 分钟

DynamoDB 中的单例 Item

DynamoDB 单例 item——用一个固定 key 的行保存功能开关、配置之类的全局状态，为什么用 GetItem 取它，以及如何在不引发竞态的情况下更新它。

进阶阅读约 7 分钟

知识检测开始测验

检验你在本节学到的内容。

先从单表设计开始 —— 之后的一切都建立在这个心智模型之上。

试用 DynoTable，针对真实的表来建模并浏览这些布局。