web-dev-qa-db-ja.com

ZeroMQの代わりにDDSを使用する理由/理由

私は以下を読みました：

  1. DDS vs AMQP vs 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. DDS（ZMQではなく）を使用する明確な目的はありますか？

ありがとう

ipczeromqdata-distribution-service
19
user3668129

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

最初のいくつかの説明：

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

（2）あなたが提供した最初の参考文献には客観的な情報があまり見つかりませんでした。重要な点は、DDSがそのアプリケーションに最適であるように思われ、DDSがどの程度広く使用されているかについて懸念があったことであり、ACからの回答で明らかになりました。しかし、議論は少し主観的なようでした。特定の製品のコードベースに対する誰かの主観的な調査に基づいて、ACの投稿に対して否定的な回答がありました。否定的なコメントを投稿した人が有効なポイントを持っていたとしても、コメントは1つの特定のDDS実装/製品にのみ適用され、DDS一般には適用されません。個人的に私はそのコメントにあまり信憑性を与えません、その口調はあまりにも敵対的であり、述べられた事実だけに基づくことはできません。

（3）APIの明確さ/単純さについて。コメントは、2番目のリファレンスで提供したベンチマークの例に基づいていますか？このコードは、標準のDDSAPIを使用していません。 OCI（その記事を書いた会社）がなぜそのようにしたのかはわかりません-おそらく彼らは他の以前のコードを採用したのでしょう。

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

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

特定の質問に答えます。

1。 DDSを使用する方がよい場合

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

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

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

いくつかの重要な違い：

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

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

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

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

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

それに関連します。私が正しく理解していれば、ZeroMQのコア実装は1つ（githubにあるもの）だけであり、その背後にあるのは会社（iMatix）だけです。そこから、コア（libzmq）で開発作業のほとんどを行っているのは4人のコミッターだけのようです。 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 ComputingIncの「OpenDDS」実装用であることに注意してください。私の知る限り、これが最速のDDS実装の1つであるとは知られていない。 RTI Connext DDS（私たちの実装）、PrimsTechのOpenSplice DDS、TwinOaksのCoreDXDDSなどの他のいくつかをご覧になることをお勧めします。もちろん、結果は実際に使用されるテスト、ネットワーク、およびコンピューターに大きく依存しますが、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を使用する明確な目的はありますか？

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

ジェラルド

51
Gerardo Pardo