私のユースケースについての簡単な概要：100万のエントリを持つデータベース（おそらくmongodb）を考えてみましょう。各エントリの値は、APIを呼び出して毎日更新する必要があります。そのようなcronジョブを設計する方法は？Facebookが似たようなことをしていることは知っています。私が考えることができる唯一のことは、データベースエントリをバッチに分割し、各ジョブがバッチを更新する複数のジョブを持つことです。私はそこにもっと賢い解決策があると確信しています。また、どのテクノロジーを使用すればよいかわかりません。任意のアドバイスをいただければ幸いです。
-カラン
技術的な観点からは、mongodbシェルでスクリプトを実行し、cronを介してスクリプトを実行できます。次のようなコマンドを実行するようにcronをスケジュールする場合：
./mongo server:27017/dbname--quiet my_commands.js
Mongodbは、my_commands.jsスクリプトの内容を実行します。さて、概念を説明するためだけに、非常に単純な例を示します。名前の付いた人物を見つけて属性を挿入したい場合sara（はい、非現実的な例）、.jsスクリプトファイルに次のように入力できます。
person = db.person.findOne( { name : "sara" } );
person.validated = "true";
db.people.save( person );
その後、cronが実行されるたびに、そのレコードが更新されます。ここで、APIにループと呼び出しを追加すると、解決策が得られる可能性があります。これらのコマンドと例の詳細については、mongodbのドキュメントをご覧ください。
ただし、設計の観点から、毎晩すべてのレコードを更新する必要がありますか？処理する必要のあるレコードのより合理的なサブセットを特定する方法はありますか？または、データを取得して消費する人に提供するときに、データに対してAPIを呼び出すことができますか？
「キャッシュをウォームに保つ」という更新された質問コンテキストを考えると、データが使用可能なメモリに快適に収まらない限り、すべてのデータベースドキュメントにアクセスする戦略は、パフォーマンスを向上させるのではなく、低下する可能性があります。
MongoDBでのキャッシュは、ファイルシステムキャッシュのオペレーティングシステムの動作に依存します。これは通常、使用頻度が最も低い（LRU）アプローチに従ってキャッシュを解放します。つまり、時間の経過とともに、メモリ内の作業データセットは当然「ウォーム」データになるはずです。
データをメモリに強制的に読み込むと、エンドユーザーがほとんど（またはまったく）アクセスしないドキュメントをロードする可能性があります。アプリケーションユーザーが実際に頻繁に要求する可能性のあるデータを犠牲にする可能性があります。
キャッシュを「予熱」するユースケースがあります。たとえば、MongoDBサーバーを再起動し、データまたはインデックスをメモリにロードする場合です。
MongoDB 2.2では、この目的のために新しいtouchコマンドを使用できます。
予熱のための他の戦略は、本質的にを使用して逆最適化を行うことexplain()です。nscannedインデックスエントリ（ ）とドキュメント（ ）の数を最小化しようとする代わりに、nscannedObjectsこれらのエントリを意図的に最大化するクエリを作成します。
APIの応答時間の目標を設定すると、誰かの最初の呼び出しでデータをメモリにフェッチする必要があったとしても、それでもかなり迅速にインデックスを取得できるはずです。アプリケーションに多くの処理オーバーヘッドがない限り、3〜4秒の応答という目標は寛大なようです。MongoDBのデフォルトの「遅い」クエリ値は100ミリ秒です。