Amazon dynamodb 当多方的数量可能太小或太大时，对一对多关系进行建模

我需要一些建议

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

单个发布服务器可以有多个集成（基于它们可能有多个站点或多个子站点这一事实）

集成中的文章数量可能太少，也可能太大，具体取决于发布者的大小。文章的访问频率将根据网站每日访问者的数量而降低或过高

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

数据访问模式如下所示：

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

以下是我计划的实体图

对于日期过滤器，我想添加以下GSI：

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

GSI1PK:目录#
GSI1SK：内容#

以下是我的问题：

如何在上述模型中支持日期之间（integrationId、from_date、to_date）的GetContentByIntegrationId

我应该使用集成还是用户作为主键？我担心内容在分区之间的分布是否均匀。一些用户或集成将拥有相对较高的内容数量和对内容的频繁访问。上述模型会导致热键场景吗

---

欢迎提出建议。

我看到的模型如下：

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

如何在日期之间支持GetContentByIntegrationId（integrationId， 上述模型中的从_日期到_日期）

使用内容表上GSI处创建的集成_id。应用日期筛选

我应该使用集成还是用户作为主键？我担心 内容在分区之间的均匀分布。一些 用户或集成将拥有相对较多的内容 以及频繁访问内容。上述模型是否会导致 热键场景

---

使用此模型时，我看到的唯一问题是

Content

表上的集成id GSI。如果每次集成的内容太多（每个用户都是安全的），则可能会导致问题。Dynamodb对每个分区有10GB的限制，但如果您的密钥超过了这个限制，它将透明地创建一个新分区，所以不会失败。拆分需要排序键，因此在处创建的

也很方便。
使用单独的表还是使用单个表更有意义？在很多地方，他们建议使用单个表。在NoSql中，您的模型是根据您将对其执行的查询创建的。所以这取决于我会说的很多。例如，您可以在集成中嵌入用户。但是，如果您更改（例如）名字，则需要为所有集成对象手动执行此操作。所以很大程度上取决于您的查询和更新