メッセージキューとしてのNoSQLドキュメントデータベース
NoSQL Documentデータベースをメッセージングキューとして使用することを検討しています。
理由は次のとおりです。
- クライアントがメッセージ（シリアル化されたオブジェクト）をサーバーに投稿し、同期応答を待つ必要がないようにしたい。
- いくつかの基準に基づいて「キュー」からメッセージを引き出すことができるようにしたいのですが、これは単なる優先度レベルよりも洗練されている場合があります（私はホストされているWebアプリに取り組んでいるので、すべての顧客に公平にしたいと思います「コンピューティング時間」の量、および1人の顧客がすべての処理を独占しないようにします）。
- キューを永続的なものにしたい-サーバーがダウンした場合、残りのメッセージがすべてアップしたときに処理されるようにしたい。
そのため、MongoDBまたはRavenDBをメッセージキューとして使用することを検討しています。クライアントは、メッセージオブジェクトをデータベースに書き込むWebサービスに投稿できます。次に、作業を行うサービスは、発生する可能性のある基準に基づいて、さまざまなメッセージタイプをプルできます。シナリオの周りにインデックスを作成して、より高速にすることができます。
だから-私はこれに穴を開ける誰かを探しています。誰かがこれを成功させましたか？誰かがこれを試し、何らかの方法で失敗しましたか？
この質問で受け入れられた回答を確認してください： https://stackoverflow.com/questions/4745911/nosql-databases
両方のタイプのデータベースで作業したことに対する私の見方は、NoSQLの真の利点はそれらのスケーラビリティにあるということです。それらは、多くのノードに存在する必要がある、増え続けるものの塊に適しています。結局のところ、これらは（Facebook、Google ...）から生まれたアプリケーションです。
それらには欠点もあり、実装に固有です。個人的には、複数のノードが短時間でオブジェクトを削除して再入力すると、いくつかのレプリケーションエラーが発生しました。私は必ずしもそれが常に普及していることを示唆しているわけではありませんが、速度の利点は一貫性の保証が少ないことがしばしばあります（つまり、最終的な一貫性があり、しかし、あなたはそれに依存したくありません）。
あなたがしているすべてがキューを構築しているなら、私はそれらを好ましい選択にするNoSQLに固有の何かを見ていません。それの速度/信頼性/効率は、それを採用することを決定した実装の構成により多く影響します。
要件リストがかなり短いので、目に見える穴はありません:-)。基本的に、要件リストが長いほど、独自の記述で穴が見つかる可能性が高くなります。
私の意見では、このシナリオにNoSQLデータベースを使用すると、次のようになります。
- 要件がフル機能のキューではない場合
- アプリがプルモデルからプッシュモデルに移動する必要がない場合（queue v pub/sub）
- メッセージの構造はかなり変化しやすく、時間とともに変化します
- アプリはさまざまな基準に基づいてメッセージをプルする必要があります
- noSQLデータベースを再利用すると、アプリが依存するシステムの数が減ります
ちなみに、私は（偏見として）RethinkDBも参照することをお勧めします。
MrFoxに同意します。キュー内の同じデータを更新するスレッドが複数ある場合、データベースは真のACIDトランザクションをサポートする必要があります。そうしないと、キュー内の同じアイテムが重複して処理されるだけでなく、キュー内の同じアイテムが複数回処理されるリスクがあります。待ち行列。
キューに投稿する合計データがビッグデータサイズ（> PB）のデータでない場合、別のタイプのデータベース、少なくとも真の一貫性をサポートするデータベースを選択することをお勧めします。
プロセスキューは、OLTPタイプのデータベースに適しています。基本的に、何よりも挿入/更新を多く行うためです。