我有一台服务器存储内容5,000个文档。假设我有100万用户，他们都以自己的速度查询50个新文档，直到看到所有内容。从不向同一用户显示两次相同的文档
我想确保每个用户只查看一次内容并与内容进行交互，而不再像Tinder那样。
我的第一个想法是为每个文档添加一个已经看过该文档的用户的用户ID列表。然而，这个列表会变得非常长......就像每个文档有100万个用户标识符的列表 - 但是这听起来像是它会真正杀死查询性能。
有没有人有任何更好的想法，我可以如何返回内容给用户只有一次，永远不会。
PS我就这样打造出来的具有MongoDB的
PPS计划我想到制作“文件的IDS-看到”清单，并连接，为用户的文档，然后通过您的每笔查询用户'过滤'出与'document-ids-seen'相匹配的结果，但是同样的挑战在这里，查询长度将随着用户不断交互并引入新内容而线性增长。
的解决方案取决于的确切含义“按照自己的节奏。”
你的第二篇文章建议时间表取决于用户，但她将按照你的应用程序确定的顺序显示文档，例如，按照新闻创建时间戳的顺序获取新闻项目。在这种情况下，您的时间戳或自动增量解决方案将起作用，并且对数据量和查询复杂性只有很小的影响。
然而，如果用户还可以选择要查看的文件，这将不再工作，因为已经浏览的文件，也可以分散在整个文档集。处理这方面的一个有效的解决方案包括两个设计思路：
（一）想象一下，是否大多数用户来说，在给定的时间点，将查看过小或整个文件集的很大一部分。如果预计只有少量文档对特定用户感兴趣，则用户浏览过的文档的数量将会很小。 （例如，假设文件是关于IT和一个用户只想看MongoDB的文档，另一个主要的Linux的文档）。如果所有用户将感兴趣的大部分或全部的文件，那么文件计数特定用户不查看将会很小。 （例如一组的消息称，每个人都试图效仿。）根据是哪种情况，只存储与每个用户，这也将简化查询仍然要查看的文件查看/不查看文档ID的小单子。（b）对于每个用户，不要存储单个文档ID（查看或不查看）的列表，而是存储此类ID的间隔列表。例如，如果您存储了尚未查看的文档的ID，并且某些文档被添加到数据库中，那么当用户打开时，她的最高时间间隔将从(someLowerId, formerHighestId)更新为(someLowerId, currentHighestId)。当用户查看文档时，包含其ID的区间从(lowId, highId)分割为(lowId, viewedId - 1), (viewedId + 1, highId)，其中一个或两个区间可能会变空。包括或排除这些间隔也会简化查询，而不是列出单个ID。
我刚刚有一个想法，即我可以避免内容与用户的交互的多对多关系，如果我在每个文档上放置一个时间戳，并且因此只在一个文档之后查询更多文档特定的时间戳'X'。
其中'X'可以存储在我的'用户'表中。
因此，当打开应用程序时，我会同步我的'用户'表，然后在时间戳'X'后发出查询，然后返回结果时，我会使用新时间更新我的'用户'表-stamp十
或“X”不能成为一个时间戳，“X”可能仅仅是一个自动递增ID
感谢TAM。我喜欢在每个文件上加上时间戳，并且只在某个日期之后“返回”文件。对我而言，如果用户只能在某个特定ID或日期后才能查询，那么用户可能会失去文档，然后他们改变搜索偏好（他们永远不会看到早期的东西有不同的搜索条件），但我认为这是一个小的价格支付 – user1709076