5

Meteor の DDP プロトコルは、少量のデータ コレクションをサーバーからブラウザー ベースのクライアントに同期するのに非常に適しています。これにより、処理されるデータの量が本質的に制限されます。

ただし、あるサーバーから別のサーバーに大規模なコレクションを同期するために Meteor が使用されている状況や、ある MongoDB を別のサーバーと同期するために DDP プロトコル自体が使用されている状況を考えてみてください。

この場合、DDP はどのくらい効率的ですか (計算上)? 複数のクライアントにどの程度拡張できますか? パフォーマンスの制限は帯域幅のみですか、それとも DDP は一部の CPU バウンドにも影響しますか? 現在、DDP で合理的に同期できるデータの最大量はどれくらいですか? DDP はこれを行うための間違ったアプローチなのでしょうか (以下の参考文献を参照)。

いくつかの追加の考え:

  • 私の知る限り、現在のバージョンの DDP は各クライアントのコレクション全体を追跡しているため、漸近的に非常に効率的とは言えません。
  • スマート コレクションは、サーバーからクライアントへの同期コレクションのパフォーマンスを向上させるために作成されました。しかし、これが DDP を改善しているのか、それとも他の何かを改善しているのかは不明です。

以下も参照してください。

編集：

これに関するいくつかの経験的な経験の後、答えは「あまり効率的ではない」と結論付けなければなりません。説明については、 https://stackoverflow.com/a/21835534/586086を参照してください。

Meteor 開発者との話し合いによると、この問題は将来的に DDP とパブリッシュ/サブスクライブ API のリビジョンで対処され、それによってマージ ボックスが削除され、クライアントがマージを処理することが示されました。これにより、サーバーの CPU/メモリが節約され、より大きなデータセットをネットワーク経由で送信できるようになります。

4

1 に答える 1

1

基本的には、クライアントの数よりも、何をどのようにクライアントに公開するかが重要です。インデックスが作成されている場合、リクエストは通常​​ log2(N) で処理されるため、(最悪の場合) コレクション全体が変更された場合でも、サーバーが結果セットを再計算するのは非常に簡単です。したがって、サーバー側からは、クライアントに公開する新しい結果セットを非常に迅速に取得できます (既存の結果セットから変更された場合)。

本当の問題 (そして一般的なエラー) は、(以前の自動公開のように) すべてをクライアントに公開するときに発生します。そのため、クライアントが見るべきものだけを提供するように、賢明に公開してください。不要なフィールドを隠しているドキュメントを削除するか、使用パラメータのデータ スコープに固有のパブリケーションを作成して、クライアントに送信する結果セットを減らすことができます。

データの反応性 (パブリケーションにバインドされたセッション パラメーター) も注意して処理する必要があります。公開するセット)。meteor を介して不動産サービスを構築しようとすると、データセットが数ギガバイトを超えるため、オーバーロードされたデータでパイプをブロックせずにこれを処理するのは非常に困難でした。

帯域幅に関しては、DDP は非常に優れています。これは、巧妙なエントリの更新 (ドキュメント全体ではなくフィールドの変更のみを送信する) をサポートし、アイテムの移動 (サーバー側の並べ替え) がサポートされる (予定) ためです。

また、内部で行われている巨大なコレクションに関するこの優れた回答もご覧ください。

于 2013-12-20T10:01:06.603 に答える