MongoDB ChangeStream 性能

Question

是否可以广泛使用变更流？我想观看许多带有各种参数的文档的集合。这个想法是允许多个用户观看他们感兴趣的数据。因此，不仅要显示一些实时更新，例如来自单个集合或其他内容的一些股票数据，而且要允许现代 Web 应用程序是实时的时间。我偶然发现了一些讨论，例如这个讨论表明该功能不可用于此类目的。

想象一下实施众所周知的社交网络。每个用户都希望获得以下方面的实时数据：(1) 通知、(2) 在线好友、(3) 好友请求、(4) 新闻源、(5) 对新闻源帖子的评论（也许每个帖子一个？）。这使得每个用户至少有 5 个开放的变更流。如果一项服务连接了 10000 个用户，那么它会产生 50000 个活动变更流。

该机制是否准备好承受这样的负载？如果我理解了讨论（以及其他一些讨论），那么每个变更流观察者都会创建一个连接。拥有数万个连接可以吗？这似乎不是一个好的设计。似乎最好在应用程序服务器上监视每个集合并进行过滤，但这更多是数据库服务器的工作。

有没有办法如何使用 mongo db 处理这样的负载？

Answer 1

每个更改流都需要连接到服务器。假设您的 10000 个活跃用户要执行诸如登录、发布内容、阅读内容、评论其他人的内容、管理朋友列表等操作。您实际上可能需要每个用户 10 个连接。

每个更改流本质上是一个聚合，它在操作日志上维护一个游标。只要服务器有足够的大小来处理：

• 100,000 个同时连接
• 50,000 个长时间运行游标的状态
• 这些变更流每秒有数千次查询
• 其他非变更流读写所需的查询速率

在 MongoDB Atlas 上，您至少需要一个 M140 实例来处理如此数量的连接，价格标签约为每月 1 万美元。

在这个价位上，设计一个发布/订阅通知服务可能会更具成本效益，该服务总共使用 5 个更改流来监视不同类型的更改，并通过推送机制将这些更改传递给用户，而不是让每个更改都用户直接轮询数据库。