DynamoDB 是键值存储吗？

是——DynamoDB 是键值存储，同时也是文档存储。每个项目都通过它的主键（一个分区键，可选再加一个排序键）取回，从而实现快速的基于键的查找。它还额外支持文档类型——嵌套的列表和映射——所以它既是键值数据库，也是文档数据库。

键值模型

每个项目都有一个唯一标识它的主键。对那个键执行 GetItem 是一次直接的、个位数毫秒的查找——不做扫描。这就是经典的键值访问模式。

除了键之外，值可以是丰富的文档：映射（对象）和列表（数组），可嵌套至 32 层深，并受 400 KB 项目上限约束。这让 DynamoDB 成为一个值为类 JSON 文档的键值存储。

32 层的上限是真实存在的（第 33 层会被直接拒绝，准确的错误在这里），但真正咬人的很少是深度，而是寻址方式。

你是按键读取的，不是按字段。ProjectionExpression 收窄的是穿过网络的内容，而不是 DynamoDB 读取的内容。在一个约 30 KB、装着一段很长的 bio 和一个 100 元素 tags 列表的项目上，一次强一致的 GetItem 三种写法的账单完全一样：

请求	返回内容	`ConsumedCapacity`
`GetItem`，整个项目	全部内容	8
`ProjectionExpression: 'status'`	一个 6 字节的值	8
`ProjectionExpression: 'profile.tags[0]'`	列表里的一个元素	8

这就是你把文档存进键值存储所接受的取舍：访问和计费的单位都是整个项目。如果某一个属性被频繁读取而它的邻居又很大，它们就该放进不同的项目里。

因为读取是按键进行的，一次高效的查找必须先钉住单个分区键值。设计好键正是 DynamoDB 建模的核心。

item size calculator 按照 DynamoDB 的方式对属性名称和值进行总计。

在DynoTable：复合分区键，例如USER#123在网格中解码，这样您就可以一目了然地读取实体前缀，行快速视图（Space）可以打开完整文档而不会丢失您的位置。参见Querying tables。

最后核实于 2026-07-13，依据上方链接的 AWS 官方文档。

这些容量数字于 2026-07-28 针对 DynamoDB Local 3.3.0（amazon/dynamodb-local:latest）通过 @aws-sdk/client-dynamodb 3.1095.0 实测得出，不是估算。

根据上面链接的官方AWS文档上次验证时间为 2026 年 7 月 13 日。

容量数据是在 2026 年 7 月 28 日通过 @aws-sdk/client-dynamodb 3.1095.0 根据 DynamoDB 本地 3.3.0 (amazon/dynamodb-local:latest) 进行测量的，未进行估计。