刷卡式应用的Mongodb模式设计

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

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

• 在主页上，用户首先查询帖子列表
• 列表应按日期按逆时间顺序排序，或按某种内部分数排序，以确定活跃帖子（有大量投票或评论等）
• 每一篇文章都会以卡片状的打火机或果冻式提要的形式一个接一个地展示给用户
• 对于每张卡，用户可以跳过或投票
• 当用户使用所有已取回的卡片并再次查询下一个项目时，当前用户跳过或已投票的卡片不应再次出现

这里的要点是，用户可能会有大量被跳过或投票的帖子，因为用户只能在主页上跳过或投票一篇帖子。（用户可以在其个人资料中浏览这些已处理的项目）

我简单想到的方法是

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

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

2.将投票或跳过帖子的用户的所有用户ID嵌入到数组中，并使用$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中，对于创建的每一篇文章，都会有太多的写操作，而且效率不高

---

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

在关系数据库上，我将使用方法1。这是一个显而易见的选择，因为您有很好的SQL操作符来完成任务，并且可以轻松地优化查询

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