Meteor 的 DDP 在同步非常大的集合方面的效率如何？答案

【问题标题】：How efficient is Meteor's DDP at syncing very large collections?Meteor 的 DDP 在同步非常大的集合方面的效率如何？
【发布时间】：2013-09-15 01:59:54
【问题描述】：

Meteor 的 DDP 协议非常适合将少量数据从服务器同步到基于浏览器的客户端，这从本质上限制了处理的数据量。

但是，考虑使用 Meteor 将大型集合从一台服务器同步到另一台服务器的情况，或者仅使用 DDP 协议本身将一个 MongoDB 与另一个同步。

在这种情况下（计算）DDP 的效率如何？它对多个客户的扩展性如何？性能的限制仅仅是带宽还是 DDP 也会受到 CPU 的限制？目前可以通过 DDP 合理同步的最大数据量是多少？ DDP 是否只是这样做的错误方法（请参阅下面的参考资料）？

一些额外的想法：

据我所知，当前版本的 DDP 会跟踪每个客户端的整个集合，因此它不能渐近高效。
创建Smart Collections 是为了提高服务器到客户端同步收集的性能。但我不清楚这是否在改进 DDP 或其他方面。

另见：

编辑：

在这方面的一些经验经验之后，我不得不得出结论，答案是“不是很有效”。请参阅 https://stackoverflow.com/a/21835534/586086 了解说明。

与 Meteor 开发人员的讨论表明，这个问题将在未来通过 DDP 和发布-订阅 API 的修订来解决，其中合并框将被删除，客户端将处理合并。这将节省服务器上的 CPU/内存，并允许通过网络发送更大的数据集。

【问题讨论】：

这可能更适合作为邮件列表的帖子或 gh 问题。我肯定希望看到一些测试/基准来证明一种或另一种方式。

标签： meteor publish-subscribe database-replication ddp

【解决方案1】：

基本上，与客户数量相比，您向客户发布的内容和方式更重要。如果已建立索引，请求通常在 log2(N) 中处理，因此即使（在最坏的情况下）整个集合会发生变化，服务器也很容易重新计算结果集。因此，您可以从服务器端快速获取新的结果集以发布到客户端（如果它们与已有的结果集不同）。

真正的问题（和常见错误）出现在您将所有内容发布到客户端（就像以前的自动发布一样）时，因此请明智地发布，以便您只提供客户端应该看到的内容。您可以修剪隐藏无用字段的文档，或者通过创建具有特定于您的数据使用范围参数的发布来减少发送给客户端的结果集。

还应小心处理数据反应性（绑定在发布上的会话参数），例如，如果您每次在搜索字段中按下一个键时都发送请求，您可能会很快使连接过载（仍然很大程度上取决于您要发布的集合的大小）。我们不得不处理这个尝试在流星上构建房地产服务的问题，数据集超过几 GB，在不阻塞数据超载的管道的情况下处理这个问题非常具有挑战性。

在带宽方面，DDP 相当不错，因为它确实支持智能条目更新（仅发送字段更改而不是整个文档），（将）支持将项目移动到（服务器端重新排序）。

还可以查看 this excellent answer 上有关大量收藏的信息，了解幕后操作。

【讨论】：