如何在DynamoDB中存储大型数组？有哪些最佳实践

首先明确一个基础规则：DynamoDB单条Item的硬大小上限是400KB（包含属性名、属性值的所有编码长度），你记忆里的1MB是错误阈值，只要单条数据逼近400KB，就必须调整模型，不能硬塞大数组。

你提到的「仅存储CardId数组、二次查询拉取完整Card数据」是可行方案之一，但要根据你的业务数据量级选对应实现，下面是生产环境验证过的标准方案：

方案1：主Item存ID列表 + 批量拉取实体 #

• 适用场景：Card是独立公共实体，会被多个用户关联、单独更新维护，单用户关联的Card总量在1000条以内（单个CardId按20字节算，1000个ID仅占20KB左右，离400KB上限有充足冗余）
• 实现逻辑：
  • 用户主Item仅存UserId、昵称、头像这类体积小、更新频率低的核心属性，Watching、Listings字段改为字符串数组，仅存储对应Card的主键ID
  • 所有Card单独存储为独立Item，主键用CardId
  • 需要拉取完整列表时，先查询用户Item拿到ID数组，调用BatchGetItem接口批量拉取Card详情即可，该接口单次支持最多100条ID查询，ID量超过100时拆批调用即可，延迟完全可控
• 优缺点：实现门槛极低，Card信息更新时仅需修改对应Card单条记录，不需要同步更新所有关联用户的Item；缺点是如果单用户关联的Card量过万，ID数组本身会占用过多空间，每次拉取全量ID的额外开销会升高。

方案2：邻接表建模（无界大数组的官方推荐方案） #

如果你的业务里用户关联的Card量没有明确上界（比如重度用户可能有上万条Listing/浏览记录），用邻接表（单表设计核心模式）可以完全绕开单Item大小限制，是DynamoDB处理一对多无界关系的标准实践：

• 表结构采用复合主键设计：
  • 分区键（PK）：存储实体唯一标识，用户实体格式为USER#<UserId>，卡片实体格式为CARD#<CardId>
  • 排序键（SK）：存储关系类型或实体标记，用户自身核心属性的SK固定为#META，用户上架卡片的关联关系SK格式为LISTING#<CardId>，用户关注卡片的关联关系SK格式为WATCHING#<CardId>，卡片自身属性的SK固定为#META
• 实际存储示例：

• 查询逻辑：
  • 拉取用户核心信息：直接查询PK=USER#123 AND SK=#META即可，单条读性能极高
  • 拉取用户全量Listing：查询PK=USER#123 AND SK BEGINS_WITH 'LISTING#'，同分区下的前缀查询性能不受数据量影响，支持分页拉取，哪怕单用户有十万条Listing也不会触发大小限制
  • 拉取卡片详情：单条查询PK=CARD#<CardId> AND SK=#META，或批量拉取多个Card即可
• 效率优化：如果列表页需要展示卡片名称、封面这类更新频率极低的Card属性，可以在写入LISTING#<CardId>关联记录时把这些字段冗余存一份，这样拉列表时一次查询就能拿到所有渲染需要的字段，不需要二次查Card实体，用反范式冗余换读性能，Card信息更新时异步同步冗余字段即可，非常适合读多写少的场景。

避坑提醒 #

• 不要把完整Card对象直接嵌套在用户Item的数组里：一来很快会撞上400KB单Item上限，二来Card信息更新时需要遍历修改所有关联该Card的用户Item，写性能极差，还很容易出现数据不一致
• 如果你存的数组有明确的很小的上界（比如每个用户最多存50个常用地址），直接嵌套存在用户Item里完全没问题，不需要拆分，DynamoDB对小体积嵌套属性的读写性能很好。

内容的提问来源于stack exchange，提问作者Oliver Darby