数据建模

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

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

已读 0/7测验

DynamoDB 中的单表设计

DynamoDB 中的单表设计把所有实体都放进一张表，用重载的键前缀区分，于是父项和它的子项能在一次 Query 中一并返回。

进阶阅读约 4 分钟

如何在 DynamoDB 中建模数据

如何以访问模式优先的方式在 DynamoDB 中建模数据。一个游戏排行榜的演练，把四个问题变成分区键、排序键和一个 GSI。

进阶阅读约 8 分钟

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

在 DynamoDB 中何时不要用单表设计——重分析、对无关实体的简单 CRUD，以及需要独立扩展或独立失败的实体。

进阶阅读约 6 分钟

DynamoDB 中的 Type 属性

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

进阶阅读约 7 分钟

DynamoDB 中的反规范化

DynamoDB 反规范化——为什么你复制数据而不是做 join，附带一个博客作者名的示例、陈旧数据的暗雷，以及何时嵌入对比复制。

进阶阅读约 6 分钟

DynamoDB 中的单例项

DynamoDB 单例项——一行固定键的项目，保存诸如特性开关或配置之类的全局状态，用 GetItem 读取，用条件表达式更新。

进阶阅读约 8 分钟

知识检测开始测验

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

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

在动手构建之前，先用免费的单表设计工具勾勒 schema——它会把一份访问模式清单变成一个 PK/SK/GSI 方案。然后试用 DynoTable，针对真实的表来建模并浏览这些布局——而对于你的键服务不了的临时问题，它的 SQL Workbench 会在客户端运行 JOIN、GROUP BY 和聚合。