私は非常に基本的な質問をしているかもしれませんが、グーグルで明確な答えを見つけることができなかったので、ここに入れます。
Memcached は、別のプロセスに情報をキャッシュします。したがって、キャッシュされた情報を取得するには、プロセス間通信 (通常は Java でのシリアル化) が必要です。つまり、通常、キャッシュされたオブジェクトを取得するには、シリアル化されたオブジェクトを取得して、通常はネットワークに転送する必要があります。
シリアル化とネットワーク通信はどちらもコストのかかる操作です。memcached がこれらの両方を使用する必要がある場合 (一般的に言えば、ネットワーク通信が必要ない場合があるかもしれません)、Memcached はどのように高速なのでしょうか? レプリケーションはより良い解決策ではありませんか?
それとも、これはディストリビューション/プラットフォームの独立性/スケーラビリティとパフォーマンスのトレードオフですか?
ディスク I/O のコストを考慮に入れていません。これは一般に、どのプロセスでも最も遅い部分であり、memcached などのメモリ内キャッシュを利用するための主要なドライバー IMO です。
共有キャッシュ（memcachedなど）で何かを検索するのは、ローカルキャッシュで検索するよりも遅いというのは正しいです（これは、「レプリケーション」の意味だと思います）。
ただし、共有キャッシュの利点は共有されることです。つまり、キャッシュの各ユーザーは、メモリがローカル キャッシュに使用された場合よりも多くのキャッシュにアクセスできます。
50 GB のデータベースと 10 個のアプリ サーバーがあり、それぞれが 1 GB のメモリをキャッシュ専用にするアプリケーションを考えてみましょう。ローカル キャッシュを使用した場合、各マシンには 1 GB のキャッシュがあり、データベースの合計サイズの 2% に相当します。共有キャッシュを使用した場合、合計データベース サイズの 20% に相当する 10 GB のキャッシュがあります。キャッシュ ヒットは、ローカル キャッシュの方が多少速くなりますが、キャッシュ ヒット率は共有キャッシュの方がはるかに高くなります。キャッシュ ミスは、いずれの種類のキャッシュ ヒットよりも天文学的にコストがかかるため、ミスの数を減らすために、わずかに遅いヒットでも支払う価値があります。
現在、正確なトレードオフは、ローカル ヒット、共有ヒット、およびミスのコストの正確な比率と、データベース上のアクセスの分散によって異なります。たとえば、すべてのアクセスがサイズが 1 GB 未満の一連の「ホット」レコードに対するものである場合、ローカル キャッシュは 100% のヒット率を示し、共有キャッシュと同じくらい優れたものになります。それほど極端でない分布でも、バランスが傾く可能性があります。
実際には、最適な構成は通常 (IMHO!) 最もホットなデータ用に小さくても非常に高速なローカル キャッシュを使用し、次にロング テール用に大きく低速のキャッシュを使用することです。おそらく、他のキャッシュ階層の形状として認識されるでしょう: プロセッサがコアごとに小さくて高速な L1 キャッシュを持ち、次に低速の L2/L3 キャッシュが単一のダイのすべてのコア間で共有され、さらに低速になる方法を考えてみてください。システム内のすべてのダイで共有されるチップ キャッシュ (実際にオフチップ キャッシュを使用する現在のプロセッサはありますか?)。
メモリ キャッシュは、ネットワーク経由で RAM メモリを使用します。レプリケーションでは、RAM メモリと永続ディスク メモリの両方を使用してデータをフェッチします。それらの目的は大きく異なります。
Memcached を使用して、テーブル レコードの 1 対 1 マッピングなどの簡単に取得できるデータを保存することだけを考えている場合:you-re-gonna-have-a-bad-time:.
一方、データが複雑な SQL クエリの結果セット全体であり、SQL メモリ プールをオーバーフローする可能性がある (フェッチするために一時的にディスクに書き込む必要がある) 場合は、大幅な速度向上が見られます。 .
前の例では、読み取り操作のためにデータをディスクに書き込む必要があることに言及しています-はい、結果セットがメモリに対して大きすぎる場合に発生します（ a を想像しCROSS JOINてください）。つまり、そのドライブに対して読み取りと書き込みの両方を行うことを意味します（スラッシングが思い浮かびます）。
たとえば、C で記述された高度に最適化されたアプリケーションでは、合計処理時間が 1 マイクロ秒で、ネットワークやシリアライゼーション/デシリアライゼーション (マーシャリング/アンマーシャリング) をアプリの実行時間よりもはるかに長く待機する必要がある場合があります。そのとき、ネットワークを介したメモリ キャッシングの限界を感じ始めるでしょう。