DynamoDB证书存储Schema设计及查询方案咨询

一、主表 PK-SK 组合优化 #

当前方案分析 #

你计划用 certificateID（UUID）作为 PK，CERT-时间戳作为 SK 实现数据均匀分布。这里存在两个可优化点：

• UUID 本身具备极强的随机性，作为 PK 已经能保证数据在 DynamoDB 分区中均匀分布，额外的 SK 前缀 CERT- 属于冗余存储，无实际查询价值。
• 如果主表仅需通过 certificateID 做单条查询，SK 完全可以省略——DynamoDB 支持单属性主键（仅 PK），能减少存储开销，简化数据结构。

优化建议 #

• 若未来有按时间范围查询证书创建/签发记录的需求，保留 SK 但优化格式：去掉冗余前缀，直接用 ISO 8601 格式的时间戳（如 2024-05-20T14:30:00）作为 SK。这样既保留均匀分布特性，又能通过 PK = certificateID AND SK BETWEEN 起始时间 AND 结束时间 做精准范围查询。
• 若无时间范围查询主表的需求，直接使用单主键 certificateID（UUID）即可，无需设置 SK，降低存储和维护成本。

二、未来90天过期证书查询方案优化 #

当前 GSI 方案的潜在问题 #

你计划用 expiryYearMonth（如 202405）作为 GSI 的 PK，通过3-4次查询获取目标数据，存在以下问题：

• 热点分区风险：若某一个月的过期证书数量远高于其他月份，该 expiryYearMonth 对应的 GSI 分区会成为热点，触发性能瓶颈甚至限流。
• 低效数据过滤：每次查询需读取整个月的所有证书数据，再在应用层过滤出未来90天内的记录，浪费大量读取容量单元（RCU），尤其是当月初或月末查询时，无效数据占比极高。
• 逻辑复杂度高：需处理跨多个月份的边界情况（比如当前是5月20日，90天后到8月18日，需查询5、6、7、8月四个分区），代码中要拼接多个查询并去重，增加维护成本。

更优替代方案 #

推荐采用带分片键的 GSI 范围查询方案，具体设计如下：

1. GSI 结构：
   • PK：EXPIRY#<shard>，其中 <shard> 是 expiryDate 的日份对 N 取模的结果（N 建议取 10-20，比如模10，生成 0-9 共10个分片）。
   • SK：expiryDate（存储为 ISO 8601 格式的字符串，如 2024-08-18T00:00:00）。
   • 投影属性：包含查询需要的所有字段（如 certificateID、name、status 等），避免回表查询。
2. 查询逻辑：
   • 计算未来90天的时间范围：startDate = 当前日期，endDate = 当前日期 + 90天。
   • 遍历所有分片（0到9），对每个分片执行查询：PK = EXPIRY#<shard> AND SK BETWEEN '<startDate>' AND '<endDate>'。
   • 合并所有分片的查询结果，即可得到未来90天内过期的所有证书。
3. 方案优势：
   • 避免热点：分片键将过期证书均匀分散到多个 GSI 分区，不会出现单分区过载的情况。
   • 高效精准：直接通过 SK 范围查询过滤目标日期，无需读取无效数据，大幅节省 RCU。
   • 逻辑简化：无需处理月份边界，只需按固定分片数执行查询，代码逻辑更清晰。

另一种简化方案（适合数据量不大的场景）：
如果证书总数据量较小（百万级以下），可以直接创建一个 GSI，PK 设为固定值 CERT-EXPIRY，SK 设为 expiryDate。查询时直接执行 PK = 'CERT-EXPIRY' AND SK BETWEEN '<startDate>' AND '<endDate>'。这种方案逻辑最简单，但数据量较大时会出现热点问题，需谨慎使用。

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