用于刷卡式应用程序的 Mongodb 模式设计

Question

设计具有跳过功能的刷卡式应用程序的好方法是什么？

我正在开发的应用程序的核心功能如下。

• 在主页上，用户首先查询帖子列表。
• 列表应该按时间倒序排列，或者根据某种内部分数来决定活跃的帖子(有大量的投票或评论等)
• 每个帖子都以卡片的形式逐一显示给用户，例如 tinder 或果冻式提要。
• 对于每张卡片，用户可以跳过或投票给它。
• 当用户消费所有获取的卡片并再次查询下一个项目时，不应再次出现当前用户跳过或已经投票的卡片。

这里的重点是用户可能有大量跳过或投票的帖子，因为用户只能跳过或投票主页上的帖子。(用户可以在他/她的个人资料中浏览这些已处理的项目)

我简单想到的方法是

1. 将每个用户的跳过或投票的帖子 ID 列表存储在某个地方，并在带有 $nin 运算符的查询中使用它们。

db.posts.find({ _id: {$nin: [postid1,...,postid999]} }).sort({ date: -1 })

2. 将投票或跳过帖子的所有用户的 userId 嵌入到一个数组中，并使用 $ne 运算符进行查询

{ 
  _id: 'postid',
  skipOrVoteUser: ['user1', 'user2' ...... 'user999'],
  date: 1429286816366
}

db.posts.find({ skipOrVoteUser: {$ne: 'user1'} }).sort({ date: -1 })

3.维护每个用户的 feedCache 和写入时的扇出。

提要缓存

{
  userId: 'user1',
  posts: [{id:1, data: {..}}, {id:2, data: {...}},.... {id:3, data: {...}}]
}

操作:-当用户创建帖子时，将帖子的副本写入系统中所有用户的提要缓存。- 从用户的提要缓存中获取帖子。-当用户投票或跳过帖子时，从他/她的提要缓存中删除该帖子。

但是由于用户跳过或投票的帖子列表不断增长，并且随着时间的推移可能会非常大。我担心这个查询对于方法 1 的 $nin 的大量列表来说太慢了。

还有方法 2，因为系统上的所有用户(或许多用户取决于过滤)可以投票或跳过帖子，每个帖子的嵌入式用户数组可能非常大(最大所有用户数)和使用 $ne 的查询性能会很差。

使用方法 3，对于创建的每个帖子，都会有太多的写操作并且效率不高。

设计架构以支持此类功能的好方法是什么？我试过想出好的解决方案，但想不出更好的解决方案。请帮我解决这个问题。谢谢!

Answer 1

在关系数据库上，我会使用方法 1。这是显而易见的选择，因为您有适合该任务的良好 SQL 运算符，并且您可以轻松优化查询。

对于文档数据库，我会选择方法 2。在这种情况下，随着系统的增长，投票/跳过列表很有可能保持相对较小。