0

我正在设计一个基于 DynamoDB 的新表。我已经阅读了一些文档，但我无法弄清楚我应该遵循哪种设计模式才能在未来没有问题。

当前方法

表 - 事件

 - eventId (HashKey)
 - userId
 - createdAt
 - some other attributes...

表 - 用户

 - userId (HashKey)
 - name
 - birth
 - address

事件表将有一堆条目，比如数百万。目前用户将有大约 20 个条目。

我将需要执行以下查询：

 - GET paginated events from specific userId ordered by createdAt
 - GET paginated events from specific userId between some range of dates and ordered by createdAt 
 - GET specific event entry by eventId

所以我想用以下设置在事件表上创建一个 GSI（全局二级索引）：

 - userId (HashKey)
 - createdAt (RangeKey)

但我的问题是：我最初的设计有意义吗？不知何故，我觉得我可以使用以下设置设计事件表：

 - userId (HashKey)
 - eventId (SortKey)

但是我认为按照这种方法我会遇到热分区陷阱。

一些意见和建议将不胜感激。

谢谢。

4

1 回答 1

0

你的方法对我来说似乎很好。牢记最佳实践https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-design.html，特别是

一般来说，您应该将应用程序设计为跨表中所有逻辑分区键及其二级索引的统一活动。您可以确定应用程序所需的访问模式，并估计每个表和二级索引所需的总 RCU 和 WCU。

这意味着，数据突变必须尽可能均匀地分布在所有分区中。在您的情况下，将会有很多事件和有限数量的用户，这表明每个用户必须有大量事件。

如果您选择基于 对表进行分区eventid，您最终会得到数百万个分区，每个分区都具有相同的用户 ID。假设您需要按用户查询事件，读取最终将均匀分布在所有分区中。每个事件的写入也将平均分配给所有人。

但是，如果您选择userid作为分区键，与其他情况相比，更多的请求将在同一分区结束。因此，我建议使用前者（eventid作为分区键）。

那是我的 2 美分。

于 2018-10-04T20:40:35.793 回答