当多方数量太少或太大时，建模一对多关系

Question

我需要一些建议。

我正在尝试建立文本到语音解决方案的模型。博客所有者可以将我们的窗口小部件集成到他们的网站中，其访问者可以收听该文章。

单个发布者可以具有多个集成（基于他们可能具有多个站点或多个子站点的事实）。

根据发布者的规模，集成中的文章数可以太小或太大。根据网站上每天的访问者数量，访问文章的频率会降低或降低。

因此，用户具有许多集成。集成中有很多文章。

数据访问模式如下：

getIntegrationByUserId(userId)
getIntgrationById(integrationId)
getContentByIntegrationId(integrationId)
getContentByIntegrationIdBetweenDates(integrationId, from_date, to_date)
getContentByIntegrationIdAndContentId(integrationId, contentId)

以下是我正在计划的实体图。

对于日期过滤器，我正在考虑添加以下GSI：

GSI1PK: CONTENTS#<TimeStamp>
GSI1SK: CONTENT#<ContentId>

以下是我的问题：

1. 在上述模型中如何支持getContentByIntegrationIdBetweenDates（integrationId，from_date，to_date）。

2. 我应该将集成或用户作为主键吗？我担心内容在分区之间的平均分配。一些用户或集成将具有相对较高数量的内容，并且经常访问该内容。上面的模型会导致出现热键情况吗？

欢迎提出建议。

Answer 1

我正在看到这样的模型：

User 
-----------
user_id: pk; uuid
... user specific attributes ...

Integration
-----------
integration_id: pk, uuid
user_id: uuid, references User:user_id

Content
-----------
content_id: pk, uuid
content: text
created_at: date
integration_id: uuid, references Integration:integration_id

GSI: 
Integration: on user_id
Content: on integration_id, with created_at as sort key

如何支持getContentByIntegrationIdBetweenDates（integrationId， 上述模型中的from_date，to_date）。

通过在Content表上将Integration_ID与created_at GSI结合使用。应用日期过滤。

我应该将“集成”或“用户”作为主键吗？我很担心 内容在分区之间的平均分配。一些 用户或集成将具有相对大量的内容 并经常访问内容。上面的模型会导致 热键场景？

我看到的唯一使用此模型的问题是Content表上的integration_id GSI。如果每个集成的内容过多（每个用户都是安全的），则可能会导致问题。 Dynamodb每个分区有10GB的限制，但是如果您的密钥超出了限制，它将透明地创建一个新分区，因此不会失败。该拆分需要排序键，因此created_at也很方便。