我有一个服务器存储内容5,000个文档。假设我有 100 万用户，他们都按照自己的节奏查询 50 个新文档，直到看到所有内容为止。
我想确保每个用户只看到内容并与之互动一次，再也不会像 Tinder 那样。
我的第一个想法是用看过该文档的用户的用户 ID 列表标记每个文档。但是，这个列表会变得很长...就像每个文档包含 100 万个用户 ID 的列表一样 - 但这听起来确实会降低查询性能。
有没有人对我如何将内容仅一次返回给用户并且再也不会返回有更好的想法。
附言我打算用mongoDB进行构建
P.P.S我想过制作一个"文档ID-seen"列表并将其附加到用户的文档，然后该用户进行的每个查询都会"过滤"出与"文档IDS-seen"匹配的结果，但同样的挑战是，随着用户不断交互并引入新内容，查询长度将线性增长。
解决方案取决于"按照自己的节奏"的确切含义。
您的第二篇帖子建议时间表取决于用户，但她将按照您的应用程序确定的顺序显示文档，例如按照新闻创建时间戳的顺序获取新闻项目。在这种情况下，时间戳或自动增量解决方案将起作用，它对数据量和查询复杂性的影响很小。
但是，如果用户还可以选择要查看的文档，这将不再起作用，因为已查看的文档可能分散在整个文档集中。有效处理此问题的解决方案包括两个设计理念：
（a） 想象一下，大多数用户在某一特定时间点查看了整个文档集的一小部分还是大部分。如果特定用户预计只有一小部分文档感兴趣，则用户查看的文档计数将相当小。（例如，假设文档是关于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"之后发出查询，然后在返回结果时，我会使用新的时间戳 X 再次更新我的"用户"表。
或者"x"不能是时间戳，"x"可能只是一个自动递增的id