Java项目DynamoDB复合属性查询：LSI与GSI选型及设计疑问

现有设计的合理性分析 #

前三个查询的设计是可行的 #

• 主表用book_id作为PK，完全覆盖查询1（按book_id增删改查），符合DynamoDB单主键查询的最优模式。
• 创建GSI以author_id为PK、type为SK，能完美覆盖：
  • 查询2（按author_id查所有图书）：只需指定GSI的PK为目标author_id，无需SK条件即可返回该作者的全部图书。
  • 查询3（按author_id+type查图书）：同时指定GSI的PK和SK，精准过滤出该作者对应类型的图书。

查询4设计的问题与优化 #

现有拟方案的核心问题 #

1. LSI完全不适用查询4场景：
   LSI要求与主表共享相同的PK（即book_id），查询LSI必须先指定主表PK的值。但查询4是通过book_code、publishing_house_id、book_gender的组合查询，此时你并不知道目标图书的book_id，根本无法发起有效的LSI查询，这个设计完全无法满足需求。
2. 将三个查询属性移入Document字段不可行：
   DynamoDB不支持直接对Document（JSON）内部的属性创建索引，也无法高效查询Document内的字段（只能通过全表扫描，性能极差且成本高）。这三个属性作为查询条件，必须保留为表的顶级属性，才能被索引利用。

查询4的最优方案：使用GSI #

针对book_code+publishing_house_id+book_gender的唯一组合查询，推荐创建专属GSI，有两种可选模式：

模式1：拆分GSI的PK与SK（推荐，扩展性更强）

• GSI结构：PK = book_gender#publishing_house_id，SK = book_code
• 查询方式：指定GSI的PK为[目标book_gender]#[目标publishing_house_id]，SK为[目标book_code]，即可精准定位唯一图书。
• 优势：未来如果需要扩展查询（比如查询某出版社某类别的所有图书），无需额外创建索引，直接查询该GSI的PK即可。

模式2：组合属性作为GSI的PK（写法更简单）

• GSI结构：PK = book_gender#publishing_house_id#book_code
• 查询方式：直接指定GSI的PK为拼接后的字符串，即可找到唯一图书。
• 优势：查询逻辑更简洁，适合确定未来不会扩展该组合的查询场景。

最终优化后的整体设计 #

1. 主表结构：保留所有顶级属性（book_id、author_id、type、book_code、publishing_house_id、book_gender），动态属性存储为Document类型的顶级字段。
2. 主表PK：book_id（满足查询1）。
3. GSI 1：PK=author_id，SK=type（满足查询2、3）。
4. GSI 2：选择上述模式1或模式2的结构（满足查询4）。

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