DynamoDB中GSI与数据浅复制的功能差异及原理问询

GSI的工作原理 #

DynamoDB的全局二级索引（GSI）是一张后台异步维护的独立索引表。当你为主表创建GSI时，DynamoDB会自动将主表中符合GSI键规则的数据复制到索引表，并按照GSI定义的分区键+排序键重新组织存储结构。

以你提到的关注关系为例：
主表条目结构：

PK: FOLLOWEDPAGE#<PageID>
SK: USER#<UserId>

如果创建一个反转键的GSI（GSI的分区键为主表的SK，排序键为主表的PK），那么索引表中会生成对应条目：

GSI-PK: USER#<UserId>
GSI-SK: FOLLOWEDPAGE#<PageID>

这样就能通过GSI快速查询某用户关注的所有页面，和主表查询某页面的所有粉丝逻辑对称。

GSI本质是DynamoDB帮你自动维护了一份"键反转"的数据副本，不需要你手动写入第二条目。

GSI与手动创建第二条目的功能差异 #

除了你提到的"手动维护第二条目"的成本差异，二者还有这些核心区别：

• 一致性模型：GSI是最终一致的，主表数据更新后，GSI的同步可能存在毫秒级延迟（极端场景下延迟更长）；手动创建的第二条目如果用强一致写入，写入成功后立刻就能查询到，一致性更强。
• 存储与成本：GSI默认会复制主表的所有属性（可配置投影规则），如果主表条目带有额外属性（比如关注时间），GSI会同步存储这些数据；手动创建的第二条目可以只存必要的键属性（比如FOLLOWINGUSER#<UserId>和PAGE#<PageID>），能节省存储成本。
• 写入开销与复杂度：主表的增删改操作会自动触发GSI的同步写入（后台处理，无需代码干预），但相当于一次主表写操作会触发两次实际写入（主表+GSI）；手动创建第二条目需要在代码中执行两次写入，还要处理写入失败的回滚逻辑（比如主条目写成功但第二条目写失败的情况），复杂度更高。
• 事务支持：手动创建第二条目可以纳入DynamoDB事务，保证两个条目写入/删除的原子性；GSI不支持事务，主表的事务操作会同步到GSI，但GSI本身无法作为事务的参与对象。
• 查询限制：GSI只能通过自身的主键（分区键+排序键）进行查询，或基于排序键做范围查询；手动创建的第二条目属于主表的一部分，虽然查询逻辑类似，但可以和主表其他类型的条目结合使用（比如同一张表存储用户信息、页面信息、关注关系时），不过实际场景中通常还是单独查询。

GSI的数据复制规则 #

• GSI只会复制主表中包含GSI分区键的条目：如果主表的某个条目没有GSI定义的分区键（比如GSI分区键是主表的排序键，但该主表条目没有设置排序键），则不会被同步到GSI。
• 复制的属性可配置：默认复制主表的所有属性，你也可以选择只复制主表的键属性（主表PK、SK，以及GSI的PK、SK），或者指定特定的属性集合，以此控制存储成本。
• 主表中不符合GSI键规则的条目，不会被复制到GSI中。

内容的提问来源于stack exchange，提问作者Joshua Foxworth