2

質問の背景: Web サイトにキャッシュ システムを実装しようと考えています。現在、これを行う手段として memcache を検討しています。ただし、SQL Server にも同様のものが存在するかどうかを調べています。MySQL には、分散されていませんが一種の「ストップ ギャップ」対策として機能するクエリ キャッシュがあることを理解しています。MySQL クエリ キャッシュは SQL Server のバッファ キャッシュと同等ですか?

だからここに私の質問があります：

  1. 現在バッファキャッシュに保存されていることを知る方法はありますか?
  2. これに続いて、特定のテーブルまたは結果セットをキャッシュに強制する方法はありますか
  3. バッファとプロシージャ キャッシュで何が行われるかをどの程度制御できますか? 以前は DBCC PINTABLE コマンドがあったことは理解していますが、それは廃止されました。
  4. 少し話が逸れましたが、キャッシュはデータベース層にも存在するべきでしょうか? それとも、Velocity/Memcache を使用してキャッシュを管理する方が賢明ですか? そうですか、なぜですか？重複するトリガーを持つ多くのオブジェクトを処理する場合、キャッシュの無効化は苦痛のようです。

ありがとう！

4

4 に答える 4

4

System Rがその方法を示して以来、SQL Server は、太陽の下のすべてのデータベース製品と同じ方法で (多かれ少なかれ) バッファー プールを実装しています。詳細については、Transaction Processing: Concepts and Techniquesで説明しています。さらに、プロシージャ キャッシュ、アクセス許可トークン キャッシュ、およびその他の多くのキャッシュ クラスで使用されるキャッシュ フレームワークがあります。このフレームワークは、Clock Hands - what are they forで最もよく説明されています。

しかし、これは、アプリケーションが通常関心を持っている種類のキャッシュではありません。内部データベース キャッシュは、これらのキャッシュを使用することで、より強力なバックエンド データベースがより多くのクエリに迅速に応答できるスケールアップ シナリオに最適ですが、最新のアプリケーション スタックはWeb サーバーをスケールアウトする傾向があり、実際の問題は、Web ファームで使用されるキャッシュにクエリ インテロゲーションの結果をキャッシュすることです。理想的には、このキャッシュは共有および分散する必要があります。Memcached と Velocity は、このようなアプリケーション キャッシング インフラストラクチャの例です。Memcache には長い歴史があり、その用途と短所は理解されており、使用方法、展開方法、管理方法、監視方法に関する重要なノウハウがあります。

アプリケーション層でのキャッシング、特に分散キャッシングの最大の問題は、キャッシュの無効化です。新しいリクエストが古いデータを使用しないように、バックエンド データで発生する変更を検出し、キャッシュされたエントリを無効としてマークする方法。

最も単純な (いくつかの単純な定義では...) 代替手段は、アプリケーションからの積極的な無効化です。コードは、データベース内のエンティティをいつ変更するかを認識しており、変更が発生した後、キャッシュされたエントリを無効としてマークするための追加の手順を実行します。これにはいくつかの短いコミングがあります:

  • どのキャッシュされたエントリが無効化されるかを正確に知ることは困難です。依存関係は非常に複雑になる可能性があり、物事は常に単純なテーブル/エントリ以上のものであり、集計クエリ、結合、パーティション化されたデータなどがあります.
  • データを変更するすべてのパスでキャッシュも無効になるようにするには、コードの規律が必要です。
  • アプリケーションの範囲外で発生したデータの変更は検出されません。実際には、アプリケーションの範囲外で発生する変更が常にあります。同じデータを使用する他のアプリケーション、インポート/エクスポートおよび ETL ジョブ、手動介入などです。

より複雑な代替手段は、変更が発生したときにデータベース自体から通知されるキャッシュです。ただし、これをサポートするテクノロジは多くありません。データベースからの積極的なサポートがなければ機能しません。SQL Server には、このようなシナリオ向けのクエリ通知があります。詳細については、The Mysterious Notificationを参照してください。スタンドアロン アプリケーションに QN ベースのキャッシングを実装するのはかなり複雑です (そしてしばしばうまくいかないこともあります) が、正しく実装すると問題なく動作します。Memcached のようなスケールアウトされた共有キャッシュでこれを行うことは、非常に強力ですが、実行可能です。

于 2009-11-19T22:35:56.877 に答える
3

ナイ、

あなたの質問への答えは次のとおりです。

  1. Wikiから-常に正しい...？:-)。より多くのマイクロソフトの答えについては、ここにバッファキャッシュに関する彼らの説明があります。

    バッファ管理

    SQL Serverは、ディスクI / Oを最小限に抑えるために、ページをRAMにバッファリングします。任意の8KBページをメモリ内にバッファリングでき、現在バッファリングされているすべてのページのセットはバッファキャッシュと呼ばれます。SQL Serverで使用可能なメモリの量によって、メモリにキャッシュされるページ数が決まります。バッファキャッシュは、バッファマネージャによって管理されます。任意のページからの読み取りまたはページへの書き込みのいずれかにより、ページがバッファキャッシュにコピーされます。後続の読み取りまたは書き込みは、ディスク上のバージョンではなく、メモリ内のコピーにリダイレクトされます。このページは、メモリ内キャッシュがしばらく参照されていない場合にのみ、バッファマネージャによってディスク上で更新されます。ページをディスクに書き戻すときに、非同期I / Oが使用されます。これにより、I / O操作がバックグラウンドスレッドで実行されるため、他の操作はI/O操作が完了するのを待つ必要がありません。各ページは、書き込まれるときにチェックサムとともに書き込まれます。ページを読み返すと、チェックサムが再度計算され、保存されているバージョンと照合されて、その間にページが破損または改ざんされていないことを確認します。

  2. この回答については、上記の回答を参照してください。

    任意のページからの読み取りまたはページへの書き込みのいずれかにより、ページがバッファキャッシュにコピーされます。後続の読み取りまたは書き込みは、ディスク上のバージョンではなく、メモリ内のコピーにリダイレクトされます。

  3. bpool_commit_targetカタログビューの列とbpool_committed列をクエリしsys.dm_os_sys_infoて、メモリターゲットとして予約されているページ数と、バッファキャッシュに現在コミットされているページ数をそれぞれ返すことができます。

  4. マイクロソフトは自社製品のキャッシュを理解する時間があり、信頼されるべきだと感じています。

この情報がお役に立てば幸いです。

ありがとう！

于 2009-11-11T17:25:00.077 に答える
0

SQL Server のバッファ キャッシュに関する特定の技術的な質問は、「私の Web サイトにキャッシュ システムを実装する」ということになると、間違った道を進んでいます。

確かに、SQL Server はパフォーマンスを改善できるようにデータをキャッシュします (そしてそれはかなりうまくいきます)。 - クエリが完全に SQL Server のキャッシュから実行される場合でも、オーバーヘッドとリソースの競合が発生するためです。

調べたいのは、memcached、Velocity、ASP.NET Cache、P&P Caching Application Block などです。

于 2009-11-20T23:52:41.027 に答える
0

キャッシングは、ASP.Net アプリケーションがブラウザーからハードウェアに至るまで、IIS、アプリケーション、データベースが中間に配置されているため、さまざまな意味を持ちます。

あなたが話しているキャッシングはデータベースレベルのキャッシングです。これはアプリケーションに対してほとんど透過的です。このレベルのキャッシュには、バッファー プール、ステートメント キャッシュなどが含まれます。DB サーバーに十分な RAM があることを確認してください。理論的には、DB サーバーは DB ストア全体をメモリにロードできる必要があります。アプリケーションの起動時に予期されるデータをプリフェッチし、それが DB キャッシュにあることを確認しない限り、このレベルでできることはあまりありません。

一方、インメモリ分散キャッシングシステムです。memcache と速度とは別に、NCacheやOracle Coherenceなどの商用ソリューションを見ることができます。私はどちらも推奨する経験がありません。このレベルのキャッシングは、より安価なコストでスケーラビリティを約束します。これに比べて、DB 層のスケーリングにはコストがかかります。ただし、ネットワーク帯域幅などの側面を考慮する必要がある場合があります。このタイプのキャッシングは、特に無効化と期限切れを伴う場合、複雑になる可能性があります

IIS レベル (IIS 7) および ASP.Net レベルでの出力キャッシュを使用して、Web サービス層でキャッシュできます。
アプリケーション レベルでは、ASP.Net キャッシュを使用できます。これはあなたが最もコントロールできるものであり、あなたに良い利益をもたらします.

次に、キャッシュ制御 HTTP ヘッダーによって制御できるクライアント Web プロキシ層でキャッシングが行われます。

最後に、ブラウザー レベルのキャッシュ、ビュー ステート、小さなデータ用の Cookie があります。

また、SAN などのハードウェアも物理ディスク アクセス レベルでキャッシュすることを忘れないでください。

要約すると、キャッシングは多くのレベルで発生する可能性があり、シナリオに最適なソリューションを分析して実装する必要があります。データの安定性と揮発性、予想される負荷などを調べました。ASP.Net レベル (特にオブジェクトの場合) でのキャッシュが、最も柔軟性と制御を提供すると思います。

于 2009-11-20T09:46:52.607 に答える