大規模な Web サイトで Memcached のような分散キャッシュ ソリューションを使用するのは初めてです。いくつか質問があります。経験のある方にコメントをお願いします。
明らかに、キャッシュに入れることができるデータの量は、サーバーの RAM に依存します。十分な大きさのサーバー ファームと RAM があると仮定すると、パフォーマンスの低下が見られる前に memcached に入れることができるオブジェクトの最大数はありますか? 私が尋ねる理由は、文字通り何百万ものオブジェクトを memcached に入れたら、オブジェクトのインデックス作成と検索に時間がかからないのではないかと考えているからです。ここに線引きはありますか？
memcached に小さいがより多くのオブジェクトをキャッシュする必要がありますか、それとも大きいが少ない数のオブジェクトをキャッシュする必要がありますか? オブジェクトが小さいほど、それらを取得するために DB へのラウンドトリップが多くなりますが、より柔軟でプログラミングが容易になります。
どうもありがとうございました、
レイ。
Memcached は内部的にハッシュを使用して O(1) ルックアップを行います。複雑な作業をできるだけ少なくするように設計されています。
大小を問わず、何をキャッシュするかに関しては、何を保存する必要があるかによって、労力を節約できます (これは大きなばかげたキャッシュであることを念頭に置いてください。参照されている 1 つの部分を変更した場合は、同期を維持する必要があります)。他の場所へ)。元のサイトである Livejournal.com では、意味のある最大のブロックは 1 つの完全なジャーナル エントリでした。これは、特定の投稿を見ることを許可された人なら誰でも使用できる完成した HTML です。
私はこれをいくつかの非常に小さなエントリ (メンバー ID に対する単一の数字) に使用しましたが、必要に応じて一度に 1 つずつではなく、単一のデータベース クエリでそのようなエントリをまとめて数千生成しています。
非常に大きなアイテムまたは非常に小さなアイテムのみを保存することがわかっている場合は、デーモンを多少最適化できますが、多くの小さなエントリの場合、メモリの空の大きなスラブを小さなチャンクに分割して使用するのに十分なスマートがあります。
サーバーファームとRAMが十分に大きいとすると、パフォーマンスの低下が見られる前にmemcachedに入れることができるオブジェクトの最大数はありますか？
理想的には、キャッシュは常に100％いっぱいである必要があります。memcachedはハッシュアルゴリズムを使用してキーを検索します。私が知る限り、より多くのキーを保存してもパフォーマンスが低下することはありません。
小さいが多いオブジェクトをmemcachedにキャッシュする必要がありますか、それとも大きいが少ないオブジェクトをキャッシュする必要がありますか？
データベースとキャッシュの両方のルックアップの時間を短縮するには、オブジェクトを大きくしてもオブジェクトを少なくすることが望ましいと思いますが、これはケースバイケースで行う必要があります。パフォーマンスの違いが大幅に大きくなることがわかっている場合を除いて、最初に最も簡単なものから始めて、それでも不十分な場合はそこから作業することをお勧めします。