5

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

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

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

一些额外的想法：

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

也可以看看：

编辑：

在对此进行了一些经验经验之后，我不得不得出结论，答案“不是很有效”。有关说明，请参阅https://stackoverflow.com/a/21835534/586086。

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

4

1 回答 1

1

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

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

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

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

还要看看这个关于大量收藏的优秀答案，引擎盖下做了什么。

于 2013-12-20T10:01:06.603 回答