meteor - Meteor 的 DDP 在同步大型集合方面的效率如何？

Question

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

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

在这种情况下，DDP 的效率如何(计算上)？它对多个客户端的扩展能力如何？对性能的限制是仅带宽还是 DDP 也会达到某些 CPU 限制？目前可以通过 DDP 合理同步的最大数据量是多少？DDP 是否是执行此操作的错误方法(请参阅下面的引用资料)？

一些额外的想法:

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

另请参阅:

• How to implement real-time replication of MongoDB (or CouchDB) to many remote clients
• DDP vs Straight MongoDB access for synching large amounts of data

编辑:

经过一些经验之后，我得出的结论是，答案“不是很有效”。请参阅https://stackoverflow.com/a/21835534/586086 进行解释。

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

Answer 1

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

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

数据 react 性(绑定(bind)在发布上的 session 参数)也应该小心处理，例如，如果您每次在搜索字段中按下某个键时都发送一个请求，您可能会很快使连接过载(仍然强烈依赖于您要发布的集合的大小)。我们必须解决这个问题，试图通过 meteor 构建房地产服务，数据集超过几千兆字节，在不阻塞管道的情况下处理这个问题非常具有挑战性。

就带宽而言，DDP 非常好，因为它确实支持巧妙的条目更新(仅发送字段更改而不是整个文档)，支持移动项目(服务器端重新排序)。

另请查看this excellent answer关于庞大的收藏，幕后是做什么的。