クエリ ストアの使用シナリオ

  • [アーティクル]

適用対象: Azure Database for PostgreSQL - 単一サーバー

重要

Azure Database for PostgreSQL - シングル サーバーは廃止パスにあります。 Azure Database for PostgreSQL - フレキシブル サーバーにアップグレードすることを強くお勧めします。 Azure Database for PostgreSQL - フレキシブル サーバーへの移行の詳細については、Azure Database for PostgreSQL 単一サーバーの現状に関するページをご覧ください。

予測可能なワークロード パフォーマンスの追跡と管理が重要であるさまざまなシナリオで、クエリ ストアを使用することができます。 次に例を示します。

  • 高コスト上位クエリの識別と調整
  • A/B テスト
  • アップグレード中の安定したパフォーマンスの維持
  • アドホックなワークロードの識別と改善

コストの高いクエリを識別して調整する

実行時間の長いクエリを識別する

実行時間が最も長いクエリをすばやく識別するには、Azure portal の Query Performance Insight ビューを使用します。 このようなクエリは、一般に、大量のリソースを消費する傾向があります。 実行時間が長いクエリを最適化すると、リソースが解放されて、システムで他のクエリの実行に使用できるようになるため、パフォーマンスが向上する可能性があります。

パフォーマンス向上の対象クエリ

クエリ ストアはパフォーマンス データを時間枠に細分するので、クエリ パフォーマンスの時間による変化を追跡できます。 これにより、全体的な消費時間増加の原因になっているクエリを正確に特定できます。 その結果、対象を絞ってワークロードのトラブルシューティングを行うことができます。

コストの高いクエリの調整

パフォーマンスが最適ではないクエリがわかったら、問題の性質に応じて対処します。

  • パフォーマンスに関する推奨事項を使って、推奨されるインデックスがあるかどうかを調べます。 ある場合は、インデックスを作成し、クエリ ストアを使用してインデックス作成後のクエリのパフォーマンスを評価します。
  • クエリで使用される基になるテーブルの統計が最新であることを確認します。
  • コストが高いクエリを書き直すことを検討します。 たとえば、クエリのパラメーター化を利用し、動的 SQL の使用を減らします。 アプリケーション側ではなくデータベース側でのデータへのフィルター処理の適用など、データを読み取る時点で最適なロジックを実装します。

A/B テスト

クエリ ストアを使用して、導入が計画されているアプリケーション変更の前後で、ワークロードのパフォーマンスを比較します。 環境またはアプリケーションの変更がワークロードのパフォーマンスに及ぼす影響をクエリ ストアを使用して評価するシナリオの例:

  • 新しいバージョンのアプリケーションの展開。
  • サーバーへの新しいリソースの追加。
  • 高コストのクエリによって参照されているテーブルでの欠落したインデックスの作成。

これらのどのシナリオでも、次のワークフローを適用します。

  1. 計画的な変更の前にクエリ ストアを使用してワークロードを実行し、パフォーマンスのベースラインを生成します。
  2. 制御された時点でアプリケーションの変更を適用します。
  3. 十分に長い時間ワークロードの実行を続けて、変更後のシステムのパフォーマンス イメージを生成します。
  4. 変更の前と後の結果を比較します。
  5. 変更したままにするか、ロールバックするかを決定します。

アドホックなワークロードを識別して改善する

一部のワークロードには、アプリケーション全体のパフォーマンス向上のために調整できる支配的なクエリがありません。 このようなワークロードの特徴は、一般に、比較的多くの固有クエリが含まれ、各クエリがシステム リソースの一部を消費していることです。 個々の固有クエリの実行頻度は低いので、個別のランタイム消費量は重要ではありません。 一方で、アプリケーションが絶え間なく新しいクエリを生成していると、システム リソースのかなりの部分がクエリのコンパイルに費やされ、最適とはいえない状態になります。 通常、このような状況は、アプリケーションが (ストアド プロシージャまたはパラメーター化クエリを使用するのではなく) クエリを生成する場合、または既定でクエリを生成するオブジェクト リレーショナル マッピング フレームワークにアプリケーションが依存している場合に、発生します。

ユーザーがアプリケーションのコードを管理している場合は、ストアド プロシージャまたはパラメーター化クエリを使用するようにデータ アクセス層を書き直すことを検討できます。 しかし、このような状況は、データベース全体 (すべてのクエリ) またはクエリ ハッシュが同じ個々のクエリ テンプレートに対し、クエリのパラメーター化を強制することにより、アプリケーションを変更しないで改善することもできます。

次のステップ