mongodb - 在 Web 应用程序中实现类似功能的架构答案

【问题标题】：mongo db - schema for implementing like feature in webappmongodb - 在 Web 应用程序中实现类似功能的架构
【发布时间】：2013-02-04 07:36:51
【问题描述】：

我有一个 mongodb 数据库，其中有 2 个集合。 posts 和 users。

posts json 结构是这样的

{title:"Title", content:"content goes here", postedby: "userid"}

和用户一样

{username:"", name:""}

现在我需要实现一个点赞功能，让用户喜欢帖子。

解决方案 1

我可以在用户中放置一个内部数组

{username:"", name:"", likes:[postid1,postid2..]}

这里的问题是它很容易查询用户喜欢的帖子。但是很难找到喜欢文章的人。

解决方案 2

我可以在帖子中放置一个内部数组

{title:"Title", content:"content goes here", postedby: "userid", like:[userid1,userid2 ..]}

这里的问题是很容易获得喜欢文章的人。但很难查询用户喜欢的帖子。

我该如何解决这个问题？目前我正在考虑两种方式。就像在两个集合中保留内部数组一样。我知道我保留了冗余数据，这是解决此问题的最佳方法吗？

【问题讨论】：

标签： mongodb database nosql

【解决方案1】：

我个人不会在这里选择类似的数组。

当一个人喜欢太多帖子时，喜欢变得失控是很常见的；以至于这可能会阻碍您可以在该文档中存储的顶级用户数据量。

您还必须在这里考虑您的查询模式。您很可能希望对多个用户的点赞数进行某种图形聚合。目前要动态地做这样的事情，你必须使用聚合框架：http://docs.mongodb.org/manual/applications/aggregation/（预聚合报告：http://docs.mongodb.org/manual/use-cases/pre-aggregated-reports/ 在这里也是一个有用的工具，但我会跳过它）使用 $unwind。

$unwind 是一种内存中操作，对于许多用户的远程聚合可能会很慢，特别是如果每个用户至少有 1000 个赞（50x1000 已经突破了$unwind 和帖子@ 的内存限制987654327@$sort，其内存限制为系统内存的 10%）。总而言之，聚合框架不会是查询这些喜欢的性能方法。

尽管如此，MongoDB 可以很容易地存储这个结构，即使是在它的 gorwing 形式中，因为子文档对于每个条目来说可能是 12 个字节，所以你可以使用 2 个大小（http://docs.mongodb.org/manual/reference/command/collMod/#usePowerOf2Sizes）的幂分配来解决你通常会遇到的问题（碎片化）使用结构。

因此，考虑到这一点，我会将喜欢的内容保存在单独的集合中。确实，您将失去在用户文档中包含喜欢的单次往返表示，但我相信我上面所说的值得付出代价。

【讨论】：

你能告诉我在单独的类似集合的情况下我应该有的模式吗？
@ravisuhag 由于用户可以有大量的赞，我可能会将这些赞自己放入一个单独的集合中，该集合的形式为{_id:(), user_id: (), media_id: (), collection: (), date_liked: ()}，集合字段将允许您喜欢多个媒体项目，即墙上的帖子和视频。

【解决方案2】：

要问自己的一个重要问题是获取这些数据需要哪些不同的方法？

您可以在第一种情况下使用user.find({"likes":postId}) 查询喜欢特定页面的用户，在第二种情况下使用相反的查询。但这是个好主意吗？您希望避免在 MongoDB 中不断增长的文档，而且您可能不想知道特定用户所有他们喜欢的页面，以及特定页面所有用户喜欢。

那么，如何将点赞保存在他们自己的收藏中，并且只在用户和页面收藏中保留聚合（即计数）？您还可以选择在页面中保留最近的“N”个赞或对您的应用程序及其性能最有用的任何其他内容。

在不了解用例（即读写模式）及其相关要求的情况下，几乎不可能在 MongoDB 中设计“理想”模式。

【讨论】：

【解决方案3】：

我认为只在 post 文档中保留 like 数组就足够了。

您可以使用like 字段获取用户喜欢的帖子。如果您在类似字段上有索引，性能也会很好。

唯一的缺点是，使用这种方法，post 对象的大小会根据类似数组的长度而变化。 Mongo 不是很擅长处理这类数据结构，所以如果你对一个帖子有数千个赞，保留所有 id 可能会降低查询性能，但一般来说帖子没有那么多赞，总的来说你的我相信系统会正常工作。您可能会考虑对帖子的点赞 id 数量进行限制（例如保留最后 1000 个用户 id）以确保文档的大小不会过度增长。

【讨论】：