使用mongodb模式/端点设计的Facebook“like”功能

我提出了多种解决方案，但似乎没有一种能经得起未来的考验

让我先迭代我的解决方案

特征的验收标准

用户可以喜欢或不喜欢帖子 用户可以在他已经喜欢的帖子上看到充满激情的内容 假设

有用户收集和后期收集

可能的解决方案 一,。放置喜欢该帖子的用户引用的数组

问题

超级简单，但一旦帖子增长过多，所有查询帖子的用户都会受到影响。还可以在文档中放置潜在的无限数组

二,。将Post引用数组放置到用户

问题

同上，但只有数据不断增长的用户可能会受到影响

三,。与用户和Post的模式类似，并向Post添加计数器

问题

这个文档将快速增长，很多用户每天都会喜欢很多帖子。如何查询用户喜欢哪些帖子？如果此集合增加到数百万个类似文档，该怎么办

到目前为止，我还没有找到正确的答案，起初，我认为1是一个不错的选择，然后很快就改变了主意，改为3，然后我就想——如果每次我发帖子时，从数百万个文档中查询到喜欢的内容变得很快，变得很痛苦，那该怎么办？现在我认为2是更安全的选择，但我可能错了。如果我选择3，我想分离/喜欢和/发布端点，这是另一个问题我将如何查询用户是否喜欢文章列表中的内容？它应该是单独的单端点吗？但每次帖子列表加载时，都会有太多的调用。我很困惑：

---

谢谢阅读。

第三扇门！然后，您将使用一个独特的复合索引和User+Post，以防止重复并加快查询时间

当您查询帖子时，您将希望使用聚合管道，以便可以$lookup查看每个帖子是否存在“like”文档

---

应该可以开始了。

如果是这种情况，我的posts端点很可能会返回类似状态，不会返回纯Post对象，现在我的服务具有依赖性。如何解决这个问题？对，它将以“喜欢的”布尔值添加到您的post对象中。但是你可以通过在管道中使用默认值来保证它的存在。如果你决定保持你的Post对象“纯”，你可以在一秒钟的请求中查询类似的数据。收到帖子后，映射它们的_id，然后立即请求所有类似的数据，使用$in操作符从db查询。我会先使用$lookup。确切地说，我要找的是，在postid数组中选择WHERE，但每个id都相当长，所以当我从客户端查询时，它不会超过url长度限制吗？比如说，我最初收到24篇帖子，我需要用24个ID查询。我将如何做呢？db.Likes.find{post:{$in:[id数组]}；其中“ID数组”是传递给端点的参数。如果你每页的帖子只有10或20篇，你应该没问题。不过，您始终可以发送请求的有效负载/正文。