このページでは、AlloyDB for PostgreSQL インスタンスでクエリの透過的な転送を有効にして構成し、モニタリングする方法について説明します。クエリの透過的な転送は、インテリジェントなリソース最適化機能です。プライマリノードは、読み取り専用クエリをインターセプトし、読み取り / 書き込みの整合性を維持しながら、使用率の低い読み取りプールインスタンスに選択的に転送できます。読み取りプールに転送されたクエリは、プライマリ ノードの実行と整合性のある結果を生成します。
クエリの透過的な転送は、次のようなシナリオに最適です。
- ハイブリッド ワークロード（HTAP）: トランザクションを処理する同じデータベースで、読み取り / 書き込みの整合性を維持しながら、レポートまたは分析クエリを実行し、コストのかかる読み取りが書き込みレイテンシに影響しないようにします。
- モノリシック アプリケーション: 厳密な読み取り / 書き込みの整合性を維持しながら、リーダー エンドポイントとライター エンドポイントを別々に使用するようにアプリケーションをリファクタリングせずに、読み取りプールの容量を使用します。
- 動的な負荷管理: 読み取りトラフィックが予測不能なスパイクが発生し、プライマリ ノードに読み取り / 書き込みの整合性を維持しながら負荷がかかっているときに、データベースが読み取りプールノードに自動的に処理をオフロードします。
始める前に
AlloyDB クラスタが PostgreSQL 17 または 18 と互換性があることを確認します。
AlloyDB クラスタに、アクティブな読み取りプール インスタンスが 1 つ以上構成されている必要があります。読み取りプール インスタンスの作成または確認については、クラスタに読み取りプール インスタンスを作成するとインスタンスの詳細を表示するをご覧ください。
必要なロール
alloydbsuperuserデータベース ロールがあること、またはデフォルトのpostgresユーザーとしてログインしていることを確認します。
クエリの透過的な転送を有効にする
クエリの透過的な転送はデフォルトで無効になっています。データベースを再起動せずに、セッション レベルまたはデータベース レベルで動的に有効にできます。
セッション レベルで有効にする
現在のセッションでクエリの透過的な転送を有効にするには、次の SQL コマンドを実行します。
SET alloydb.enable_query_forwarding = TRUE;
データベース レベルで有効にする
特定のデータベースでクエリの透過的な転送を有効にするには、次の SQL コマンドを実行します。
ALTER DATABASE DATABASE_NAME SET alloydb.enable_query_forwarding = ON;
DATABASE_NAME は、データベースの名前に置き換えます。
クエリの利用条件
- クエリの透過的な転送は、読み取り専用の
SELECTステートメントにのみ適用されます。 - クエリは、
SELECT ... FOR UPDATEで使用されるような行レベルのロックを取得してはなりません。 - クエリの透過的な転送は、マルチステートメント トランザクション内の
SELECTステートメントのサポートが制限されています。 - クエリは、一時テーブル、ログに記録されないテーブル、カタログ テーブルを参照できません。
- クエリは、次の関数の制約に準拠する必要があります。
- クエリに揮発性関数やユーザー定義関数（UDF）を含めることはできません。
- クエリに、
CURRENT_DATE、LOCALTIME、USER、CURRENT_SCHEMAなどの SQL 値関数を含めることはできません。 - クエリに
NEXTVAL()式を含めることはできません。 - クエリに SQL プロシージャまたは SQL 関数を含めることはできません。
- すべての結果列で、バイナリの送信関数と受信関数を実装するデータ型を使用する必要があります。
- クエリのオーバーヘッド コストがクエリの合計コストと比較して最小限の場合にのみ、クエリを転送できます。つまり、インデックス スキャンを使用するクエリは、通常、オーバーヘッドがクエリ自体のコストを超えるため除外されます。
- AlloyDB ホットスタンバイ ノードへの転送はサポートされていません。AlloyDB ホットスタンバイ ノードは、高可用性（HA）プライマリ インスタンス専用のセカンダリ ノードです。
EXPLAIN でクエリの利用資格を確認する
次の例では、large_table は行数の多いデータベース内のテーブルです。現在の構成で特定のクエリを転送できるかどうかを確認するには、EXPLAIN コマンドを実行します。
EXPLAIN SELECT count(*) FROM large_table t1, large_table t2;
クエリが適格な場合、出力には標準の Postgres 実行プランの後にクエリ転送ステータス ステートメントが含まれます。このステートメントがない場合、クエリはクエリ転送の対象ではなく、プライマリでローカルに実行されます。
Aggregate (cost=25000.00..25000.01 rows=1 width=8)
-> Nested Loop (cost=0.00..20000.00 rows=1000000 width=0)
... [Standard Postgres Plan Steps] ...
Query Forwarding: Eligible. (overhead=1250.02)
出力レスポンスで、Eligible は、クエリが標準の読み取り専用 SQL 条件を満たし、費用対効果分析で読み取りプール
インスタンスへのルーティングが優先されることを示します。overhead パラメータは、接続の確立とレプリカでのスナップショットの復元にかかるオーバーヘッドなど、クエリを読み取りプール
インスタンスに転送する際のプランナーの計算コストを示します。
クエリ転送の指標をモニタリングする
ワークロード全体でクエリの透過的な転送が機能していることを確認するには、Cloud Monitoring で次の指標を追跡します。
| 指標 | 説明 | 詳細 |
|---|---|---|
alloydb.googleapis.com/internal/database/postgresql/workload/distributed/tqf_query_count |
クエリの透過的な転送によって処理されたクエリの累積数。 | 表示名: TQF クエリ数 指標の種類: CUMULATIVE 値の型: INT64 ラベル: status: クエリの透過的な転送が有効になっている場合のクエリ処理。このラベルには、次のいずれかの値が記録されます。
|