DynamoDB单表设计：前缀分区键与GSI热分区问题咨询
首先看你当前的主表与GSI设计：
原主表设计
| PK | SK (entity) | Attr |
|---|---|---|
| CAR#12345 | Car | Record for Car 12345 |
| CAR#67890 | Car | Record for Car 67890 |
| CAR#11111 | Car | Record for Car 11111 |
| TRUCK#22222 | Truck | Record for Truck 22222 |
原GSI设计
| GSI PK | GSI SK | Description |
|---|---|---|
| Car | CAR#12345 | GSI Record for Type Car 12345 |
| Truck | TRUCK#22222 | GSI Record for Type Truck 22222 |
一、主表静态前缀PK是否会引发热分区？
不会。DynamoDB的分区是基于分区键的哈希值分配的，而非前缀匹配。你用CAR#<GUID>作为PK时，每个记录的后缀是唯一GUID，不同GUID的哈希值差异极大，会被均匀分散到不同物理分区。哪怕有50万条汽车记录，也不会集中在同一个分区，因此不会出现热分区问题。
这种设计是单表模式的常规实践：前缀区分实体类型，唯一后缀保证分区键高基数，既满足实体识别需求，又天然规避了热分区风险。
二、以实体类型作为GSI PK是否会导致热分区？
会。GSI的分区规则和主表一致：相同GSI PK的所有记录会存储在同一个物理分区。看你原GSI设计，所有Car类型记录的GSI PK都是Car，会全部聚集到同一个GSI分区。当对该类型实体有大量读写操作时，这个分区会成为热点，达到单个分区的吞吐量上限（默认1000 RCU/WCU，虽可扩容但仍有瓶颈），进而影响性能。
三、无需扫描获取特定实体所有记录的替代方案
要避免扫描同时规避GSI热分区，核心是提升GSI PK的基数，让同类型实体分散到多个GSI分区。以下是几种可行方案：
1. GSI PK引入分片键
修改GSI PK为实体类型#分片ID格式，例如Car#0、Car#1…Car#9。分片ID可通过对主表PK的GUID部分做哈希取模生成（比如hash(GUID) % 10），确保同类型实体均匀分配到不同分片。
调整后的GSI示例：
| GSI PK | GSI SK | Description |
|---|---|---|
| Car#0 | CAR#12345 | GSI Record for Type Car 12345 |
| Car#1 | CAR#67890 | GSI Record for Type Car 67890 |
| Car#0 | CAR#11111 | GSI Record for Type Car 11111 |
| Truck#2 | TRUCK#22222 | GSI Record for Type Truck 22222 |
查询所有Car记录时，只需并行查询Car#0到Car#9这10个GSI PK，再合并结果即可。这种方式避免了扫描，同时分散了GSI的读写压力。
2. 利用业务天然维度作为分片键
如果数据有天然业务分片维度（如地域、品牌、用户组），可直接将其融入GSI PK，例如Car#US、Car#EU。这种设计不仅规避热分区，还能让查询更贴合业务场景（比如只查美国地区的汽车）。
3. 时间分片（适用于带时间属性的实体）
如果实体包含时间戳（如创建时间），可将GSI PK设计为Car#2024Q1、Car#2024Q2这类按时间窗口分片的格式。查询时按需指定时间范围，既分散负载，又能实现按时间维度的高效查询。
四、最佳实践总结
主表设计
- 保留
CAR#<GUID>这类PK设计：前缀区分实体类型，唯一后缀保证高基数，天然规避热分区。 - 避免使用递增式后缀（如自增ID、连续时间戳）：短时间内递增的PK哈希值可能集中到同一个分区，引发临时热点；GUID这类随机值是更优选择。
GSI设计
- 绝对避免单一实体类型作为GSI PK：必须引入分片键提升PK基数。
- 分片数量按需调整：根据实体总数量和读写吞吐量需求确定分片数（比如50万条记录分10-20个分片即可）。
- 并行查询分片：遍历分片时采用并行查询，减少总耗时；DynamoDB支持并发请求，不会带来额外性能损耗。
内容的提问来源于stack exchange，提问作者rmore123
