DynamoDB 表设计模式：使用 utc 时间戳对数据进行分类

Posted 2023-02-24

【中文标题】DynamoDB 表设计模式：使用 utc 时间戳对数据进行分类

【英文标题】：DynamoDB table design pattern: catagorized data with utc time stamp

【发布时间】：2020-01-29 08:44:47

【问题描述】：

我目前正在设计一个 DynamoDB 模式，我不知道我是否走在正确的轨道上。

我需要将以下数据存储到 DynamoDB 表中：

设备ID（编号） deviceLogType（字符串） timestamp (number) // 时间戳以 utc 秒为单位 其他杂项属性

此 DynamoDB 表的主要查询是通过 deviceID 和 deviceLogType 在一个时间范围内查询数据。是

分区键：deviceLogType_deviceID

排序键：timestamp

我的问题是：

上面的设计正确吗？ 最佳实践是否使用复合键作为分区键来表示层次关系？

【问题讨论】：

您是否需要搜索“给定 deviceID 和时间范围的所有 deviceLogTypes”或“给定 deviceLogType 和时间范围的所有 deviceIDs”？如果是，那么有多少个 deviceLogType，这个数字还会增长吗？

哪个层次关系更准确？

@MatthewPope，不，我也不需要搜索。有固定数量的 deviceLogTypes。

@HoratiuJeflea，层次关系：deviceLogType -> deviceID

【参考方案1】：

deviceLogType_deviceID (hash key)
timestamp (sort key)
deviceID (I would keep this separate for future query possibilities)
deviceLogType (I would keep this separate for future query possibilities)
other misc attributes

使用此架构，您可以使用当前的查询，并为将来仅通过 deviceId 或 deviceLogType 进行查询提供可能性（仅添加索引）。

复合键确实是一种很好的做法（最好有一个不会出现在两个值中的分隔符），但不确定您指的是哪种继承。

但例如，如果我们有 androidDeviceLogType > DeviceLogType，最佳做法是将该值以序列化形式存储在 deviceLogType 中（例如 Base64 中的 JSON，或者只是纯 JSON...）。

【参考方案2】：

您的方法适用于您描述的用例。

使用复合分区键是可以接受的。您不能使用分区键上的部分匹配来执行任何分层查询，但从历史上看，它具有帮助防止热分区的额外好处。热分区现在是a thing of the past，所以你不必再担心了。

我只看到一个可能的问题。如果您有多个具有相同deviceLogType_deviceID 和timestamp 的日志条目，则最后一个将覆盖具有相同时间戳的所有先前条目。为避免这种情况，您可以将时间戳存储为 ISO 8601 字符串，并在时间戳末尾附加 UUID 以防止主键冲突。