RedisとMongoDBを併用すると、良い結果が得られます。 MongoDBとRedisを（MySQLとSphinxとともに）実行することで有名な会社はCraiglistです。 Jeremy Zawodnyの このプレゼンテーション を参照してください。
MongoDBは、さまざまな方法でインデックス化された永続的なドキュメント指向のデータにとって興味深いものです。 Redisは、揮発性データ、またはレイテンシーに敏感な半永続データにとってより興味深いものです。
MongoDBでのRedisの具体的な使用例は次のとおりです。
2.2より前のMongoDBにはまだ有効期限のメカニズムがありません。キャップ付きコレクションを使用して実際のTTLを実装することはできません。 RedisにはTTLベースの有効期限メカニズムがあり、揮発性データを保存するのに便利です。たとえば、ユーザーセッションは通常Redisに保存されますが、ユーザーデータはMongoDBに保存され、インデックス付けされます。 MongoDB 2.2は、コレクションレベルで低精度の有効期限メカニズムを導入していることに注意してください（たとえば、データのパージに使用されます）。
Redisは、便利なセットデータ型とそれに関連する操作（ユニオン、インターセクション、複数セットの差分など）を提供します。この機能の上に基本的なファセット検索またはタグ付けエンジンを実装するのは非常に簡単です。これは、MongoDBの従来のインデックス作成機能への興味深い追加です。
Redisは、リストでの効率的なブロッキングポップ操作をサポートしています。これを使用して、アドホック分散キューイングシステムを実装できます。バックエンドアプリケーションは、タイムアウト付きで複数のキューをリッスンしたり、項目を別のキューにアトミックに転送したりできるため、MongoDBテーラブルカーソルIMOよりも柔軟性があります。 、MongoDBに永続的な機能データを保持します。
Redisはpub/subメカニズムも提供します。分散アプリケーションでは、イベント伝播システムが役立つ場合があります。これもRedisの優れたユースケースですが、永続データはMongoDBに保持されます。
Redisを使用するよりもMongoDBを使用してデータモデルを設計する方がはるかに簡単であるため（Redisはより低レベルです）、主な永続データに対するMongoDBの柔軟性と、Redisが提供する追加機能（低遅延）の恩恵を受けることは興味深いことです、アイテムの有効期限、キュー、pub/sub、アトミックブロックなど）。それは確かに良い組み合わせです。
同じマシンでRedisとMongoDBサーバーを実行しないでください。 MongoDBメモリはスワップアウトされるように設計されていますが、Redisはそうではありません。 MongoDBがスワッピングアクティビティをトリガーすると、Redisのパフォーマンスは壊滅的なものになります。それらは異なるノードに分離する必要があります。
明らかにfarこれより多くの違いがありますが、非常に高い概観のために：
ユースケースの場合：
- Redisは、分散コンピューティングのキャッシングレイヤーまたは共有ホワイトボードとしてよく使用されます。
- MongoDBは、従来のSQLデータベースのスワップアウトの代替としてよく使用されます。
技術的に：
- Redisは、ディスクの永続性を備えたインメモリデータベースです（データベース全体がRAMに収まる必要があります）。
- MongoDBはディスクでバックアップされたdbで、インデックスに十分なRAMのみが必要です。
いくつかの重複がありますが、両方を使用することは非常に一般的です。その理由は次のとおりです。
- MongoDBは、より多くのデータをより安く保存できます。
- Redisはデータセット全体で高速です。
- MongoDBの文化は「すべてを保存し、後でアクセスパターンを把握する」ことです。
- Redisの文化は、「データにアクセスしてから保存する方法を慎重に検討する」ことです。
- どちらにも、それらに依存するオープンソースツールがあり、その多くは一緒に使用されます。
Redisは従来のデータストアの代替として使用できますが、最もよく使用されるのはwith Mongo、Postgresql、MySQLなどの別の通常の「長い」データストアです。
Redisは、MongoDBとキャッシングサーバーとして優れた動作をします。ここで何が起こるかです。
Mongooseがキャッシュクエリを発行すると、最初にキャッシュサーバーに渡されます。
キャッシュサーバーは、以前にその正確なクエリが発行されたことがあるかどうかを確認します。
そうでない場合は、キャッシュサーバーがクエリを取得し、mongodbに送信すると、Mongoがクエリを実行します。
次に、そのクエリの結果を取得し、キャッシュサーバーに戻ります。キャッシュサーバーは、クエリの結果を自身に保存します。
そのクエリを実行するたびに、この応答を取得するので、発行されたクエリとそれらのクエリから返される応答の間の記録を維持するようになります。
キャッシュサーバーは応答を受け取り、それをmongooseに送り返します。mongooseはそれを表現に渡し、最終的にはアプリケーション内で終了します。
同じクエリが再度発行されるたびに、mongooseは同じクエリをキャッシュサーバーに送信しますが、キャッシュサーバーがクエリを発行する前にこのクエリが発行されたことを確認すると、クエリをmongodbに送信せず、代わりに最後に取得したクエリをすぐにmongooseに送り返します。ここにはインデックスも、フルテーブルスキャンも、何もありません。
このクエリが実行されたと言うために、単純なルックアップを行っていますか？はい？さて、リクエストを受け取ってすぐに返送してください。mongoには何も送信しないでください。
Mongooseサーバー、キャッシュサーバー（Redis）、Mongodbがあります。
キャッシュサーバーには、すべてのキーが以前に発行されたクエリのタイプであり、値がそのクエリの結果であるキー値タイプのデータストアを持つデータストアが存在する場合があります。
ですから、_idによるブログ投稿を探しているかもしれません。
したがって、ここのキーは、以前に検索したレコードの_idである可能性があります。
したがって、mongooseが新しいクエリを発行し、_idが123のブログポストを見つけようとすると、クエリはキャッシュサーバーに流れ、キャッシュサーバーは_idを探しているクエリの結果があるかどうかを確認します123の。
キャッシュサーバーに存在しない場合、このクエリが取得され、mongodbインスタンスに送信されます。 Mongodbはクエリを実行し、応答を取得して返信します。
この結果はキャッシュサーバーに返送され、キャッシュサーバーはその結果を取得してすぐにmongooseに返送するため、できるだけ迅速に応答することができます。
その直後に、キャッシュサーバーも発行されたクエリを取得し、発行されたクエリのコレクションに追加し、クエリの結果を取得して、クエリに対してすぐに保存します。
将来、同じクエリを再度発行し、キャッシュサーバーにアクセスし、所有しているすべてのキーを調べて、ブログ投稿を見つけて、mongoに到達せず、単にクエリの結果と、それを直接mongooseに送信します。
複雑なクエリロジックを実行しているわけではありません。インデックスも、そのようなものもありません。その可能な限り高速。その単純なキー値ルックアップ。
キャッシュサーバー（Redis）がMongoDBでどのように機能するかの概要です。
今、他の懸念があります。データを永遠にキャッシュしますか？レコードを更新するにはどうすればよいですか？
常にキャッシュにデータを保存し、キャッシュから読み取る必要はありません。
キャッシュサーバーは書き込みアクションには使用されません。キャッシュレイヤーは、データの読み取りにのみ使用されます。データを書き込む場合、書き込みは常にmongodbインスタンスに渡されるため、データを書き込むたびに、Mongoで更新したばかりのレコードに関連するキャッシュサーバーに格納されているデータをクリアする必要があります。