我有一个服务器存储内容 5,000 个文档。假设我有 100 万用户，他们都按照自己的节奏查询 50 个新文档，直到看到所有内容。
我想确保每个用户只看到一次内容并与内容进行交互，并且再也不会像 Tinder 一样。
我的第一个想法是用看过该文档的用户的用户 ID 列表标记每个文档。然而，这个列表会变得很长......就像每个文档有 100 万个用户 ID 的列表 - 但这听起来真的会降低查询性能。
有没有人对我如何将内容返回给用户一次且永不再有更好的想法。
ps 我打算用 mongoDB 做这个构建
pps，我考虑过制作一个“document-ids-seen”列表并将其附加到用户的文档中，然后该用户进行的每个查询“过滤”出与“document-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