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