meteor 的DDP协议(protocol)非常适合将少量数据从服务器同步到基于浏览器的客户端，这从本质上限制了要处理的数据量。
但是，请考虑使用Meteor将大型集合从一台服务器同步到另一台服务器，或者仅DDP协议(protocol)本身用于将一个MongoDB与另一台MongoDB同步的情况。
(在计算上)DDP在这种情况下的效率如何？它可以很好地扩展到几个客户吗？是对性能的限制仅是带宽，还是DDP也会受到某些CPU的限制？现在可以通过DDP合理地同步的最大数据量是多少？ DDP只是这样做的错误方法(请参见下面的引用资料)吗？
其他一些想法:
也可以看看:
编辑:
经过一些实证经验，我必须得出结论，答案是“不是很有效”。有关说明，请参见 https://stackoverflow.com/a/21835534/586086 。
与Meteor开发人员的讨论表明，将来将通过修订DDP和发布-订阅API来解决此问题，从而将删除合并框，并由客户端进行合并。这将节省服务器上的CPU/内存，并允许通过网络发送更大的数据集。
最佳答案
基本上，更多的是您要发布给客户端的内容和方式，而不是客户端的数量。如果对请求建立索引，通常会在log2(N)中对其进行处理，因此即使整个集合发生变化(在最坏的情况下)，服务器也很容易重新计算结果集。因此，从服务器端，您可以非常快速地将新结果集发布到客户端(如果它们已从现有客户端更改为其他客户端)。
真正的问题(和常见错误)是当您确实将所有内容发布到客户端时(与前一个自动发布一样)，因此，请明智地进行发布，以便仅给出客户端应该看到的内容。您可以通过创建特定于您的数据使用范围参数的发布来修剪隐藏无用字段的文档，或减少结果集以发送给客户端。
数据 react 性( session 参数绑定(bind)到发布上)也应谨慎处理，例如，例如，如果每次在搜索字段中按一个键时都发送请求，则可能会使连接快速过载(仍然强烈依赖于连接的大小您要发布的集合)。我们必须考虑在 meteor 上建立房地产服务的这种尝试，因为数据集超过了数GB，要在不用重载数据阻塞管道的情况下处理这一挑战非常困难。
就带宽而言，DDP非常好，因为它确实支持聪明的条目更新(仅发送字段更改而不是整个文档)，支持(将)支持移动项目(服务器端重新排序)。
还要看看有关大量收藏的this excellent answer，它是在后台进行的。
关于meteor - meteor 的DDP在同步非常大的收藏集方面的效率如何？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/18734507/