MongoDBの多くの用途では、コレクションをメモリ内にあるものとして扱いたいと思っています。たとえば、ユーザーセッションオブジェクト（Webサイト用）のコレクションの場合。 MongoDBを使用する前に、私はmemcachedサーバなどにそのようなデータを格納します。しかし、このような場合には、memcached + MongoDBの両方を実行する必要はありません。小さなMongoDBコレクションの場合、あたかもメモリ内にあるかのように設計するのは安全ですか？
頻繁にアクセスされるデータのサイズが小さい（システムRAM全体の1％未満）場合、コレクションは基本的に常にメモリ内に保持されると想定するのは合理的ですか？私はいつも_idによって直接参照を行い、データにはインデックスがありません。
セッションコレクションがそれ自身のデータベースに保持されていた場合、この前提に役立ちますか？私は、MongoDBのバッファキャッシュベースのメモリマッピングスキームの性質のために尋ねます。
MongoDBはDBストレージのメモリ管理自体を行いませんが、OS仮想メモリマネージャーに依存します。したがって、OSに非常に依存しています。 VMMは、99％のサイズであってもDB全体をメモリにロードすることができます。または、他のアプリケーションがRAMを要求しているため、VMMはすべてをページングできます。したがって、使用パターンにも依存します。
VMMは可能な限りMRUデータをメモリに保存しようとします。そのため、セッションコレクションは別のデータベースにあるかどうかに関係なく常にメモリに格納されます（通常4kサイズのページに分割されます）。
mongostatユーティリティでは、いつでもページングの状態を確認できます。これは、メモリにないページへのアクセス回数を表すページフォールトカウンタを持ち、ファイルからロードする必要があります。
一般に、コレクションのメモリリークを制御する限り（たとえば、未使用のオブジェクトが最終的に解放されるなど）、大きなコレクションをメモリに保持することは大丈夫です。これが問題ではない理由は、最近のどのサーバーでも、未使用のページがスワップされている仮想メモリがあるからです。このようにして、頻繁に使用されないいくつかのオブジェクトにメモリが割り当てられたとしても、システムのパフォーマンスは損なわれません。
私は別のデータベースに保管することを考えました。セッションのコレクションを残りのデータと混在させると、ページあたり1つのセッションオブジェクトしかなく、他のコレクションの他のランダムオブジェクトが混在することがあります。セッションをそれ自身のDBに入れると、そのDBの各4kページがSessionオブジェクトで埋められます。しかし、mongodbがどのようにコレクションオブジェクトをページに割り当てるのか分からないので、このことが重要かどうかはわかりません。 – slacy