MongoDB ChangeStream性能

Question

是否可以使用更改流进行广泛使用？我想看许多包含各种参数的文档的集合。这样做的目的是允许多个用户观看他们感兴趣的数据。因此，不仅要显示很少的实时更新，例如来自单个集合或其他方面的一些股票数据，而且允许一个现代web应用程序是实时的。我无意中发现了一些讨论，例如this one，它表明该特性不能用于这样的目的。

所以想象一下，实现大家熟知的社交网络。每个用户都希望有关于(1)通知，(2)在线朋友，(3)朋友请求，(4)新闻提要，(5)对新闻提要的评论(每个帖子可能有一个？)的实时数据。这使得每个用户至少有5个打开的更改流。如果一个服务已经连接到例如10000个用户，它就会产生50000个活动的更改流。

这个装置能承受这样的负荷吗？如果我理解the discussion (以及其他一些)，那么每个更改流观察者都会创建一个连接。有成千上万的联系还行吗？这似乎不是一个好的设计。查看每个集合并在应用程序服务器上进行筛选似乎更好，但这更像是数据库服务器的工作。

有办法用mongo db来处理这样的负载吗？

Answer 1

每个更改流都需要连接到服务器。假设您的10000名活跃用户将进行登录、发布、阅读、评论他人的事情、管理朋友列表等，那么您实际上可能需要更多的每个用户的10个连接。

每个更改流本质上都是一个聚合，它维护操作日志上的游标。只要服务器的大小足以处理以下问题，它就应该工作得很好：

为50,000个长期运行的游标同时执行connections

• state 100,000个
• 10s每秒有数千次查询，对于这些变化的streams
• whatever查询速率，其他不改变的读写将需要。

在MongoDB地图集上，您至少需要一个M140实例来处理这些连接，每个月的价格大约是10,000美元。

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