Redisキャッシュと永続化のためのMongoのアーキテクチャ
セットアップ：
ユーザーが投稿を送信し、その投稿が多数（数百、数千、またはそれ以上）のユーザーに読まれる「Twitterのような」サービスを想像してください。
私の質問は、キャッシュとデータベースを設計して迅速なアクセスと多くの読み取りのために最適化するが、ユーザーが（必要に応じて）古い投稿を表示できるように履歴データを保持する最良の方法に関するものです。ここでの仮定は、ユーザーの90％が新しいものにのみ興味を持ち、古いものはたまにアクセスされるということです。ここでのもう1つの前提は、90％を最適化することであり、古い10％の取得に少し時間がかかる場合でも問題ありません。
これを念頭に置いて、私の研究では、キャッシュを90％使用する方向を強く指摘しており、投稿を別のより長期的な永続システムに格納することも考えています。したがって、これまでの私の考えは、キャッシュにRedisを使用することです。利点は、Redisが非常に高速であり、多くの人に投稿を公開するのに最適なpub/subが組み込まれていることです。そして、MongoDBを、Redisで期限切れになったときにアクセスされる同じ投稿を保存するためのより永続的なデータストアとして使用することを検討していました。
質問：
1。このアーキテクチャは水を保持しますか？これを行うより良い方法はありますか？
2。 RedisとMongoDBの両方に投稿を保存するメカニズムについては、アプリに2つの書き込みを行わせることを考えていました。1つ目はRedisに書き込み、その後すぐにサブスクライバーが利用できるようになります。 2番目-Redisに正常に保存した後、すぐにMongoDBに書き込みます。これはそれを行うための最良の方法ですか？代わりに、期限切れの投稿をRedisにMongoDB自体にプッシュさせる必要がありますか？これについては考えましたが、Redisから直接MongoDBにプッシュするための情報はあまり見つかりませんでした。
実際、RedisとMongoDBを関連付けることは賢明です。優れたチームプレーヤーです。あなたはここでより多くの情報を見つけるでしょう：
重要なポイントの1つは、必要な回復力レベルです。 RedisとMongoDBはどちらも、許容レベルの復元力を実現するように構成できます。これらの考慮事項は、設計時に検討する必要があります。また、デプロイメントオプションに制約を課す可能性があります。RedisとMongoDBの両方のマスター/スレーブレプリケーションが必要な場合は、少なくとも4つのボックスが必要です（RedisとMongoDBを同じマシンにデプロイしないでください）。
これで、キューイング、pub/subなどのためにRedisを維持し、ユーザーデータをMongoDBのみに保存する方が少し簡単になるかもしれません。理論的根拠は、異なるパラダイムを備えた2つのストアに対して、同様のデータアクセスパス（このジョブの難しい部分）を設計する必要がないことです。また、MongoDBには水平方向のスケーラビリティ（レプリカセット、自動シャーディングなど）が組み込まれていますが、Redisには自分でできるスケーラビリティしかありません。
2番目の質問については、両方のストアに書き込むことが最も簡単な方法です。 RedisアクティビティをMongoDBに複製するための組み込み機能はありません。 Redisキュー（アクティビティが投稿される場所）をリッスンし、MongoDBに書き込むデーモンを設計することはそれほど難しくありません。