PostgreSQLのようなデータベース上にRabbitMQのようなメッセージブローカーが必要なのはなぜですか？

Question

RabbitMQ のようなメッセージブローカーは初めてで、これを使用して Celery のようなスケジューリングシステムのタスク/メッセージキューを作成できます。

さて、ここで質問です：

PostgreSQL でテーブルを作成できます。このテーブルに新しいタスクを追加し、Celeryのようなコンシューマプログラムで使用できます。
RabbitMQのようなまったく新しい技術をセットアップしたいのはなぜですか？

現在、PostgreSQLのようなデータベースは分散環境で動作するため、スケーリングは答えにならないと考えています。

特定の問題に対してデータベースがどのような問題を引き起こすかをグーグルで調べましたが、次のことがわかりました。

ポーリングにより、データベースがビジー状態になり、パフォーマンスが低下します
テーブルのロック->再び低パフォーマンス
数百万行のタスク->繰り返しますが、ポーリングのパフォーマンスは低いです

さて、RabbitMQまたはそのような他のメッセージブローカーは、これらの問題をどのように解決しますか？

また、AMQPプロトコルが従うものであることがわかりました。その中で何が素晴らしいのでしょうか？

Redis はメッセージブローカーとしても使用できますか？ RabbitMQよりMemcachedに似ています。

これに光を当ててください！

Jaigus · Accepted Answer

Rabbitのキューはメモリに常駐するため、これをデータベースに実装するよりもはるかに高速です。（適切な）専用メッセージキューは、スロットリング/フロー制御などの重要なキューイング関連機能、およびカップルを指定するためのさまざまなルーティングアルゴリズムを選択する機能も提供する必要があります（ウサギはこれらを提供します）。プロジェクトのサイズによっては、メッセージパッシングコンポーネントをデータベースとは別にすることもできます。これにより、1つのコンポーネントに大きな負荷がかかっても、他のコンポーネントの動作を妨げる必要がなくなります。

あなたが言及した問題に関して：

データベースをビジーで低パフォーマンスに保つポーリング：Rabbitmqを使用すると、プロデューサーはコンシューマーにPush更新を行うことができますポーリングよりもはるかにパフォーマンスが高い。データは必要なときに消費者に送信されるだけなので、無駄なチェックの必要はありません。
テーブルのロック->再び低パフォーマンス：ロックするテーブルがありません：P
数百万行のタスク->ポーリングのパフォーマンスは低くなります：前述のように、RabbitmqはRAMに常駐するため高速に動作し、フロー制御を提供します。必要に応じて、ディスクがRAMを使い果たした場合にメッセージを一時的に保存するために使用することもできます。 2.0以降、RabbitはRAMの使用法を大幅に改善しました。クラスタリングオプションも利用できます。

AMQPに関して、本当にクールな機能は「交換」であり、それが他の交換にルーティングできることです。これにより、柔軟性が向上し、スケーリング時に非常に便利になる可能性のある幅広い複雑なルーティングの類型を作成できます。良い例については、以下を参照してください。

_{（ソース： springsource.com ）}

および： http://blog.springsource.org/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/

最後に、redisに関しては、はい、メッセージブローカーとして使用でき、うまく機能します。ただし、rabbitmqはフル機能のエンタープライズレベルの専用メッセージキューになるようにゼロから構築されたため、Rabbitmqにはredisよりも多くのメッセージキュー機能があります。一方、Redisは、主にメモリ内のキーと値のストアとして作成されました（現在はそれ以上の機能を備えていますが、スイスアーミーナイフとも呼ばれています）。それでも、私はRedisで小規模なプロジェクトで良い結果を達成している多くの人々を読んだり聞いたことがありますが、大規模なアプリケーションではあまり聞いていません。

ロングポーリングチャットの実装で使用されているredisの例を次に示します。 http://eflorenzano.com/blog/2011/02/16/technology-behind-convore/

Craig Ringer · Answer

PostgreSQL 9.5

PostgreSQL 9.5にはSELECT ... FOR UPDATE ... SKIP LOCKEDが組み込まれています。これにより、作業キューシステムをlotより簡単かつ簡単に実装できます。他のセッションがロックされていない「n」行をフェッチし、作業が完了したことを確認するまでロックしたままにするのが簡単になったため、外部キューシステムは不要になります。外部調整が必要な場合の2フェーズトランザクションでも動作します。

外部キューイングシステムは引き続き有用であり、定型機能、実証済みのパフォーマンス、他のシステムとの統合、水平スケーリングおよびフェデレーションのオプションなどを提供します。それにもかかわらず、単純なケースでは、それらはもう必要ありません。

古いバージョン

あなたはそのようなツールを必要としないが、それを使うことは生活を楽にするかもしれない。データベースでキューイングを行うのは簡単に見えますが、実際には、高性能で信頼性の高い同時キューイングは本当に難しいリレーショナルデータベースであることがわかります。。

PGQ のようなツールが存在するのはそのためです。

LISTENとNOTIFYを使用してPostgreSQLのポーリングを取り除くことができますが、高度な同時操作を維持しながら、キューの先頭から正確に1つのコンシューマーにエントリを確実に配布する問題は解決しません。挿入をブロックしません。あなたが考えるすべてのシンプルで明白な解決策は、実際にはその問題を解決するものではなく、シングルワーカーのキューフェッチの効率の悪いバージョンに縮退する傾向があります。

高度な同時マルチワーカーキューフェッチが必要ない場合、PostgreSQLで単一のキューテーブルを使用することはまったく合理的です。