推荐的DynamoDB日历/事件结构模式

Question

我对DynamoDB设计很新，并尝试为我的应用程序获取正确的架构。在这个应用程序中，不同的用户将输入关于他们的一天例如＆＃34;用户X，3月1日12：00-2：00，累了＆＃34; 。在给定时间内可能有多个条目，或重叠时间（例如，从12-2疲惫到12-1吃午餐）。

我需要根据用户和时间范围进行查询。常见问题：

• 给我所有的＆＃34;行动＆＃34;对于用户X在时间t1和t2之间
• 向我提供用户X
操作Z的所有开始时间

我最初的想法是分区键是开始时间的用户ID和范围键，但由于重复的开始时间不对，它不能正常工作吗？

第二个想法：

• UserID - 分区键
• StartTime - RangeKey

• 操作 - 该开始时间的所有操作的JSON文档

  [{action：＆＃34; Lunch＆＃34;，endTime：＆＃34; 1 pm＆＃34;}，{action：tired，endTime：＆＃34; 2 pm＆＃34;}]

  < / LI>

有关正确架构的任何建议吗？

Answer 1

这并不是真的有一个解决方案。您需要根据您的使用情况评估多个选项，您拥有多少数据/查询频率以及哪些字段等。

但一个好的解决方案就是像这样对你的架构进行分区。

• 生成UUID作为分区键
• 用户ID
• 开始时间（以unix纪元时间或ISO8601时间格式）

<强>优点

• 可以处理多个时区
• 可以轻松查询以获取用户ID和开始日期（您需要使用主键 userID 和排序键开始时间的辅助索引）
• 由于随机生成的主键，您在DynamoDB分区上的数据分布更均匀，热点更少。

<强>缺点

• 每个项目的更多数据（因为UUID）（+16字节）
• 新二级索引的额外费用，请注意扫描表中的数据通常比使用二级索引贵得多。

这与您最初的想法非常接近，为了获得更准确的答案，我们需要更多关于您计划进行多少次写入和读取的信息，以及您需要什么样的查询。

Answer 2

如果不是重叠活动的事实，那么UserID作为分区键是正确的，而StartTime作为rangeKey是明显的选择。

我会考虑选择

• UserID - 分区键
• StartTime + uuid - RangeKey
• StartTime - 普通旧属性

DynamoDB中的日期时间无论如何都只是存储为字符串。所以这里的想法是你有一个StartTime +一些uuid作为你的rangekey，它给你一个基于日期时间的可排序表，同时也保证你有唯一的主键。然后，您可以将StartTime存储在单独的属性中，或者具有从StartTime + uuid属性添加/删除uuid的功能。