And*_*Mao 5 publish-subscribe database-replication meteor ddp
Meteor的DDP协议非常适用于将一小部分数据从服务器同步到基于浏览器的客户端,这本身就限制了处理的数据量.
但是,请考虑Meteor用于将大型集合从一个服务器同步到另一个服务器的情况,或者仅使用DDP协议本身将一个MongoDB与另一个服务器同步.
在这种情况下(计算上)DDP的效率如何？它如何扩展到几个客户？性能仅限于带宽还是DDP也会受到一些CPU限制？现在可以通过DDP合理同步的最大数据量是多少？DDP是否是这样做的错误方法(参见下面的参考资料)？
一些额外的想法:
也可以看看:
编辑:
经过一些实证经验,我必须得出结论,答案是"效率不高".有关说明,请参阅/sf/answers/1528487411/.
与Meteor开发人员的讨论表明,将来通过修订DDP和发布 - 订阅API来解决此问题,合并框将被删除,客户端将处理合并.这将节省服务器上的CPU /内存,并允许通过线路发送更大的数据集.
基本上，这更多的是向客户发布内容和方式的问题，而不是客户数量的问题。如果有索引，请求通常在 log2(N) 中处理，因此即使（在最坏的情况下）整个集合发生变化，服务器也很容易重新计算结果集。因此，从服务器端，您可以非常快速地获取新的结果集以发布到客户端（如果它们与已有的结果集发生了更改）。
当您将所有内容发布给客户（就像以前的自动发布一样）时，真正的问题（也是常见的错误）就会出现，因此明智地发布内容，以便您只提供客户应该看到的内容。您可以修剪隐藏无用字段的文档，也可以通过创建具有特定于您的数据使用范围参数的发布来减少发送给客户端的结果集。
数据反应性（绑定在发布上的会话参数）也应该小心处理，例如，如果您每次在搜索字段中按下某个键时都发送一个请求，您可能会很快使连接过载（仍然强烈取决于您正在发布的集合）。我们必须解决这个问题，试图通过流星构建房地产服务，数据集超过几千兆字节，在不阻塞过载数据管道的情况下处理这个问题非常具有挑战性。
就带宽而言，DDP 非常好，因为它确实支持巧妙的条目更新（仅发送字段更改而不是整个文档），支持移动项目（服务器端重新排序）。
另请看一下这个关于大量收藏的优秀答案，以及幕后的工作。
| 归档时间： |
|
| 查看次数： |
1633 次 |
| 最近记录： |