mongo の内部キャッシュがどのように機能するか、および memcache の使用を排除するかどうかを理解しようとしています。私たちのデータベースのサイズは約 200G で、インデックスはメモリに収まりますが、インデックスの後でサーバーに空きメモリがあまり残っていません。
私の同僚の 1 人は、mongo の内部キャッシュは memcache と同じくらい高速であるため、memcache を使用して別のレベルの複雑さを導入する必要はないと言っています。
私の頭の中のシナリオは、db からデータを読み取るときに memcache に保存され、次回は db サーバーに戻る代わりにキャッシュから直接読み取られるというものです。データが変更され、保存/更新が必要な場合は、memcache サーバーとデータベース サーバーの両方で行われます。
私はこれについて読んでいますが、まだ自分自身を納得させることができませんでした. ですから、誰かがこれに光を当てることができれば、本当に感謝しています。
まず、キャッシュ ストレージはデータベースとは異なります。そのため、MongoDB と SQL は、Memcache と比較すると、目的と使用法が異なります。
Memcache は、クエリのワーキング セット サイズを小さくするのに非常に優れています。例: サブセレクトとステートメントを含む巨大な集計クエリとCASE、SQL にないもの (できる限り複雑なクエリを考えてください) を想像してください。このクエリを常にリアルタイムで実行すると、コンピューターが「スラッシング」する可能性があります (クライアント側の問題に言及してください）。
ただし、誰もが知っているように、このクエリを別のコレクション/テーブルに要約するだけで、すぐに高速になります。memcache の実際の速度は、メモリ内のキーと値のストアであるという事実に由来します。これは、MongoDB がメモリに保存されておらず、メモリ マップされているが保存されていないため、速度が低下する可能性がある場所です。
MongoDB はセルフ キャッシングを行いません。クエリが「ホット」であり、LRU (ワーキング セットが入る場所) の場合、応答時間に大きな違いは見られません。クエリが「ホット」であることを確認する良い方法は、クエリを実行することです。キャッシュをウォームアップするために実行する最大のクエリのスクリプトを持っている人もいます。
私が言ったように、memcache はキャッシュ層であり、これが理由です:
データが変更され、保存/更新が必要な場合は、memcache サーバーとデータベース サーバーの両方で行われます。
私は少し内側で死にます。多くの場合、DB とキャッシュ レイヤーの境界があいまいになります。