私は MongoDB を使用してリアルタイム Websocket サーバー アプリケーションをサポートしています。
クライアント ベースが拡大しており、シングル スレッドのパフォーマンスではもはや不十分です。スレッド間でメッセージを分散するには、pub/sub レイヤーが必要です。
通常は Redis を使用しますが、アプリではすでに MongoDB を使用しているため、tailable カーソルを使用して依存関係を回避できます。ただし、パフォーマンスが心配です。
pub/sub アーキテクチャの場合、MongoDB の tailable カーソルのパフォーマンスは Redis と比べてどうですか?
ベストアンサー1
実際のところ、それらはまったく異なるものです。
MongoDB の tailable カーソルは、キューのように動作します。上限付きコレクションで動作するため、コレクション内のアイテムを明示的に削除する必要はありません。これは非常に効率的ですが、MongoDB は書き込み操作ごとにコレクション全体 (実際にはデータベース) をロックするため、スケーラビリティが制限されることに注意してください。もう 1 つのスケーラビリティ制限は、接続数です。各クライアント接続により、mongod サーバー (または mongos) に接続スレッドが追加されます。
それでも、大きな問題なく 1 秒あたり数万個のアイテムを処理できると期待でき、これはさまざまなアプリケーションには十分である可能性があります。
一方、Redis は、各接続でスレッドが作成されないため (Redis はシングル ヘッドのイベント ループ)、通常、より多くの接続を同時に処理できます。また、すべてのアイテムをキューに入れないため、CPU 効率も非常に優れています。Redis の pub/sub では、アイテムはパブリケーションと同じイベント ループの反復でサブスクライバーに伝播されます。アイテムはメモリに保存されることもなく、Redis には維持する単一のインデックスさえありません。アイテムはソケット バッファーから取得され、別のソケット バッファーにプッシュされるだけです。
ただし、キューイングがないため、Redis pub/sub メッセージの配信はまったく保証されません。メッセージが発行されたときにサブスクライバーがダウンしている場合、このサブスクライバーのメッセージは失われます。
Redis では、特にパイプラインと複数のパブリケーション クライアントを使用する場合、単一のコアで 1 秒あたり数十万のアイテムを期待できます。