クエリプラン管理

統計情報、制限事項、環境設定、クエリパラメータのバインディングの変更、PostgreSQL データベースエンジンのアップグレードは、すべてクエリ計画のリグレッションの原因になる可能性があります。クエリ計画のリグレッションとは、オプティマイザが、データベース環境への特定の変更前よりも最適でない計画を選択したことです。

Amazon Aurora PostgreSQL Compatible Edition では、クエリプラン管理 (QPM) 機能は、クエリプランのリグレッションを引き起こす可能性のあるデータベース環境の変化に関係なく、プランの適応性と安定性を確保するように設計されています。QPM はオプティマイザーをある程度制御します。QPM を使用すると、オプティマイザによって生成されたクエリ計画を SQL クエリ管理できます。クエリ実行プランでは、オプティマイザーは重要なクエリについて承認済みのプランから選択して、パフォーマンスを最適化する必要があります。

企業は通常、アプリケーションやデータベースをグローバルに展開したり、開発、QA、ステージング、試作、テスト、本番環境など、アプリケーションデータベースごとに複数の環境を維持したりします。各データベース、各環境、AWS リージョンおよびすべてのデータベースのクエリ実行計画を維持することは、複雑で時間がかかる場合があります。QPM では、Amazon Aurora PostgreSQL と互換性のあるマネージドプランをあるデータベースから別のデータベースにエクスポートおよびインポートできます。これにより、クエリ実行計画を一元的に管理し、データベースをグローバルに展開できます。この機能を使用して、試作データベースにある一連の計画を調査し、それらが適切に機能することを確認してから、本番環境に読み込むことができます。

QPM には他にもいくつかの利点があります。たとえば、アプリケーションでは変更できない実行プランや、ステートメントにヒントを追加できない場合に、QPM を使用して改善できます。また、QPM は、オプティマイザーが検出した新しい最小コストプランを自動的に検出するため、パフォーマンスだけでなくコストも引き続き最適化できます。

QPM を有効化することを推奨します。QPM を有効にすると、オプティマイザーは承認された最小コストプランを使用します。これにより、リグレッションを防ぎ、最適ではない計画の管理と修正に必要な時間を短縮できます。

QPM 機能の使用方法には、事前対応型と事後対応型の 2 種類があります。プロアクティブなアプローチは、パフォーマンスの低下を防ぐのに役立つように設計されており、事後対応的なアプローチは、パフォーマンスの低下が発生した後にそれを検出して修復するように設計されています。アプローチはクエリごとに選択できます。リグレッションが発生しやすい複雑なクエリやビジネスクリティカルなクエリには、プロアクティブなアプローチを採用して、それらのクエリに最適なプランを承認できます。実行中に他のクエリでクエリプランのリグレッションが発生した場合は、事後対応型のアプローチを使用できます。リグレッションが検出されたら、rejectedオプティマイザーが別の承認済みプランを選択するように、そのプランのステータスをに変更します。詳細については、「Aurora PostgreSQL クエリプラン管理のベストプラクティス」(Aurora ドキュメント) を参照してください。

クエリプラン管理はどのように機能しますか?

プランには、、approvedunapprovedpreferred、またはのいずれかのステータスが割り当てられますrejected。オプティマイザーは、approved各管理ステートメントの最初に生成されたプランをに設定し、次にその他のプランのステータスをに設定しますunapproved。unapproved後でプランを評価し、ステータスをapprovedpreferred、またはに変更できますrejected。詳細については、「Aurora PostgreSQL クエリプラン管理について」(Aurora ドキュメント) を参照してください。

管理計画は、マニュアルまたは自動でキャプチャできます。最も一般的な方法は、2 回以上実行されるすべてのステートメントのプランを自動的にキャプチャすることです。ただし、特定のステートメントセットの計画を手動でキャプチャすることもできます。詳細については、「Aurora PostgreSQL 実行プランのキャプチャ」(Aurora ドキュメント) を参照してください。

管理計画を設定すると、オプティマイザでは、preferredapproved管理ステートメントごとに最小コストまたは計画が使用されるようになります。詳細については、オプティマイザが実行する計画を選択する方法 (Aurora ドキュメント) を参照してください。

Amazon Aurora PostgreSQL 互換で QPM 機能を設定する手順については、「Aurora PostgreSQL のクエリ実行プランの管理」(Aurora ドキュメント) を参照してください。

制約事項

QPM を使用するには、サポートされている SQL ステートメントの要件を満たしていること、ステートメントがシステムリレーションを参照していないこと、DB インスタンスクラスに十分な vCPUs があることを確認する必要があります。詳細については、「サポートされている SQL ステートメント」と「クエリプラン管理の制限」(Aurora ドキュメント) を参照してください。

クエリ計画管理のユースケース

• クエリプランのリグレッションの防止 — データベースのバージョンを最新の状態に保つことには、パフォーマンスとセキュリティの向上、新機能へのアクセス、既知の問題の修正、規制要件への準拠など、多くのメリットがあります。ただし、データベースを更新すると、一部のクエリでパフォーマンスが低下するリスクがあります。メジャーバージョンのアップグレードでは、既存のアプリケーションクエリとの後方互換性のない変更が含まれる可能性があるため、このリスクは高くなります。QPM を実装すると、システム変更時にリグレッションを防ぎ、パフォーマンスを安定させるのに役立ちます。統計を更新したり、インデックスを追加したり、パラメータを変更したり、Amazon Aurora PostgreSQL と互換性のある新しいバージョンにアップグレードしたりすると、QPM は新しいプランを検出しますが、承認されたプランを引き続き使用するため、プランの安定性が維持されます。

• テスト機能 — すべてのマネージド SQL ステートメントのプラン履歴を表示し、PostgreSQL の新機能やプランの変更によってパフォーマンスが向上しているかどうかを評価できます。その後、それらの機能を実装するか、新しい計画を実装するかを決定できます。詳細については、dba_plans ビューで Aurora PostgreSQL クエリ計画を検証する (Aurora ドキュメント) を参照してください。

• 計画のリグレッション化、削除せずに、修正した方が良いこともあります。詳細については、「pg_hint_plan を使ったプランの修正」(Aurora ドキュメント) を参照してください。