データベースに保存する必要がある大量のデータを生成するコードがあります。問題は、データベースが生成されたデータを保持できないことです。したがって、ある種のキューイングメカニズムがこの状況で役立つかどうか疑問に思っています-特にRabiitMQで考えており、一部の消費者がデータを取得してデータベースにプッシュするまで、データをキューに保存することが可能かどうかを考えています. また、同じデータがすぐに更新されるため、そのデータがデータベースに作成されたかどうかには特に関心がありません。
2 に答える
1
@hyperboreean 少しぎこちなく聞こえるかもしれませんが、おそらく本当に必要なのはRedisやMemcacheDなどのキャッシュですか?
技術的には、RabbitMQ を使用してコンシューマが DB を更新することもできますが、「キュー クリーニング」メカニズムを実装する必要があります。そうしないと、入力レートがデータベースの処理能力を超えている限り、キューが大きくなります。キューが大きくなるにつれて、キュー内のデータが古くなります。つまり、送信されたばかりの更新がまだキューに残っているということです。レジ係が 1 人いる店のようなものと考えてください。確かに別々の行を形成することはできますが、それは複数の長い行があり、まだ 1 つのチェッカーがあることを意味します。チェッカーが顧客を処理できるレートに拘束されます。
あまりにも簡単な説明からすると、データは実際には一時的なデータであり、キャッシュ システム (または他の NoSQL のような配置) の方が適しているように思えます。最終的にデータを永続化する必要がある場合は、現在のデータをキャッシュ メカニズムからプルして DB にロードする別のプロセスを用意することができます。次に、データを抽出するのにかかった時間と実際にデータを DB にロードできる頻度によって制限されます。
于 2010-05-27T19:14:04.900 に答える
1
挿入はストアにまだ存在しないデータに関するものであるため、データベースはロックメカニズムなしでデータ挿入を非常に高速に処理することになっています。データの挿入を扱っていて、データベースへのシリアライゼーションがボトルネックである場合、データベースの挿入はRabbitMQ へのアウトバウンド メッセージングよりも高速に実行されるため、RabbitMQ には問題が残っています。このシナリオでは、RabbitMQ は問題を解決しません。一方、データの更新は (一般に) 更新行をロックし、ロックと待機で同時実行の問題が発生する可能性があります。全体として、データベースの永続性がボトルネックである理由を理解してください。
最終的に、データ ストアが NOSQL の場合、実行中の書き込みではない可能性があります。この場合、何がデータをより速く受信するかを分析できます (NoSQL と RabbitMQ の比較)。
複数のスレッドでデータ プロデューサーを使用している場合は、永続ストアに書き込むための同時実行性の問題があります。この場合、RAbbitMQ は同時実行性を高めるように設計されているため、永続ストアよりも優れた同時実行性を処理する必要があります。これは、使用しているデータストアによって異なります。
于 2013-07-21T13:19:28.013 に答える