目前，我们的系统尚未完全规范化，我们使用meteor-publish-composite获取mongodb中的规范化数据。有些模型具有非常少的依赖关系，但是其他模型具有对象数组（即子文档），在获取每个模型时我们订阅的外键很少。
示例是Post，其中包含Comment个子文档的列表，其中每个评论都有一个userId字段。
我的问题是，虽然我知道使用集合挂钩并使用数据非规范化更新集合会更快，但Meteor如何处理同一集合上的多个订阅？
同一个集合上的一百个订阅是否会影响应用程序的速度（显着）？一千个呢？等
答案 0 :(得分：1)
这可能无法完全回答你的问题，但是在花了无数个小时调整大型流星应用程序的性能后，我想我会分享一些我学到的东西。
在Meteor中，当您定义发布时，您正在设置一个反应式查询，当对基础mongo数据的更改导致查询结果发生更改时，该查询将继续将数据推送到订阅的客户端。换句话说，它会设置一个查询，在插入，更新或删除数据时将不断将数据推送到客户端。它执行此操作的机制是在查询上创建observer。
初始化observer时（例如订阅发布时），它将向mongodb查询要发送的初始数据集，然后使用oplog检测前进的更改。幸运的是，如果查询针对相同的集合，相同的选择器和相同的选项，那么meteor能够重新使用现有的观察者进行新的订阅。
这意味着您可以针对许多不同的出版物创建数百个订阅，但如果它们针对同一个集合并使用相同的查询选择器，那么您实际上只有1个observe正在进行中。有关详细信息，我强烈建议您阅读kadira.io中的this article（我从中获取了此答案中使用的信息）。
除此之外，Meteor还能够处理发布同一文档的多个出版物，当发生这种情况时，文档将合并为一个。有关详细信息，请参阅this。
最后，由于Meteor的MergeBox组件，它会通过跟踪所更改的数据与客户端上已有的数据来最小化通过网络发送的数据。< / p>
因此，在您的具体示例中，听起来您将在有效的相同查询上运行多个不同的订阅（因为您只是尝试对数据进行反规范化）和数据集。由于我上面描述的所有优化，我猜想通过采用这种方法你不会受到性能问题的困扰。
我在我的一个应用程序中做过类似的事情，但从来没有遇到任何问题。