ベストアンサー
Scott McNultyが以前にこの質問に回答したように、SQLキャッシングは、に対するクエリの結果として生成された結果セットの格納です。データベース、および後の結果のために結果のコピーを使用します。そうは言っても、この問題には単なる「キャッシング」以上のことがたくさんあります。本当の問題はキャッシュではなく、無効化が難しい部分です。情報の保存は難しくありません。いつ無効になるかを知ることは難しいことではありません。
キャッシュに関連する2つ目の、より微妙な問題もあります。それは、キャッシュによるネットワーク遅延の影響です。ほとんどのキャッシュソリューションは、データベースと同じように、独立したサーバーとして動作します。キャッシュをクエリするには、データベースと同様に、ネットワーク全体のラウンドトリップを実行する必要があります。キャッシュに確実に答えがなく、データベースよりも速く応答する場合、キャッシュを使用して実際にパフォーマンスを向上させることは非常に困難です。
SQLを最適にキャッシュするには、解決できるソリューションが必要です。いくつかの問題：
- どのコンテンツをキャッシュする必要がありますか？
- キャッシュされた結果がある場合、それは無効と見なされますか？
- キャッシュがヒットした場合レートが低すぎる場合、ペナルティを回避するためにキャッシュロジックが自動的に調整されてキャッシュが停止し、ルックアップが停止しますか？
実際には、ほとんどのコーナーケースを考慮すると、非常に複雑になります。キャッシュの最良のパフォーマンスシナリオを保証するための一連のロジック。これは、 Redis や Hazelcast などのキャッシュエンジンをアプリケーションに実装するほど簡単ではありません。 。代わりに、変更されているデータを検査し、データを自動的に無効にし、外部キャッシュエンジンに対して行われる可能性のあるリクエストと、データベースに対して行われているものを最適化できるインテリジェントなキャッシュエンジンが必要です。
そのようなエンジンの1つは、 Heimdall Data からのものです（免責事項、私はHeimdall DataのCTOです）。 Heimdallエンジンは、アプリケーションからデータベースに送信されたコンテンツをJDBCドライバーまたはプロトコルレベルのプロキシとして自動的にキャッシュし、コンテンツを自動的に無効にし、キャッシュされるコンテンツも最適化します。これにより、開発者はキャッシュではなく機能に集中でき、場合によっては、アプリケーションの開発とデバッグの時間を20〜40％節約できます。
回答
一般的なキャッシュは保存です。リソースを再び使用する必要がないようにリソースを大量に消費するプロセスの結果。
SQLの場合。これは常にベンダーテクノロジーに固有です。 MS-SQL、Oracle、MySQL、およびPostGresはすべて、キャッシュするものについて異なる選択肢を持っています。結果、クエリ、クエリの実行プランもすべて保存して、後で同じ情報を処理しようとするときに使用できます。
基になるデータが変更された場合、システムには通常、メカニズムがあります。キャッシュされた情報が「ダーティ」であり、完全に使用できなくなったことを示すため。そのため、システムはクエリを再度実行できます。
これは常に表示されます。クエリにはどのくらい時間がかかりますか？もう一度実行すると、なぜ常に高速になるのですか？さてこれが理由です。システムはあなたが以前に尋ねたことを効果的に記憶し、その時から覚えている答えをあなたに与えます。