如何为多查询参数场景设计DynamoDB表结构适配位置追踪系统需求

一、最优扩展性与性能的表结构设计 #

主表设计 #

• 分区键（Partition Key）：user_id，天然将不同用户的数据分散到不同存储分区，完全匹配按用户维度查询的需求，避免分区热点
• 排序键（Sort Key）：timestamp，可直接使用ISO格式时间字符串或者Unix时间戳数字，支持用户维度下的时间范围快速过滤
• 非键属性仅保留业务需要的location、details即可，减少不必要的存储开销

全局二级索引（GSI，用于支持全量时间范围批量查询） #

设计逻辑说明：DynamoDB的分区键仅支持等值匹配，无法直接对时间字段做范围查询，因此需要引入时间桶字段把相同时间窗口的数据聚合到同一分区，再配合排序键实现范围查询

• 分区键（GSI PK）：time_bucket，建议按小时或者15分钟粒度生成时间桶，比如2020-10-31T07代表2020年10月31日7点这个时间窗口，粒度可根据常用查询的时间跨度调整：查询跨度越大可使用越大的时间桶粒度，避免跨太多分区查询
• 排序键（GSI SK）：timestamp，和主表的时间戳字段保持一致，支持在时间桶内做时间范围过滤
• GSI属性投影：选择仅投影需要的location、details字段，不要投影全量属性，降低GSI的存储成本和写入开销

二、原有规划方案的合理性及优化建议 #

合理性说明 #

你初步规划的主表结构完全合理，user_id做分区键+timestamp做排序键的组合，完美匹配第二类按用户+时间范围查询的需求，查询时不需要扫描全表，只需要指定user_id后做范围查询，性能和成本都最优。

存在的问题及优化建议 #

1. 直接用day做GSI的分区键会有严重的热点问题：10TB总数据如果按天存储，假设数据保存周期是1年，单日数据量大概是27GB，远大于DynamoDB单分区10GB的上限，会导致单天的分区被强制拆分，而且查询跨天数据的时候会扫多个热分区，性能不稳定。建议换成更细粒度的时间桶，比如小时级，把单日的数据拆分到24个分区，分散读写压力。
2. GSI投影属性建议调整：如果第一类查询只需要location和details，不要投影全量属性，只投影这两个字段即可，能减少GSI的写入开销和存储成本。
3. 时间戳存储优化：可以把timestamp存储成Unix时间戳数字格式，比字符串格式的存储占用更小，范围查询的效率也更高。
4. 批量查询优化：如果第一类查询的时间范围跨了多个时间桶，可以用DynamoDB并行查询能力同时查询多个时间桶的分区，再合并结果，能大幅提升批量查询的效率。

额外注意事项 #

• 优先选择DynamoDB按需计费模式，或者提前根据读写吞吐量规划预置容量，避免流量高峰时被限流。
• 如果有自动删除旧数据的需求，直接给主表加TTL字段即可，TTL删除主表数据的时候会自动同步删除GSI中的对应数据，不需要额外处理。

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