RedisとMongoDBを一緒に使用すると、良い結果が得られます。 MongoDBとRedisを（MySQLとSphinxとともに）実行することでよく知られている会社はCraiglistです。 JeremyZawodnyによるこのプレゼンテーションをご覧ください。
MongoDBは、さまざまな方法でインデックス付けされた永続的なドキュメント指向のデータにとって興味深いものです。 Redisは、揮発性のデータ、または遅延の影響を受けやすい半永続的なデータの場合に、より興味深いものになります。
MongoDB上でのRedisの具体的な使用例をいくつか示します。
-
2.2より前のMongoDBには、まだ有効期限メカニズムがありません。上限付きコレクションを実際に使用して実際のTTLを実装することはできません。 RedisにはTTLベースの有効期限メカニズムがあり、揮発性データの保存に便利です。たとえば、ユーザーセッションは通常Redisに保存されますが、ユーザーデータはMongoDBに保存され、インデックスが作成されます。 MongoDB 2.2では、コレクションレベルで低精度の有効期限メカニズムが導入されていることに注意してください（たとえば、データのパージに使用されます）。
-
Redisは、便利なセットデータ型とそれに関連する操作（和集合、共通部分、複数のセットの違いなど）を提供します。この機能に加えて、基本的なファセット検索またはタグ付けエンジンを実装するのは非常に簡単です。これは、MongoDBの従来のインデックス作成機能への興味深い追加です。
-
Redisは、リストでの効率的なブロックポップ操作をサポートしています。これは、アドホック分散キューイングシステムを実装するために使用できます。バックエンドアプリケーションはタイムアウトで複数のキューをリッスンしたり、アイテムを別のキューにアトミックに転送したりできるため、MongoDBテーラブルカーソルIMOよりも柔軟性があります...アプリケーションでキューイングが必要な場合は、キューをRedisに保存するのが理にかなっています、MongoDBに永続的な機能データを保持します。
-
Redisは、pub/subメカニズムも提供します。分散アプリケーションでは、イベント伝播システムが役立つ場合があります。これもRedisの優れたユースケースですが、永続データはMongoDBに保持されます。
RedisよりもMongoDBを使用してデータモデルを設計する方がはるかに簡単であるため（Redisはより低レベルです）、メインの永続データに対するMongoDBの柔軟性と、Redisが提供する追加機能（低レイテンシー）の恩恵を受けるのは興味深いことです。 、アイテムの有効期限、キュー、pub / sub、アトミックブロックなど...）。それは確かに良い組み合わせです。
同じマシンでRedisサーバーとMongoDBサーバーを実行しないでください。 MongoDBメモリはスワップアウトされるように設計されていますが、Redisはスワップアウトされません。 MongoDBが何らかのスワッピングアクティビティをトリガーした場合、Redisのパフォーマンスは壊滅的なものになります。それらは異なるノードで分離する必要があります。