選択とディスク間の 3 つのキャッシュ層

アプリケーションが SELECT ステートメントを起動するとき、そのクエリは回転ディスクや生のフラッシュ ストレージにさえほとんどアクセスしません。クエリは 3 つの異なるキャッシュ層を通過し、応答がマイクロ秒単位で届くかミリ秒単位で届くかをサイレントに判断します。これらのレイヤーを理解することが、簡単に拡張できるビジネス プラットフォームと、現実世界の負荷に耐えられるビジネス プラットフォームの違いとなります。

SELECT クエリがアプリケーションから出た瞬間に何が起こるでしょうか?

アプリケーションが SELECT クエリを送信した瞬間、ほとんどの開発者が決して検査しないパイプラインに入ります。データベース エンジンは、I/O が発生する前にリクエストをインターセプトし、SQL を解析して内部実行プランにし、すぐに最初の防御線であるクエリ結果キャッシュを参照します。同じパラメータを持つ同じクエリが最近実行された場合、エンジンはデータの 1 ページも操作せずに、キャッシュされた結果セットを返すことができます。これはクエリ キャッシュまたは結果キャッシュと呼ばれることもあり、分析ダッシュボードやレポート モジュールなど、読み取りが多く書き込みが少ないワークロードでは、ディスク読み取りの大部分を完全に排除できます。

ここで重要な洞察は、クエリ キャッシュがデータの変更に対して非常に敏感であるということです。基礎となるテーブルに対する INSERT、UPDATE、または DELETE は、関連するキャッシュされた結果を無効にします。これが、書き込み負荷の高いトランザクション システムがクエリ キャッシュを完全に無効にし、代わりにより深い層に依存することが多い理由です。

バッファプールとは何ですか?そしてそれが思っている以上に重要である理由は何ですか?

2 番目のキャッシュ層は、おそらく運用システムで最も重要なものですが、バッファ プール (PostgreSQL では共有バッファ、MySQL では InnoDB バッファ プールと呼ばれます) です。これは、データベース エンジンが最近アクセスしたデータ ページを保持するために使用する RAM の領域です。結果キャッシュからクエリを処理できない場合、エンジンはディスク読み取りを発行する前に、必要なデータ ページがバッファ プールにすでに存在するかどうかを確認します。

バッファ プールは、時間的および空間的局所性の原則に基づいて動作します。つまり、最近アクセスされたデータは再びアクセスされる可能性が高く、アクセスされたデータの近くに保存されているデータはすぐにアクセスされる可能性が高くなります。データベース管理者は、最も影響力の高い構成決定の 1 つとしてバッファー プール サイズを調整します。バッファー プールが小さすぎると、継続的なページの削除が発生し、スラッシングと呼ばれる現象が発生します。この現象では、システムはクエリの実行よりもキャッシュ ミスの管理に多くの時間を費やします。

重要な洞察: ほとんどの OLTP ワークロードでは、適切なサイズのバッファ プールは、すべてのデータ読み取りの 95 ～ 99% が RAM から提供されることを意味します。ワーキング セット (クエリが実際に頻繁にアクセスするデータのサブセット) は、多くの場合、データベースの合計サイズよりもはるかに小さくなります。データセット全体ではなく、作業セットに合わせてバッファー プールのサイズを変更することは、実行できる単一の最も高い収益をもたらすチューニング アクションです。

オペレーティング システムのキャッシュは RAM とディスクの間のギャップをどのように埋めるのでしょうか?

データベース自体のバッファー プールが見つからない場合でも、クエリはまだ実際のディスク読み取りを目的としていません。オペレーティング システムは、ブロック デバイスへの読み取りと書き込みをバッファリングするカーネル管理の RAM 領域であるページ キャッシュ (ファイルシステム キャッシュとも呼ばれます) を維持します。データベース エンジンがバッファ プールに存在しないページを要求すると、OS カーネルはストレージ コントローラに物理 I/O コマンドを発行する前に、自身のページ キャッシュをチェックします。

この 3 番目の層はアプリケーション開発者にはほとんど見えませんが、データベース バッファ プールが不足しているシステムでは非常に重要です。 OS ページ キャッシュはすべてのプロセスで共有されるため、アプリケーション サーバー、Web サーバー、および同じホスト上で実行されているその他のソフトウェアと競合します。専用データベース サーバーでは、この競合は最小限に抑えられ、OS キャッシュによって意味のあるセカンド チャンス バッファーが提供されます。メモリ制限が厳しい共有ホストまたはコンテナでは、OS キャッシュが小さすぎて役に立たないことがよくあります。

実際に最もパフォーマンスを向上させるのはどのキャッシュ層ですか?

実際の運用システムでは、バッファ プール domi

Related Posts

• DJBの暗号学的オデッセイ：コードヒーローから標準規格の批評家へ
• macOS のあまり知られていないコマンドライン サンドボックス ツール (2025)
• GNU Pies – プログラムの呼び出しおよび実行スーパーバイザー
• CXMT は、一般的な市場価格の約半分の価格で DDR4 チップを提供してきました。