22

私は以下を読みました：

  1. DDS 対 AMQP 対 ZeroMQ
  2. http://mnb.ociweb.com/mnb/MiddlewareNewsBrief-201004.html

また、zmq の代わりに DDS を使用する利点はないようです。

  1. zmq のレイテンシーはより優れています。
  2. ZMQのAPIはクリアでシンプルな気がします。
  3. スレッド/プロセス/ステーション間でデータを転送するために ZMQ を使用できません。

そう：

  1. DDS を使用する方が良いのはいつですか?
  2. ZMQよりも優れた DDS のパフォーマンスはありますか?
  3. (ZMQ ではなく) DDS を使用する明確な目的はありますか?

ありがとう

4

1 に答える 1

61

DDS の実装者/ベンダーとしての私の (確かに偏った) 経験では、多くのアプリケーションが、ZeroMQ を含むミドルウェア技術よりも DDS を使用することの大きな利点を見出しています。実際、ZeroMQ よりも DDS を使用した「重要なアプリケーション」の方がはるかに多くなっています...

最初にいくつかの説明：

(1) DDS とその下で使用される RTPS プロトコルは標準であり、特定の製品ではありません。これらの標準には多くの実装があります。私の知る限り、これらの標準を実装する独立した製品とコードベースを持つ企業が少なくとも 9 社あります。DDS と ZeroMQ の「パフォーマンス」について話しても意味がありません。特定の実装のパフォーマンスについてしか話せません。パフォーマンスの問題については後で説明しますが、その観点からだけでも、「zmq のレイテンシーの方が優れている」というあなたの発言は明らかに間違っています。もちろん、反対のステートメントも同様に間違っています。

(2) あなたが提供した最初のリファレンスには客観的な情報があまり見つかりませんでした. 主なポイントは、DDS がそのアプリケーションに最適であると思われることであり、AC からの返信で明らかになったように、DDS がどの程度広く使用されているかについて懸念がありました。しかし、議論は少し主観的だったようです。特定の製品のコードベースに関する誰かの主観的な調査に基づいて、AC の投稿に対して否定的な回答がありました。否定的なコメントを投稿した人が正当な意見を持っていると仮定しても、コメントは特定の DDS 実装/製品にのみ適用され、DDS 一般には適用されません。個人的には、そのコメントを信用するつもりはありません。その口調は、述べられた事実だけに基づくには敵対的すぎるように思えます。

(3) API の明快さ/単純さについて。あなたのコメントは、2 番目のリファレンスで提供したベンチマークの例に基づいていますか? このコードは、標準の DDS API を使用していません。なぜ OCI (その記事を書いた会社) がそのようなことをしたのか、私にはよくわかりません。

DDS 仕様に準拠している API の例を見るのに適した場所は次のとおりです。

いずれにせよ、後で言及するように、DDS と ZeroMQ によって提供される抽象化のレイヤーはまったく異なるため、API を直接比較することはできません...

具体的な質問にお答えします。

1. DDS の使用が適しているのはどのような場合ですか?

これほど幅広い質問に対して、簡潔で客観的な回答を提供することは困難です。ZeroMQ は良い製品であり、多くの人が満足していると確信しています。DDSについても同じことが言えます。

最善の方法は、違いのいくつかを指摘し、人々に何が重要かを判断させることだと思います.

DDS と ZeroMQ は、ガバナンス、エコシステム、機能、さらには抽象化レイヤーの点で異なります。

いくつかの重要な違い:

1.1 ガバナンス、基準、エコシステム

DDS と RTPS は、Object Management Group (OMG) によるオープンな国際標準です。ZeroMQ は「貢献者によって制御される緩い構造」です

これは、仕様とその進化、および IPR ルールを制御するオープン ガバナンスと明確な OMG プロセスがあることを意味します。

ZeroMQ IPR はあまり明確でない IMO です。彼らの Web ページ ( http://zeromq.org/docs:features ) から、彼らは「ZeroMQ の libzmq コアはその貢献者によって所有されている」と述べており、「ZeroMQ 組織は明確な権力構造のない緩い連合であり、ほとんどが GitHub に住んでいます。組織の wiki ページでは、興味深い仕事を持ち込むだけで誰でもオーナーズ チームに参加できる方法が説明されています。」

この「緩い構造」は、IPR 系統、保証、補償などを気にするユーザーにとっては、より問題になる可能性があります。

それに関連して。私が正しく理解していれば、コアとなる ZeroMQ 実装は 1 つだけ (github のもの) であり、それを支える唯一の会社 (iMatix) があります。そこから、わずか 4 人のコミッターがコア (libzmq) でほとんどの開発作業を行っているようです。iMatix が買収されるか、そのビジネス モデルを変更することが決定された場合、または主要なコミッターが関心を失った場合、ユーザーはコードベース自体をサポートする以外に頼ることはほとんどありません。

もちろん、コードの共有に基づいて成功したプロジェクトや技術は数多くあります。一方、独立した製品、コードベース、およびビジネスモデルと競合する企業のエコシステムを持つことは、テクノロジーの将来に十分な保証を提供します...それはすべて、コミュニティとエコシステムがどれほど大きいか、およびユーザーがどれほどリスクを嫌うかによって異なります.

1.2 機能と抽象化レイヤー

DDS と ZeroMQ はどちらも、publish-subscribe や Request-Reply などのパターンをサポートしています (これは DDS に新たに追加された、いわゆる DDS-RPC です)。しかし、一般的に言えば、DDS の抽象化層はより上位にあります。つまり、ミドルウェアはアプリケーションに対して「自動的に」より多くのことを行います。具体的には。

DDS は自動検出を提供します

DDS では、トピック名をパブリッシュ/サブスクライブするだけです。IP アドレス、コンピューター名、またはポートを提供する必要はありません。それはすべて組み込みの検出によって処理されます。また、追加サービスなしで自動的に実行します。これは、アプリケーションを再コンパイルまたは再構成せずに再デプロイおよび統合できることを意味します。

ZeroMQ は下位レベルです。ポート、IP アドレスなどを指定する必要があります。

DDS pub-sub はデータ中心です。

アプリケーションはトピックに発行できますが、関連付けられたデータは複数のデータ オブジェクトに更新され、それぞれがキー属性によって識別されます。たとえば、飛行機の位置を公開する場合、各更新は「飛行機 ID」を識別でき、ミドルウェアは履歴を提供し、各飛行機の QoS や更新レートなどを個別に適用できます。ミドルウェアは、新しい飛行機がシステムに出現したり、システムから消えたりしたことを理解し、通信します。

上記に関連して、DDS はアプリケーションに関連するデータのキャッシュを保持できます。これは、適切と思われるときに (キーまたはコンテンツによって) 照会できます。たとえば、飛行機の最後の 5 つの位置を読み取ることができます。アプリケーションには変更が通知されますが、すぐに使用する必要はありません。これは、アプリケーション開発者が記述する必要があるコードの量を減らすのにも役立ちます。

DDS は「アプリケーション」QoS のサポートを強化

DDS は、信頼性、エンドポイントの有効性、メッセージの持続性と遅延参加者への配信、メッセージの有効期限、フェールオーバー、定期的な更新の監視、時間ベースのフィルタリング、順序付けなど、22 を超えるメッセージおよびデータ配信の QoS ポリシーをサポートしています。シンプルな QoS ポリシー設定によって構成されます。アプリケーションは同じ読み取り/書き込み API を使用し、追加の作業はすべてその下で行われます。

ZeroMQ は、ビルディング ブロックとパターンを提供することで、この問題に取り組みます。非常に柔軟ですが、より高いレベルの動作を実現するには、アプリケーションでさまざまなパターンをプログラム、アセンブル、調整する必要があります。たとえば、信頼できる pub-sub を取得するには、http://zguide.zeromq.org/page:all#toc119で説明されているように、複数のパターンを組み合わせる必要があります。

DDS は、コンテンツ フィルタリング、時間フィルタリング、パーティション、ドメインなどの追加機能をサポートしています。

これらは ZeroMQ では利用できません。アプリケーション層で構築する必要があります。

DDS は型システムを提供し、型の拡張性と可変性をサポートします

同様の機能を得るには、ZeroMQ を Google プロトコル バッファなどの他のパッケージと組み合わせる必要があります。

安全

認証、暗号化、署名、キー配布、安全なマルチキャストなどを含む、きめの細かい (トピック レベルの) セキュリティを提供する DDS-Security 仕様があります。

2. ZMQ よりも優れた DDS のパフォーマンスはありますか?

参照するベンチマークは、Object Computing Inc の「OpenDDS」実装用であることに注意してください。私の知る限り、これが最速の DDS 実装の 1 つであるとは知られていません。RTI Connext DDS (私たちの実装)、PrimsTech の OpenSplice DDS、TwinOaks の CoreDX DDS など、他のいくつかを検討することをお勧めします。もちろん、結果は実際のテスト、ネットワーク、および使用するコンピューターに大きく依存しますが、C++ を使用した高速な DDS 実装の典型的なレイテンシ パフォーマンスは、180 マイクロ秒ではなく 50 マイクロ秒のオーダーです)。https://www.rti.com/products/dds/benchmarks.html#CPPLATENCYを参照

DDS や ZeroMQ などのミドルウェア レイヤーは、UDP や TCP などの上で実行されるため、基盤となるネットワークが実行できることによって制限され、単純なケースではあまり変わらないと思われます。生の輸送。

違いは、提供するサービスによっても異なります。したがって、同じレベルのサービスで得られるものを比較する必要があります。たとえば、多くのコンシューマーに確実にスケーリングして公開する、情報の優先順位を付ける、UDP を介して複数のフローと大きなデータを送信する (TCP のヘッドオブライン ブロッキングを回避するため) などです。

あなたが参照している OpenDDS の研究と、さまざまな DDS 実装の相対的なパフォーマンス ( http://www.dre.vanderbilt.edu/DDS/ ) に基づいて、私はリンゴからリンゴへのテストでよりパフォーマンスの良い実装を期待します。 DDS は、ZeroMQ と同じかそれを超えます。

つまり、「最高のパフォーマンス」を提供するミドルウェアを選択する人はめったにいません。そうでなければ、誰も Web サービスや HTTP を使用しないでしょう。選択は多くの要因に基づいており、アプリケーションのニーズを満たすのに必要なパフォーマンスだけが必要です。堅牢性、スケーラビリティ、サポート、リスク、保守性、ドメインへのプログラミング モデルの適合性、総所有コストなどは、通常、決定においてより重要です。

3. (ZMQ ではなく) DDS を使用する明確な目的はありますか?

そうです... 多くのアプリケーションでは、パフォーマンス、スケーラビリティ、機能、アプリケーションのシンプルさ、堅牢性、リスクの軽減、および総所有コストの点で最良のトレードオフを提供します。過去数年間で、何千ものプロジェクトがその結論に達しました:)

ジェラルド

于 2015-01-05T03:12:53.527 に答える