高效查询设计答案

【问题标题】：Design for efficient querying高效查询设计
【发布时间】：2018-08-19 19:52:23
【问题描述】：

我有一个 NoSQL 数据库，其中包含 User 集合和 Post 集合。每个User 有一个Post 并且可以关注其他Users（与他们的朋友）。

User 只能查看他以前未查看过的朋友的Post。一旦被查看，它就不再显示给他。

我正在尝试找出一种方法来设计此要求，以便有效地检索 User 尚未查看的 Posts。

我有两个想法，似乎都不是很有效：

在User 下创建一个名为NonViewedPosts 的子集合，其中每次朋友发帖时，都会在该子集合下添加他们朋友的帖子ID。当该用户查看该帖子时，它的条目将被删除。但这意味着每当用户发帖时，他们必须将自己添加到所有朋友NotViewedPosts 子集合中。如果他们有很多朋友，这可能是低效的
在Post 下有一个名为Viewed 的子集合，该集合开始为空，当帖子被查看时，它会被填满。然后我必须查询Viewed，看看我是否发现自己在每个朋友发布的集合中。如果我的朋友很多，如果我的朋友有很多观点，那么这也是低效的

还有其他我没有想到的解决方案吗？

【问题讨论】：

或者在用户查看帖子后在您修改的架构中添加一个新列怎么样？当您阅读时，您可以编写一个查询，根据该列过滤掉结果
@RamkumarVenkataraman 我正在处理带有列的表格上的文档和集合，所以我认为这个想法有点像我在帖子中提到的第二个想法。我不认为我可以在 Post 下添加单个属性（列）来处理每个朋友的视图状态。可能我没看懂

【解决方案1】：

在构建这样的系统时，您几乎应该始终尝试针对读取情况进行优化，而不是针对写入情况进行优化。在这种情况下，您的读取仍将是写入，但您仍希望针对用户“阅读”的情况进行优化，即寻找要阅读的新帖子。正确的？阅读场景可能比发帖场景更常见。

因此，将向推送模型优化（场景 1）。在任何情况下，您都不必针对其中一个进行优化。您将不得不推送或拉取有关朋友帖子的信息。

【讨论】：

没错，“读”比“写”要频繁得多。我只是想知道是否有什么我没想到的东西可以使读取查询更简单。方案 1 听起来是不是一个糟糕的设计？假设一个受欢迎的用户（名人）有 100,000 个关注者，那么他们将不得不写信给 100,000 个不同用户的“NonViewedPosts”子集合？
现在我正在考虑它，我不确定阅读是否会更频繁。这种情况的阅读实际上只需要在我的应用程序启动时发生（获取所有未查看的帖子）。发布后，将不再有大量读取，只有新帖子的文档侦听器，从那时起，用户发布（写入）的频率会很高，直到重新启动应用程序。
您可能正在考虑读取内容以查看内容。用户可能会阅读很多次以寻找要查看的新内容。其中大部分将是空的，但它们仍然会产生读取成本。