我有一个存储内容5,000个文件的服务器。假设我有100万用户按照自己的节奏查询50个新文档，直到看到所有内容。
我想确保每个用户只看到内容并与内容互动一次，而不再像Tinder那样。
我的第一个想法是使用已查看文档的用户的用户ID列表标记每个文档。但是，这个列表会变得非常长......就像每个文档的100万用户ID列表一样 - 但这听起来确实会破坏查询性能。
有没有人能够更好地了解我如何才能将内容返回给用户一次又一次。
p.s我打算用mongoDB
进行构建p.p.s我想要制作一份＆＃39;文件 - ids-seen＆＃39;并将其附加到用户的文档，然后将该用户发出的每个查询＆＃39;过滤＆＃39;输出符合＆＃39; document-ids-seen＆＃39;的结果，但同样的挑战，查询长度会随着用户不断交互和引入新内容而线性增长。
答案 0 :(得分：2)
解决方案取决于＆＃34;在他们自己的节奏＆＃34;的确切含义。
您的第二篇帖子建议时间表取决于用户，但她会按照您的应用程序确定的顺序呈现文档，例如按照新闻创建时间戳的顺序获取新闻。在这种情况下，您的时间戳或自动增量解决方案将起作用，它对数据量和查询复杂性的影响很小。
但是，如果用户也可以选择要查看的文档，则这不再起作用，因为已经查看的文档可能分散在整个文档集中。有效处理这个问题的解决方案包括两个设计思路：
（a）想象一下，在给定的时间点，大多数用户是否会查看整个文档集的一小部分或大部分内容。如果预期特定用户只对少量文档感兴趣，则用户查看的文档数量将相当小。 （例如，假设文档是关于IT的，一个用户只想查看MongoDB文档，另一个用户主要是Linux文档。）如果所有用户都对大多数或所有文档感兴趣，那么特定用户拥有的文档数量未查看会很小。 （例如，每个人都试图遵循的一组新闻。）根据具体情况，每个用户只存储一小部分已查看/未查看的文档ID，这也将简化对仍待查看的文档的查询。
（b）对于每个用户，不要存储单个文档ID列表（已查看或未查看），但列出此类ID的间隔列表。例如，如果您存储尚未查看的文档的ID，并且某些文档已添加到数据库中，则在打开用户时，其最高间隔将从(someLowerId, formerHighestId)更新为(someLowerId, currentHighestId)。当用户查看文档时，包含其ID的间隔将从(lowId, highId)拆分为(lowId, viewedId - 1), (viewedId + 1, highId)，其中一个或两个间隔可能为空。包括或排除这些区间也会简化查询，而不是列出单个ID。
答案 1 :(得分：0)
我只是觉得如果我在每个文档上加上时间戳，我就可以完全避免内容到用户之间的多对多关系，因此只能在特定文档之后查询更多文档时间戳'X'。
'X'可以存储在我的'用户'表中。
因此，在打开应用时，我会同步我的'用户'表，然后在时间戳'X'后发出查询，然后当返回结果时，我会用新的时间再次更新我的'用户'表 - 印章X。
或者'x'不能是时间戳，'x'可能只是一个自动递增的ID