DynamoDB中Load、Query与GetItem操作的差异及选型指南

一、核心定义与本质差异 #

1. GetItem #

这是DynamoDB最基础的主键查询操作，必须提供完整的主键（分区键+排序键，如果表有排序键的话），直接定位到对应分区的具体数据块，性能拉满。它只能返回单条匹配的项目，没有匹配就返回空，完全靠主键精准命中。

2. Query #

这是基于分区键的范围查询工具，必须指定分区键（或者全局二级索引的分区键），可以搭配排序键的条件（比如>、<、BETWEEN）来筛选同一分区下的多条数据。如果需要，还能通过FilterExpression对查询结果再做过滤——不过要注意，这个过滤是在数据查出来之后做的，不会减少读取容量的消耗。

3. Load（SDK封装方法） #

多数主流SDK（比如Java、.NET）里的Load方法，本质就是对GetItem API的封装，加了些实用的语法糖：比如自动把返回的原始数据映射成你定义的业务实体类，支持条件加载（比如只加载状态为ACTIVE的项目），处理空值也更方便。底层还是走GetItem，性能和成本跟GetItem完全一致。

二、关键维度对比 #

• 主键要求：
  • GetItem/Load：必须给全主键（分区键+排序键，有排序键的话不能少），缺一个都查不了。
  • Query：只要给分区键（或GSI分区键）就行，排序键可选，加了就能做范围过滤。
• 返回结果量：
  • GetItem/Load：最多1条，没匹配就空。
  • Query：能返回同一分区下的多条数据，还支持分页（用Limit和LastEvaluatedKey控制）。
• 过滤能力：
  • GetItem/Load：除了主键匹配，啥过滤都做不了。
  • Query：支持排序键范围过滤，还能加FilterExpression二次过滤（但不省容量）。
• 索引支持：
  • GetItem/Load：只能用表的主索引，GSI、LSI都用不了。
  • Query：主索引、GSI、LSI都能用，只要指定对应索引的分区键。
• 性能与成本：
  • GetItem/Load：性能最优，不管项目多大（只要不超400KB），强一致性读取只耗1个读取单位，最终一致性是0.5个。
  • Query：消耗的读取容量取决于查到的项目数量和大小，哪怕用Filter把结果滤得只剩几条，还是按最初查到的数量算容量。
• SDK使用差异：
  • GetItem：原生API，返回原始的Item或JSON结构，得自己手动解析映射。
  • Load：SDK封装好的，直接返回业务实体类，省了手动映射的代码，还能加条件判断。

三、适用场景选型 #

• 用GetItem的情况：

  • 明确知道完整主键，就查单条数据，要最快的速度和最低的成本。
  • 不需要实体映射，直接处理原始数据结构更方便。
  • 例子：用用户ID（分区键）+订单ID（排序键）查某条具体订单。

• 用Load的情况：

  • 和GetItem的场景一样，但希望少写代码，直接拿到业务实体类。
  • 需要加条件限制，比如只加载状态为有效、未删除的项目。
  • 例子：Java里用DynamoDBMapper.load(User.class, userId)直接获取User对象。

• 用Query的情况：

  • 要拿同一分区下的多条数据，比如某用户的所有历史订单（用户ID是分区键，订单时间是排序键，查近30天的）。
  • 用全局二级索引查，比如按商品分类（GSI分区键）查某类所有商品。
  • 需要对排序键做范围过滤，或者要分页批量拿数据。
  • 例子：查某个城市（分区键）下所有评分大于4.5的商家（排序键是评分）。

内容的提问来源于stack exchange，提问作者ASHOK KUMAR