私はRedisや他のKey-Valueストア/ NoSQLソリューションをWebサイトの分散キャッシュとして使用していることを多くの人が読んでいます。大量のデータをキャッシュする
私は完全に理解していないかもしれませんが、このような解決策は共有データに対してのみ機能するようです。たとえば、ユーザーがログインする必要があるWebサイトがあり、生成されたクエリによって、すべてのユーザーに対してキャッシュできないユーザー（私の場合は銀行/資産情報）のみに固有のデータが返された場合、このタイプ解決策は機能しません。
残念なことに、データベースはすべてのアプリケーションで共有されています。問題が発生すると、Webサイトも停止します。各ユーザーは何ギガバイトもの情報を持っているので、明らかにそのすべてをキャッシュすることはできず、各Webページは完全に異なる情報をクエリします。
このようなシナリオで使用できるキャッシング戦略はありますか？
Velocityのような分散キャッシュでは、格納するデータを「共有」データに限定する必要はありません。しかし、DBからデータを読み込んでキャッシュに保存する必要がありますが、時間がかかります。
いくつかの選択肢：それはいくつかのDBサーバ
....
は、Webアプリケーションの負荷がバランスされていますか？ Web層にはキャッシングオプションもあります.ASPOのオブジェクトキャッシュは開始するのに適しています。ウェブクライアントが同じデータを複数回リクエストしている可能性があります（特定のユーザーの場合）。だから、キャッシングはそのような場合に利益をもたらすことができます。
しかし、巨大なキャッシングソリューションを実装する前に、特に遅くなったり膨大な回数実行されたクエリを見て、どのような方法でそれらを最適化できるかを確認する必要があります。
次に、DBマシンのアップグレードを見てください。
私は、MySpaceが巨大な成長を遂げたときのパフォーマンスの問題について素敵な記事を読んだ。
hereという記事があります。際立っている記事から
一つの引用：
キャッシュサーバの追加は、「私たちは初めから 行っているべきものですが、私たちはあまりにも急速に成長し、時間 を持っていませんでした座ってそれをやります」とBenedetto氏は付け加えます。
問題がデータベースサーバーにある場合は、データのパーティション分割と負荷を分散するデータベースファームの使用を検討してください。 SSDのことも考えてください！彼らは実際にあなたのデータベースアクセスコードをスピードアップすることができます。
データのダイナミックさに応じて、Fragment Cachingを使用することもできます。これにより、データではなくページのHTMLがキャッシュされるので、データの量がキャッシュできない場合は、これが有効です。