メッセージング システムのテーブルに対するキュー [終了]

Question

私はメッセージング システムの良い面と悪い面を経験してきました。 実際の本番環境, そして、よく整理されたテーブルまたはテーブルのスキーマは、他の形式のメッセージング キューよりも単純に優れていることを認めなければなりません。その理由は次のとおりです。

1. データはテーブルに永続的に保存されます。私は、キャッチされなかった例外やその他のバグにより、途中でメッセージが失われたり消えたりする Java (jms) アプリケーションを非常に多く見てきました。
2. 行列はいっぱいになる傾向があります。その代わり、DB ストレージは事実上無限です。
3. テーブルには簡単にアクセスできますが、キューから読み取るには難解なツールを使用する必要があります。

それぞれのアプローチについてどう思いますか?

Answer 1

毎回ビートするというフレーズは、要件が何から始まるかによって完全に異なります。確かに、誰にとっても毎回勝つわけではありません。

すでにデータベースを使用している単一のシステムを構築している場合、非常に高いパフォーマンススループット要件はなく、他のチームやシステムと通信する必要はありません。おそらく正しいでしょう。

シンプルでスループットが低く、ほとんどがシングルスレッドの場合、データベースはメッセージキューの完全に優れた代替手段です。

メッセージキューが輝くのはいつですか

• 高パフォーマンス、高度な同時並行性、およびスケーラブルなロードバランサーが必要なため、多数のサーバー/プロセスで毎秒数万のメッセージを同時に処理できます（数百秒で処理できるデータベーステーブルを使用して、 1つのプロセスがメッセージキューテーブルをロックする傾向があるため、複数のスレッドでの処理は非常に困難です）
• 異なるデータベースを使用して異なるシステム間で通信する必要があります（そのため、システムデータベースへの書き込みアクセスを別のチームの他の人に渡す必要はありません）

単一のデータベース、チーム、およびかなり控えめなパフォーマンス要件を持つ単純なシステムの場合は、必ずデータベースを使用してください。ジョブなどに適したツールを使用します。

ただし、メッセージキューが輝くのは、相互に通信する必要のあるシステムが多数ある大規模な組織です（したがって、ビジネスデータベースを障害の中心点またはバージョンの地獄にしたくない）または高いパフォーマンス要件がある場合。

パフォーマンスに関しては、メッセージキューは常にデータベーステーブルに勝ちます-メッセージキューはジョブ専用に設計されており、悲観的なテーブルロック（キューのデータベース実装に必要）に依存しないため、ロードバランシング）および良好なメッセージキューは、キューへのメッセージの積極的なロードを実行します。データベースのネットワークオーバーヘッドを回避する。

同様に、Webサーバー間でHTTPリクエストのロードバランシングを行うためにデータベースを使用することはありません-遅すぎるため-ロードバランサーに高いパフォーマンス要件がある場合は、データベースも使用しません。

Answer 2

最初にテーブルを使用し、次に理由がある場合（およびその場合）に本格的なmsgキューにリファクタリングしました-設計が合理的であれば簡単です。

最大の利点は、a。）より簡単です（b。結合する他のテーブルがあるため、より良い監査証跡です、c。）データベースツールを本当によく知っている場合、それらはより使いやすいですメッセージキューツール、d。）一般に、アプリに既に存在するコンテキストでテスト/開発環境を設定する方が少し簡単です（同じ知識がある場合）。

ああ、e。）おそらくあなたや他の人にとっては、学習、インストール、設定、管理、サポートするのは別の製品ではありません。

IMPE、それは同じように信頼性が高く、切断可能であり、よりスケーラブルなものが必要な場合は変換できます。

Answer 3

1. データはテーブルに永続的に保存されます。私は、捕捉されなかった例外やその他のバグにより、途中でメッセージが失われたり消えたりする Java (jms) アプリケーションを非常に多く見てきました。

   どの JMS 実装ですか?Sun は、メッセージを失わない信頼性の高いキューを販売しています。おそらく、安っぽい JMS 準拠の製品を購入したばかりかもしれません。IBM の MQ は非常に信頼性が高く、それにアクセスするための JMS ライブラリがあります。

2. 行列はいっぱいになる傾向があります。その代わり、DB ストレージは事実上無限です。

   うーん...キューがいっぱいになると、何かが壊れているように思えます。アプリがクラッシュするのは良いことではありません。キューはそれとはほとんど関係がありません。本当に質の悪い JMS 実装を購入した場合、どこで不満を感じるかがわかります。それは競争の激しい市場です。より良いキューマネージャーを見つけてください。Sun の JCAPS には、非常に優れたキュー マネージャー (以前は SeeBeyond メッセージ キュー) が備わっています。

3. テーブルには簡単にアクセスできますが、キューから読み取るには難解なツールを使用する必要があります。

   それは私の経験と一致しません。テーブルは、この独特の「他の言語」(SQL) を通じてアクセスされ、テーブルからオブジェクトへの構造マッピングと、VARCHAR2 から String へのデータ型マッピングを認識する必要があります。さらに、ある種のアクセス層 (JDBC または JDBC を使用する ORM) を使用する必要があります。それはとてもとても複雑に思えます。キューには、単純な送受信を使用して、MessageConsumers および MessageProducers を通じてアクセスします。

Answer 4

あなたが経験した問題はメッセージングに固有のものではなく、メッセージング システムの実装が不十分なために生じたものであるように思えます。メッセージング システムの構築はデータベース システムの構築より難しいですか?データベース システムを構築するだけなら、はい。

• キャッチされない例外によりメッセージが失われますか?それはメッセージ キューのせいではありません。使用しているアプリケーションは適切に設計されていません。処理が完了する前にキューからメッセージを削除しています。彼らはトランザクションやジャーナリングを使用していません。
• DB ストレージが「事実上無限」であるにもかかわらず、メッセージ キューがいっぱいになりますか?あなたは、ディスク領域の管理がデータベースには必要ないことであるかのように話しています。メッセージ キュー サーバーには、データベース サーバーと同様に管理が必要です。
• 行列から読み取る難解な器具？非同期メソッドが難解だと思うならかもしれません。シリアル化と逆シリアル化が難解だと思うならかもしれません。(少なくとも、これらは私がメッセージングを学んでいたときに難解だと感じたものです。一見難解に見える多くのテクノロジと同様、これらのテクノロジも一度理解すれば実際には非常にありふれたものであり、テクノロジを理解することは熟練した開発者の教育の重要な部分です。)

データベースよりも優れているメッセージングの側面:

• 非同期処理。 メッセージ キューは、新しいメッセージが到着すると、待機中のプロセスに通知します。データベースでこの機能を実現するには、待機中のプロセスがデータベースをポーリングする必要があります。
• 関心事の分離。 通信チャネルは、メッセージ内容の実装の詳細から切り離されています。送信者と受信者のみが、特定のメッセージ内のデータ ストリームの形式について知る必要があります。
• フォールトトレランス。. 。メッセージングは​​、サーバー間の接続が断続的でも機能します。メッセージ キューはメッセージをローカルに保存し、接続がアクティブな場合にのみリモート サーバーに転送できます。
• システム統合。 少なくとも Windows の世界では、メッセージングは​​オペレーティング システムに組み込まれています。OS のセキュリティ モデルが使用され、OS のツールなどを通じて管理されます。

これらが必要ない場合は、おそらくメッセージングも必要ありません。

メッセージング用アプリケーションの簡単な例を次に示します。私は現在、複数のネットワークに分散したユーザーが、印刷出力を生成するために使用されるかなり複雑なトランザクションのセットを入力するシステムを構築しています。出力の生成は計算コストが高く、ワークフローの一部ではありません。つまりユーザーは出力がいつ生成されるかを気にせず、単に出力が生成されることだけを気にします。

そこで、トランザクションをメッセージにシリアル化し、キューにドロップします。サーバー上で実行されているプロセスは、キューからメッセージを取得し、出力を生成し、その出力をイメージング システムに保存します。

データベースをメッセージ ストアとして使用する場合、現時点では送信者と受信者のみが気にするトランザクション形式を格納するためのスキーマを考え出す必要があり、ネットワーク上のすべてのワークステーションが永続的なメッセージ ストアを持っていることを確認する必要があります。データベース サーバーに永続的に接続すると、このトランザクション負荷を複数のサーバーに分散する能力がなく、出力サーバーは処理する新しいジョブがあるかどうかを確認するために 1 日に何千回もデータベースにクエリを実行する必要があります。

Answer 5

キューは、信頼できるメッセージングを提供します。キューイングのストアアンドフォワード、切断された性質により、データベースよりもはるかにスケーラブルになります。もちろん、より堅牢です。

また、キューを情報の永続的な保存に実際に使用すべきではありません。データベースとは異なり、キューを一時的な受信トレイと考えるのが最善です。