DynamoDB 是关系型数据库吗？

不是。DynamoDB 不是关系型数据库——它是一个 NoSQL 的键值与文档存储。这里没有固定模式的表、没有外键，也没有连接。你要围绕应用的访问模式来建模并做反规范化，而不是像在关系型（SQL）数据库里那样跨相关联的表做规范化。如果你怀念关系型的工作流，DynoTable 在客户端把其中一部分找了回来：一个能运行真正 JOIN 和 GROUP BY 的 SQL Workbench，以及能可视化连接表的智能表。

为什么它不是关系型的

关系型数据库强制模式、把数据跨多张表规范化，并在读取时把它们连接起来。DynamoDB 做的恰好相反：它存储无模式的项目，并期待你通过复制或内嵌相关数据来预先完成连接。

什么取代了关系型特性

连接 → 反规范化与单表设计。
规范化的表 → 归在一个分区键之下的项目集合。
即席 SQL → 基于键的 Query 和 Scan，或者 PartiQL（一个兼容 SQL 的子集，同样没有连接）。

顺带一提，PartiQL 并没有把这个缺口补上。它的解析器会拒绝两张表的 SELECT，也会拒绝 GROUP BY，而且都发生在读取任何东西之前；确切的拒绝信息引用在 DynamoDB 支持连接吗和 DynamoDB 支持 SQL 吗这两页上。

反规范化到底让你付出了什么

这笔交易通常被描述成"复制数据而不是做连接"，听上去像是一个存储层面的决定。它其实是一个写入与原子性层面的决定，而这恰恰是关系型引擎替你藏起来的那部分。

设想一个有 5,000 个订单的客户，这位客户改了自己的显示名。在关系型模式里那是针对一行的一次 UPDATE，而且每一次连接都会立刻拿到新值。反规范化进 DynamoDB 之后，这个名字活在全部 5,000 个订单项目上，所以这次改名是 5,000 次项目写入：5,000 个写入单元，按每个项目 1 KB、us-east-1 按需费率算大约 $0.003。

钱不算什么。问题在于它不可能是一次操作。TransactWriteItems 上限是 100 个动作，所以 5,000 个项目至少是 50 个彼此独立的事务，而它们之间没有隔离性。在这次扇出跑完之前，你自己的数据是自相矛盾的，任何落在中途的读取看到的都是新旧名字的混合。

关系型数据库买给你的正是这个：对一份权威副本的一次原子修改。放弃它才是真正的入场费，也正因如此，"哪些属性会被复制"比"哪些属性要建索引"更值得投入设计精力。

深入了解

阅读如何在 DynamoDB 中建模数据和单表设计。下载 DynoTable 可以可视化地探索你的数据模型——并用 SQL Workbench 在它上面运行关系型风格的 JOIN/GROUP BY 查询。

参考资料

最后核实于 2026-07-13，依据上方链接的 AWS 官方文档；100 个动作的事务上限已于 2026-07-28 从 API 参考重新取回。