AWS为何建议在DynamoDB中使用Timestamp而非Device ID作为分区键？

场景差异是核心原因 #

AWS IoT教程和分区键博客的建议差异，本质是针对的业务读写场景不同，并非互相矛盾：

1. IoT教程推荐Timestamp做分区键的逻辑 #

IoT场景下设备数据通常是高频时序写入，且最常见的查询是按时间范围批量查询（比如查某小时内所有设备的上报数据）：

• 用分段的Timestamp（比如按小时/分钟截断的时间戳）做分区键，能把写入请求均匀分散到多个DynamoDB分区，彻底避免热点写入问题——如果用设备ID当分区键，单台高频上报的设备会把所有请求集中到同一个分区，触发DynamoDB的吞吐量限流。
• 按时间范围查询时，能直接定位到对应时间区间的分区，无需扫描全表，查询效率极高。

2. 高基数分区键建议的适用场景 #

博客中提到的高基数属性（比如设备ID），更适合以单实体查询为主的场景：

• 如果你的核心需求是快速查询某台设备的全量历史数据，用设备ID做分区键、Timestamp做排序键是更优的选择——查询时直接定位到该设备的分区，再按排序键范围读取即可。
• 但这种结构有个前提：设备的写入频率不能过高，否则单设备的所有写入都会集中在同一个分区，依然会触发热点限流。如果是这种情况，可以给设备ID加时间后缀（比如device_123#2024052010）来分散负载。

3. 同一设备数据分散的影响 #

用Timestamp做分区键时，同一设备的数据会分散到不同分区，仅对单设备全量历史查询有影响：

• 这种查询需要扫描多个时间分区才能拿到完整数据，效率会低于设备ID做分区键的结构。
• 但如果你的查询都是设备+时间范围（比如查设备A在今天10点到11点的数据），或者全局时间范围，这种分散反而不影响——你可以直接定位到目标时间分区，再在分区内过滤设备ID（把设备ID设为排序键或者全局二级索引GSI的主键即可）。

4. 分区键的唯一性误区 #

• 单独使用分区键时，确实要求全局唯一；但使用**复合主键（分区键+排序键）**时，只需要两者的组合唯一即可，分区键本身可以重复。
• 所以设备ID完全可以作为分区键，搭配Timestamp（或其他唯一标识，比如请求ID）作为排序键，就能保证每条记录的主键唯一，符合DynamoDB的要求。

总结：按需选择主键结构 #

根据你的核心读写模式来决定：

• 核心是高频时序写入+时间范围查询：选分段Timestamp作为分区键，设备ID+Timestamp作为排序键，同时给设备ID创建GSI支持单设备查询。
• 核心是单设备全量历史查询：选设备ID作为分区键，Timestamp作为排序键；若单设备写入频率极高，给设备ID加时间后缀来分散分区负载。

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