DynamoDB多GSI复用同-PK是否降本提效？单表设计咨询

场景与现有结构 #

我有一个DynamoDB表，包含帖子和用户数据，需要按以下维度排序：

• 帖子：likes（点赞数）、views（浏览量）、comments（评论数）
• 用户：friends（好友数）、uploads（上传量）

当前表结构 #

当前GSI配置 #

• GSI1: PK1 + SK1
• GSI2: PK2 + SK2
• GSI3: PK3 + SK3

期望GSI配置 #

PK1/PK2/PK3从未变更，仅为惯例使用，希望改用type作为GSI分区键，提升可读性：

• GSI1: type + SK1
• GSI2: type + SK2
• GSI3: type + SK3

访问模式 #

• 通过PK查询单篇特定帖子
• 获取按likes/comments/views排序的帖子列表
• 通过PK查询单个特定用户
• 获取按friends/uploads排序的用户列表

咨询问题 #

1. 多个GSI使用同一分区键（type）能否节省成本、提升效率？
2. 针对上述场景，是否有更优的单表设计方案？

一、同一GSI分区键的成本与效率影响 #

成本节省 #

能直接降低存储成本：

• 原设计中PK1/PK2/PK3是重复的固定长字符串，每条数据都要存储这三个冗余字段；改用type作为GSI分区键后，直接复用表中已有的type字段，无需额外存储这三个字段，主表存储容量减少，存储费用随之降低。
• GSI存储成本也会减少：原GSI分区键是长字符串，而type字段值更短（如post、user），GSI的每条索引条目占用空间更小，进一步压缩GSI存储开销。

效率提升 #

• 查询效率优化：按type筛选排序的场景（比如获取按点赞数排序的帖子），直接用type作为GSI分区键，查询时只需指定type = 'post'并按SK排序，逻辑更简洁，DynamoDB的分区定位更直接，减少不必要的字符串匹配开销。
• 维护效率提升：不用再维护PK1/PK2/PK3这三个冗余字段，写入数据时少了三个字段的更新操作，降低写入开销，同时减少因字段冗余带来的维护错误风险。

二、更优的单表设计方案 #

优化方向1：简化字段命名，利用稀疏索引特性 #

DynamoDB的GSI是稀疏索引，只有包含GSI分区键和排序键的条目才会被纳入索引，基于此可以优化字段：

• 主表删除PK1/PK2/PK3，保留type字段，将SK1/SK2/SK3分别重命名为views_sort、likes_sort、comments_sort（用户对应friends_sort、uploads_sort），字段值保持补零的字符串格式（比如005），确保数字排序逻辑正确。
• GSI配置调整为：
  • GSI1: type + views_sort（仅包含帖子条目，用于浏览量排序）
  • GSI2: type + likes_sort（仅包含帖子条目，用于点赞数排序）
  • GSI3: type + comments_sort（仅包含帖子条目，用于评论数排序）
  • GSI4: type + friends_sort（仅包含用户条目，用于好友数排序）
  • GSI5: type + uploads_sort（仅包含用户条目，用于上传量排序）
    （注：DynamoDB单表最多支持5个GSI，刚好覆盖所有排序需求）

优化方向2：精简GSI投影字段 #

根据实际查询需求设置GSI的投影类型，比如查询排序后的帖子列表时，若只需要帖子ID、标题、点赞数等核心字段，就只投影这些字段，而非投影所有字段，进一步降低GSI的存储成本。

优化方向3：保留现有主表主键逻辑 #

当前主表的PK/SK设计（POST#<ID># + POST#INFO#、USER#<NAME># + USER#INFO#）能很好支持单条数据查询需求，建议保留；post-details类型的条目用POST#<ID>#作为PK、POST#DETAILS#作为SK的设计，能有效关联帖子基本信息，无需调整。

三、额外注意事项 #

• 排序字段必须补零：确保数字以固定长度的字符串存储（比如3位或4位），否则DynamoDB按字符串排序会出现100排在20前面的错误，补零后020会排在100前面，符合数字排序逻辑。
• 字段更新一致性：当点赞数、浏览量等排序维度数值变化时，要同步更新对应_sort字段的值，避免GSI数据与主表数据不一致。

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