问题描述
是否可以将变更流广泛使用？我想看许多带有各种参数的文档的收藏。这样做的目的是允许多个用户观看他们感兴趣的数据。因此，不仅要显示少量实时更新，例如来自单个集合或其他任何集合的一些库存数据，但允许现代Web应用程序是实时的。我偶然发现了一些讨论，例如this one表示该功能不适用于该目的。
因此，请想象实现众所周知的社交网络。每个用户都希望获得有关以下方面的实时数据：（1）通知，（2）在线朋友，（3）朋友请求，（4）新闻提要，（5）新闻提要帖子的评论（每个帖子可能一个？）。这样每个用户至少要有5个开放变更流。服务是否已连接，例如10000个用户，它可以产生50000个活动更改流。
此机制是否已准备好承受此类负载？如果我了解the discussion（以及其他一些知识），则每个变更流观察者都会创建一个连接。拥有数以万计的连接可以吗？它似乎不是一个好的设计。似乎最好观察每个集合并在应用程序服务器上进行过滤，但这更多的是数据库服务器的工作。
有没有办法使用mongo db处理此类负载？
解决方法
每个更改流都需要连接到服务器。假设您的10000个活跃用户将要执行登录，发布，阅读，评论他人的事情，管理朋友列表等操作，那么实际上每个用户可能需要10个以上的连接。
每个更改流本质上都是一个聚合，可在操作日志上维护一个游标。只要服务器有足够的大小来处理，那应该就可以很好地工作：
- 100,000个同时连接
- 说明50,000个长时间运行的游标 每秒
- 这些变化流的每秒10万次查询
- 其他非变更流读写所需的查询速率如何
在MongoDB Atlas上，您至少需要一个M140实例来处理该数量的连接，价格约为每月1万美元。
在该价格点上，设计一种发布/订阅通知服务可能会更具成本效益，该服务总共使用5个更改流来监视不同类型的更改，并通过推送机制将其交付给用户，而不是而不是让每个用户都直接轮询数据库。