gpt4 book ai didi

mongodb - 大规模与 MongoDB 的多对多关系

转载 作者:行者123 更新时间:2023-12-02 05:03:30 26 4
gpt4 key购买 nike

我看过很多关于如何与 MongoDB 建立多对多关系的帖子,但没有一个提到规模。例如这些帖子:

MongoDB Many-to-Many Association

How to organise a many to many relationship in MongoDB

我发现这种设置的问题是 MongoDB 的 16MB 文档限制。假设我有用户帖子帖子有一个关联的和许多可以喜欢它的用户。一个群组中包含许多帖子,以及许多可以关注它的用户。一个用户可以拥有多个喜欢的帖子,并且可以关注多个群组。如果我用关系数据库构建它,我会这样设置:

user:
user_id
username

post:
post_id
group_id
message

group:
group_id
name

post_likes:
post_id
liked_user_id

group_followers:
group_id
follower_user_id

理论上,一个群组可以拥有无​​限数量的帖子和关注的用户,一个帖子 可以拥有无​​限数量的喜欢的用户,并且用户可以拥有无​​限数量的喜欢的帖子如果 SQL 查询中分页正确完成,他们将遵循这些内容。

如何设置 MongoDB 的架构才能实现这种规模?

最佳答案

这是一个很好的问题,它说明了过度嵌入的问题以及如何处理它。

示例:发布点赞

让我们继续使用用户喜欢帖子的示例,这是一个简单的示例。其他关系依此处理。

您说得完全正确,将点赞存储在帖子中迟早会导致非常受欢迎的帖子达到大小限制的问题。

因此,您正确地回退到创建 post_likes 集合。为什么我说这是正确的?因为它适合您的用例以及功能和非功能需求!

  • 它可以无限扩展(嗯,有一个理论上的限制,但它是巨大的)
  • 易于维护(在 post_idliked_user_id 上创建唯一索引)和使用(用户和帖子都是已知的,因此添加点赞是一个简单的操作)简单插入或更可能是更新插入)
  • 您可以轻松找出哪些用户喜欢哪个帖子以及哪个帖子被哪些用户喜欢

但是,我会稍微扩展该集合,以防止对某些频繁使用案例进行不必要的查询。

现在我们假设帖子标题和用户名无法更改。在这种情况下,以下数据模型可能更有意义

{
_id: new ObjectId(),
"post_id": someValue,
"post_title": "Cool thing",
"liked_user_id": someUserId,
"user_name": "JoeCool"
}

现在假设您要显示所有喜欢帖子的用户的用户名。对于上面的模型,这将是一个相当快的单一查询:

db.post_likes.find(
{"postId":someValue},
{_id:0,user_name:1}
)

如果只存储 ID,这个相当常见的任务将需要至少两个查询,并且考虑到帖子可能有无限数量的点赞者的限制 - 可能巨大内存消耗(您需要将用户 ID 存储在 RAM 中)。

当然,这会导致一些冗余,但即使有数百万人喜欢某个帖子,我们也只是谈论几兆字节的相对便宜(且易于扩展)的磁盘空间,同时获得大量性能在用户体验方面。

现在事情来了:即使用户名和帖子标题可能会发生变化,您也只需进行多次更新:

db.post_likes.update(
{"post_id":someId},
{ $set:{ "post_title":newTitle} },
{ multi: true}
)

您认为需要一段时间才能完成一些相当罕见的事情,例如更改用户名或帖子,以实现极其频繁发生的用例的极快速度。

底线

请记住,MongoDB 是一个面向文档的数据库。因此,请记录您感兴趣的事件以及 future 查询所需的值,并相应地对数据进行建模。

关于mongodb - 大规模与 MongoDB 的多对多关系,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/31888749/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com