データをキャッシュするか、データベースにヒットする必要がありますか？
私はキャッシュメカニズムを使用していないので、次のシナリオで.netの世界で私のオプションは何なのかと思っていました。
私たちは基本的にaa RESTユーザーがカテゴリのIDを渡すサービス（フォルダを考える）を持ち、このカテゴリには多数のサブカテゴリがあり、各サブカテゴリには1000のメディアコンテナ（ NASまたはSAN=この場合のファイルはビデオです）にある可能性のあるファイルに関する情報を含むファイル参照オブジェクトと考えます。これらのカテゴリは、いくつかの権限ルールとサブカテゴリに関するメタデータとともにデータベースに保存されます。
したがって、UIの観点からは、遅延して読み込まれたツリーコントロールがあり、これはユーザーが各サブフォルダーをクリックすると駆動されます（Windowsエクスプローラーを考えてみてください）。ビデオファイルのURLにアクセスすると、ビデオを見ることができます。
システムが成長するにつれて、ユーザーの数は1000に増え、サブカテゴリとビデオは10000になる可能性があります。
問題は、各リクエストがデータベースにヒットする場合の現在の動作方法を続行する必要があるか、それともデータのキャッシュについて考える必要があるかです。
IIS 6/7およびAsp.netを使用しています。
まず、データプロバイダーを簡単に切り替えられるようにコードが分割されていることを確認します。ここでは、インターフェースの分離とその他のSOLID原則について説明します。
次に、以下に対する答えを知る必要があります。
1）データは頻繁に変更されますか？ 2）アプリケーションはこれらの更新を取得するためにRESTサービスを頻繁にポーリングしますか？3）データベースは他の目的に使用されていますか？ 4）現在のパフォーマンスの問題を認識していますか？ 5）データはアプリケーションによって更新されますか？それらの更新はアプリに反映する必要がありますか？
興味深いのは、データベースを使用することで、技術的にすでにデータをキャッシュしていることです。それがデータベースの役割です。多くのR＆Dは、データを取得する際にデータベースを可能な限り高速にすることを目指しています。たとえば、頻繁に使用されるデータには独自のメモリキャッシュを使用します。
では、キャッシュプロバイダーを交換することで何を得たいと思っているかを自問してみてください。そして、対処する必要がある現在の制限は何ですか？
現在、速度低下が発生していない場合は、「いいえ、切り替える必要はありません」と言ってください。
それは本当に大きなトピックです。キャッシュは、データを地理的に分散させる必要がある場合に非常にうまく機能する傾向がありますが、管理の面で大きなオーバーヘッドがあります。
現在、まったく同じような決定を下しているプロジェクトをやっています。
これまでの私の解決策は、データベースのみを使用し、各クライアントからのポーリングリクエストでデータベースを大量にヒットすることです。不自然に聞こえますが、（テストにおいて）必要以上にスケールが大きく、コードは非常に単純です。
とはいえ、私のコードは、メインアプリケーションのデータプロバイダーをデータベースコードから抽象化する一種のリポジトリパターンを使用しています。 GemFireのようなキャッシュプロバイダーでスワップしたい場合は、実行するのにかなりの量のコードが必要になります。
Thorbjørnのコメントによると、実際には十分な情報がありません。
キャッシングは、正しく行われないと、あなたとあなたのユーザーに多大な悲しみを引き起こす可能性があります。アプリケーションを過度に複雑にする前に、キャッシュについて心配する必要があることを確認してください。
したがって、本当にキャッシュする必要があることを示す情報がない場合は、キャッシュしないでください。
[最適化の一般的なルール：何かをすべきかどうかを尋ねる必要がある場合、答えはノーです] *
*答えが「はい」であるほとんどの場所では、質問ではなくステートメントになります。