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