Query Insights を使用してクエリのパフォーマンスを向上させる

プレビュー

このプロダクトには、 Google Cloud 利用規約の pre-GA サービス規約が適用されます。一般提供前のプロダクトについてはサポートが制限され、一般提供前のプロダクトの変更は、他の一般提供前のバージョンと互換性がない可能性があります。詳細については、リリース ステージの説明をご覧ください。

このページでは、Query Insights ダッシュボードを使用してパフォーマンスの問題を検出して分析する方法について説明します。この機能の概要については、Query Insights の概要をご覧ください。

Gemini in Databases アシスタントを使用すると、AlloyDB リソースのモニタリングとトラブルシューティングを行うことができます。詳細については、Gemini アシスタンスによるモニタリングとトラブルシューティングをご覧ください。

始める前に

自分または他のユーザーがクエリプランの表示やエンドツーエンドのトレースを行う必要がある場合は、特定の Identity and Access Management（IAM）権限が必要です。カスタムロールを作成し、必要な IAM 権限を追加できます。その後、Query Insights を使用して問題のトラブルシューティングを行うユーザー アカウントに、このロールを追加できます。カスタムロールの作成に関するページをご覧ください。

カスタムロールには、IAM 権限の cloudtrace.traces.get が必要です。

Query Insights ダッシュボードを開く

プレビュー — Gemini in Databases

この機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。この機能の個人データは、Google Cloud にアクセスする契約に記載されている義務と制限を条件として、Cloud のデータ処理に関する追加条項に定めるとおり処理できます。 pre-GA の機能は「現状有姿」で利用できますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

Query Insights ダッシュボードを開くには、次の手順を行います。

1. クラスタとインスタンスのリストで、インスタンスをクリックします。
2. クラスタの [概要] ページの指標グラフの下にある [クエリ分析情報に移動すると、クエリとパフォーマンスに関する詳細情報を確認できます] をクリックするか、左側のナビゲーション パネルで [クエリ分析情報] タブを選択します。

次のページで、次のオプションを使用して結果をフィルタできます。

1. インスタンス セレクタ。クラスタ内のプライマリ インスタンスまたは読み取りプール インスタンスを選択できます。デフォルトでは、プライマリ インスタンスが選択されています。表示される詳細は、接続されているすべての読み取りプール インスタンスとそのノードについて集計されます。
2. データベース。特定のデータベースまたはすべてのデータベースのクエリ負荷をフィルタリングします。
3. ユーザー。特定のユーザー アカウントからのクエリ負荷をフィルタリングします。
4. クライアント アドレス。特定の IP アドレスからのクエリ負荷をフィルタリングします。
5. 期間。時間、日、週、カスタム範囲などの期間でクエリ負荷をフィルタリングします。

注: Gemini in Databases を有効にする場合、クエリ指標のデータ保持ポリシーは 30 日間です。

Query Insights の構成を編集する

Query Insights は、AlloyDB インスタンスでデフォルトで有効になっています。デフォルトの Query Insights 構成を編集できます。

AlloyDB インスタンスの Query Insights 構成を編集する手順は次のとおりです。

コンソール

1. Google Cloud コンソールで、[クラスタ] ページに移動します。

   [クラスタ] に移動

2. [リソース名] 列でクラスタをクリックします。

3. 左側のナビゲーション パネルで [Query Insights] をクリックします。

4. [クエリ分析情報] リストから [プライマリ] または [読み取りプール] を選択し、[編集] をクリックします。

5. [Query Insights] フィールドを編集します。

   1. AlloyDB が分析するクエリの長さのデフォルト制限（1, 024 バイト）を変更するには、[クエリの長さをカスタマイズする] フィールドに 256 ～ 4, 500 の数字を入力します。

      このフィールドを編集すると、インスタンスが再起動します。

      注: クエリ長の上限を大きくすると、必要なメモリが増えます。

   2. Query Insights の機能セットをカスタマイズするには、次のオプションを調整します。

      • クエリプランを有効にする。 このチェックボックスをオンにすると、クエリのサンプルの実行に使用されるオペレーションを確認できます。
        [最大サンプリング レート] フィールドに 1 ～ 20 の数値を入力します。デフォルトでは、サンプリング レートは 5 に設定されています。サンプリングを無効にするには、[クエリプランを有効にする] チェックボックスをオフにします。
        サンプリング レートは、AlloyDB がインスタンスごとにノードごとに 1 分あたりサンプリングできるクエリの最大数を決定します。
      • クライアント IP アドレスを保存する。このチェックボックスをオンにすると、クエリの送信元を把握し、その情報をグループ化して指標を実行できます。
      • アプリケーション タグを保存する。このチェックボックスをオンにすると、リクエストを行っているタグ付けされたアプリケーションを確認し、その情報をグループ化して指標を実行できます。アプリケーション タグの詳細については、仕様をご覧ください。

6. [Update instance] をクリックします。

gcloud

gcloud alloydb instances update INSTANCE \
--cluster=CLUSTER \
--project=PROJECT \
--region=REGION \
--insights-config-query-string-length=QUERY_LENGTH \
--insights-config-query-plans-per-minute=QUERY_PLANS} \
--insights-config-record-application-tags \
--insights-config-record-client-address

次のように置き換えます。

• CLUSTER: 更新するインスタンスの ID
• CLUSTER: インスタンスのクラスタの ID
• PROJECT: クラスタのプロジェクトの ID
• REGION: クラスタのリージョン（例: us-central1）
• QUERY_LENGTH: クエリの長さ（256 ～ 4,500）
• QUERY_PLANS: 1 分あたりに構成するクエリプランの数

また、次のオプション フラグを 1 つ以上使用します。

• --insights-config-query-string-length: デフォルトのクエリ長の上限を 256 ～ 4,500 バイトに設定します。デフォルトのクエリ長は 1,024 バイトです。分析クエリの場合はより長いほうが便利ですが、必要なメモリ量が増えます。クエリ長を変更するには、インスタンスを再起動する必要があります。長さの上限を超えるクエリにもタグを追加できます。
• --insights-config-query-plans-per-minute: デフォルトでは、インスタンス上のすべてのデータベースで、実行されるクエリプランのサンプルが 1 分間に最大 5 個キャプチャされます。この値を 1 ～ 20 の範囲で変更します。サンプリングを無効にするには、0 を入力します。サンプリング レートを上げると、通常は得られるデータポイントの数が増えますが、パフォーマンスのオーバーヘッドが増加する可能性があります。
• --insights-config-record-client-address: クエリの送信元であるクライアント IP アドレスを保存します。これにより、そのデータをグループ化して、そのデータに対して指標を実行できます。クエリは複数のホストから送信されます。クライアント IP アドレスからのクエリのグラフを確認すると、問題の原因を特定しやすくなります。クライアント IP アドレスを保存しない場合は、--no-insights-config-record-client-address を使用します。
• --insights-config-record-application-tags: リクエストを行っている API とモデル ビュー コントローラ（MVC）のルート決定や、指標を実行するためのデータのグループ化に役立つアプリケーション タグを保存します。このオプションでは、特定のタグセットを使用してクエリにコメントする必要があります。アプリケーション タグを保存しない場合は、--no-insights-config-record-application-tags を使用します。

クエリのパフォーマンスを向上させる手順

Query Insights は、AlloyDB クエリのトラブルシューティングを行い、パフォーマンスの問題を特定します。Query Insights ダッシュボードには、選択された要素に基づいて、クエリ負荷が表示されます。クエリ負荷は、選択された時間範囲内のインスタンス内のすべてのクエリの合計作業量の測定値です。

Query Insights では、クエリのパフォーマンスの問題を検出して分析できます。Query Insights では、次の 4 つの手順でクエリのトラブルシューティングを行います。

1. すべてのクエリのデータベース負荷を表示します。
2. 問題がある可能性のあるクエリまたはタグを特定します。
3. クエリまたはタグを調べて問題を特定します。
4. 問題の原因を特定します。

すべてのクエリのデータベース負荷を表示する

トップレベルの Query Insights ダッシュボードには、フィルタされたデータを使用して [データベースの負荷 - すべての上位クエリ] グラフが表示されます。データベースのクエリ負荷は、選択したデータベースで実行されたクエリの作業量の経時的な測定結果（CPU 秒単位）です。実行中の各クエリは、CPU リソース、IO リソース、またはロックリソースを使用または待機しています。データベースのクエリ負荷は、実時間に対する、指定の時間枠内で完了したすべてのクエリで要した時間の比率です。

グラフの色付きの線で、クエリ負荷を 4 つのカテゴリに分けて表示します。

• CPU 容量: インスタンスで利用可能な CPU の数。

• CPU と CPU 待機: 実時間に対する、アクティブな状態のクエリで要した時間の比率。IO 待機とロック待機は、アクティブ状態のクエリをブロックしません。この指標は、クエリが CPU を使用している可能性があることを示します。または、他のプロセスが CPU を使用しているときに Linux スケジューラがクエリを実行しているサーバー プロセスをスケジューリングするのをクエリが待機している可能性もあります。

  注: CPU 負荷では、ランタイムと、Linux スケジューラが実行中のサーバー プロセスをスケジューリングするのを待機する時間の両方が考慮されます。その結果、CPU 負荷が最大コアラインを超える可能性があります。

• IO 待機: 実時間に対する、IO を待機していたクエリで要した時間の比率です。IO 待機には、読み取り IO 待機と書き込み IO 待機が含まれます。PostgreSQL のイベント テーブルをご覧ください。IO 待機に関する情報の内訳が必要な場合は、Cloud Monitoring で確認できます。詳細については、指標グラフをご覧ください。

• ロック待機: 実時間に対する、ロックを待機していたクエリで要した時間の比率。通常のロック待機の他に、LwLock 待機と BufferPin ロック待機が含まれます。ロック待機に関する情報の内訳が必要な場合は、Cloud Monitoring で確認できます。詳細については、指標グラフをご覧ください。

次に、グラフを確認し、フィルタのオプションを使って次の質問に答えます。

1. クエリ負荷は高いですか？グラフは時間の経過にともなって増加または減少していますか？負荷が高くない場合は、クエリに問題はありません。
2. 高い負荷がどのくらい続いていますか？高いのは今だけですか？それとも、長い間、高いですか？範囲の選択を使用して、さまざまな期間を選択して、問題が発生した期間を探します。あるいは、クエリ負荷の急増が観測される時間枠を拡大表示できます。縮小表示して最大 1 週間のタイムラインを表示することもできます。
3. 高い負荷の原因は何ですか？CPU 容量、CPU と CPU 待機、ロック待機、IO 待機を確認するオプションを選択できます。これらの各オプションのグラフの色は異なるため、どこで最も負荷が高くなっているかを確認できます。グラフの濃い青色の線は、システムの最大 CPU 容量を示しています。これにより、クエリ負荷をシステムの最大 CPU 容量と比較できます。この比較を行うことで、インスタンスの CPU リソースが不足しているかどうかを把握できます。
4. どのデータベースで負荷が発生していますか？[データベース] プルダウン メニューからデータベースを選択して、負荷が最も高いデータベースを特定します。
5. 特定のユーザーまたは IP アドレスが高負荷の原因となっていますか？プルダウン メニューからユーザーとアドレスを選択して、どれが高負荷の原因となっているかを比較できます。

データベース負荷のフィルタリング

[クエリとタグ] セクションでは、選択したクエリまたは SQL クエリタグのクエリ負荷をフィルタまたは並べ替えることができます。

クエリでフィルタリングする

[クエリ] テーブルでは、クエリ負荷が最も大きいクエリの概要を確認できます。このテーブルには、Query Insights ダッシュボードで選択された時間枠とオプションに対応する、正規化されたすべてのクエリが表示されます。

デフォルトでは、テーブルは選択した時間枠内の合計実行時間でクエリを並べ替えます。

テーブルをフィルタするには、[クエリのフィルタリング] からプロパティを選択します。テーブルを並べ替えるには、列見出しを選択します。テーブルには以下のプロパティが表示されます。

• クエリ文字列。正規化されたクエリ文字列です。Query Insights では、クエリ文字列のうち 1,024 文字のみが表示されます（デフォルト）。

  UTILITY COMMAND というラベルの付いたクエリには通常、BEGIN、COMMIT、EXPLAIN コマンド、またはラッパー コマンドが含まれます。

• データベース。クエリが実行されたデータベース。

• 負荷（合計実行時間別） / 負荷（CPU 別） / 負荷（IO 待機別） / 負荷（ロック待機別）。これらのオプションにより、特定のクエリをフィルタリングして、各オプションの最大負荷を見つけることができます。

• 平均実行時間（ミリ秒）。すべてのサブタスクがすべての並列ワーカーでクエリを完了するために要する合計時間。詳細については、平均実行時間と継続時間をご覧ください。

• 呼び出された回数。アプリケーションによってクエリが呼び出された回数。

• 取得した平均行。クエリに対して取得された行数の平均。

Query Insights は正規化されたクエリを表示します。つまり、文字定数は $1、$2 などに置換されます。次に例を示します。

UPDATE
  "demo_customer"
SET
  "customer_id" = $1::uuid,
  "name" = $2,
  "address" = $3,
  "rating" = $4,
  "balance" = $5,
  "current_city" = $6,
  "current_location" = $7
WHERE
  "demo_customer"."id" = $8

この定数値は無視されるため、Query Insights は類似したクエリを集計し、定数で表示される可能性のある PII 情報を削除できます。

クエリタグでフィルタリングする

アプリケーションのトラブルシューティングを行うには、最初に SQL クエリにタグを追加する必要があります。

Query Insights は、アプリケーション中心のモニタリングを提供して、ORM を使用して構築されたアプリケーションのパフォーマンスの問題を診断できるようにします。

アプリケーション スタック全体の担当者である場合、Query Insights で、アプリケーションの視点からクエリをモニタリングできます。クエリのタグ付けは、ビジネス ロジック、マイクロサービス、他のコンストラクトの使用など、より高レベルなコンストラクトで問題を見つけるために役立ちます。たとえば、支払いタグ、在庫タグ、ビジネス分析タグ、出荷タグなどを使用して、ビジネス ロジックでクエリにタグを付けることができます。このようにすることで、さまざまなタイプのビジネス ロジックごとに作成されるクエリ負荷を特定できます。たとえば、午後 1 時のビジネス分析タグの急上昇など、予期しないイベントが発生するかもしれません。あるいは、前週に決済サービス トレンドの予期しない増加が確認されるかもしれません。

クエリ負荷タグは、選択したタグのクエリ負荷の内訳の時間変化を示します。

タグのデータベース負荷を計算するために、Query Insights は選択したタグを使用するすべてのクエリにかかる時間を使用します。Query Insights は、実時間を使用して 1 分間隔で完了時間を計算します。

Query Insights ダッシュボードで、[タグ] を選択して [タグ] テーブルを表示します。[タグ] テーブルは、合計負荷を合計時間で割った値でタグを並べ替えます。

テーブルを並べ替えるには、[クエリのフィルタリング] からプロパティを選択するか、列見出しをクリックします。テーブルには以下のプロパティが表示されます。

• アクション、コントローラ、フレームワーク、ルート、アプリケーション、DB ドライバ。クエリに追加したプロパティは、列として表示されます。タグでフィルタリングする場合は、これらのプロパティのうち少なくとも 1 つを追加する必要があります。
• 負荷（合計実行時間別） / 負荷（CPU 別） / 負荷（IO 待機別） / 負荷（ロック待機別）。これらのオプションにより、特定のクエリをフィルタリングして、各オプションの最大負荷を見つけることができます。
• 平均実行時間（ミリ秒）。すべてのサブタスクがすべての並列ワーカーでクエリを完了するために要する合計時間。詳細については、平均実行時間と継続時間をご覧ください。
• 呼び出された回数。アプリケーションによってクエリが呼び出された回数。
• 取得した平均行。クエリに対して取得された行数の平均。
• データベース。クエリが実行されたデータベース。

特定のクエリまたはタグの調査

クエリまたはタグが問題の根本原因であるかどうかを確認するには、[クエリ] タブまたは [タグ] タブで次の操作を行います。

1. [負荷（合計実行時間別）] ヘッダーをクリックして、リストを降順で並べ替えます。
2. 負荷が最も高く、他のクエリより時間がかかっているクエリまたはタグをクリックします。

選択したクエリまたはタグの詳細を示すダッシュボードが開きます。

クエリを選択した場合は、選択したクエリの概要が表示されます。

タグを選択した場合は、選択したタグの概要が表示されます。

特定のクエリまたはタグの負荷を調査する

[データベースの負荷 - 特定のクエリ] グラフは、選択した正規化クエリが選択したクエリで時間の経過に伴って行った作業量（CPU 秒）の測定結果を示します。実時間の 1 分間隔で完了した正規化クエリで要した時間を使用して、負荷を計算します。テーブルの上部に、（集計と PII の理由から文字が削除された）正規化されたクエリの最初の 1, 024 文字が表示されます。全クエリのグラフと同様に、データベース、ユーザー、クライアント アドレスで、特定のクエリの負荷をフィルタリングできます。クエリ負荷は、CPU 容量、CPU と CPU 待機、IO 待機、ロック待機に分割されます。

[データベースの負荷 - 特定のタグ] グラフは、選択したタグに一致するクエリが選択したデータベースで行った作業量（CPU 秒）の測定結果を時系列で示します。全クエリのグラフと同様に、データベース、ユーザー、クライアント アドレスで、特定のタグの負荷をフィルタリングできます。

レイテンシを調べる

クエリまたはタグのレイテンシを調べるには、レイテンシ グラフを使用します。レイテンシとは、正規化されたクエリの実行に要した実時間です。レイテンシ ダッシュボードには、外れ値の動作を見つけるために 50 番目、95 番目、および 99 番目のパーセンタイル・レイテンシが表示されます。

並列クエリのレイテンシは実時間で測定されます。ただし、クエリの一部を実行する際に複数のコアが使用されることによって、クエリの負荷がより高い数値になる場合があります。

以下のことを確認して、問題を絞り込んでみてください。

1. 高い負荷の原因は何ですか？CPU 容量、CPU と CPU 待機、ロック待機、IO 待機を確認するオプションを選択します。
2. 高い負荷がどのくらい続いていますか？高いのは今だけですか？それとも、長い間、高いですか？期間を変更して、負荷が悪化しはじめた日時を見つけます。
3. レイテンシの急増はありますか？時間枠を変更して、正規化されたクエリの履歴レイテンシを調べることができます。

負荷が最も高い領域と時間が見つかったら、さらにドリルダウンできます。

クラスタ全体のレイテンシを確認する

クラスタ内のインスタンスにわたるクエリまたはタグの P99 レイテンシを調べるには、クラスタ全体での同じクエリに対する P99 レイテンシグラフを使用します。

サンプリングされたクエリプランでのオペレーションの調査

クエリプランは、クエリのサンプルを取得し、それを個々のオペレーションに分割します。クエリ内の各オペレーションが説明され、分析されます。[クエリプランのサンプル] グラフには、特定の時間に実行されているすべてのクエリプランと、各プランの実行にかかった時間が表示されます。

サンプル クエリプランの詳細を表示するには、[クエリプランのサンプル] グラフのドットをクリックします。すべてではありませんが、ほとんどのクエリで、実行されたサンプル クエリプランが表示されます。開かれた詳細は、クエリプランのすべてのオペレーションのモデルを示しています。オペレーションごとに、レイテンシ、返される行、そのオペレーションの費用が表示されます。オペレーションを選択すると、共有ヒットブロック、スキーマのタイプ、実際のループ、プラン行などの詳細を確認できます。

以下の質問を確認して、問題を絞り込んでみてください。

1. リソースを消費しているのは何ですか？
2. 他のクエリとどのように関係していますか？
3. 消費は時間とともに変化していますか？

問題の原因の特定

特定のモデル、ビュー、コントローラ、ルート、ホスト、ユーザーなど、問題の原因を特定できるように、Query Insights では、コンテキストに応じたエンドツーエンドのアプリケーション トレースビューが表示されます。特定のリクエストのデータベース レイヤで何が起こっているかを理解し、モデル、ビュー、コントローラ、ルートによって問題のあるクエリのソースを見つけることができます。OpenCensus または OpenTelemetry を有効にすると、opencensus スパンの情報が SQL コメント内のタグ情報とともにデータベースに送信されます。アプリケーションから Cloud Logging に送信されたトレースは、データベース クエリプラン トレースにリンクされて、問題の原因を特定します。[サンプルクエリ] 画面の [エンドツー エンド] タブをクリックすると、インコンテキスト トレースが表示されます。

問題を起こしているクライアントとユーザーを特定するには、トップ クライアント アドレスとトップユーザーのテーブルを使用して、負荷が最大のものを探します。ユーザーまたは IP アドレスをフィルタに追加して、特定のユーザーまたはクライアント アドレスをさらに分析できます。

クエリについては、Cloud Trace を使用して、クエリプランの各手順をエンドツー エンドでトレースして確認できます。Query Insights ダッシュボードで [トレースで表示] のリンクをクリックして、Cloud Trace ツールを開きます。

Cloud Trace のツールの使用方法について詳しくは、トレースの検索と表示をご覧ください。

SQL クエリへのタグの追加

SQL クエリにタグを追加すると、アプリケーションのトラブルシューティングが簡単になります。SQL クエリにタグを追加するには、sqlcommenter を使用します。このとき、オブジェクト リレーショナル マッピング（ORM）で自動で追加することも、手動で追加することもできます。

ORM での sqlcommenter の使用

SQL クエリを直接記述する代わりに、ORM を使用すると、パフォーマンスの問題を引き起こすアプリケーション コードを見つけられないことがあります。また、アプリケーション コードによるクエリのパフォーマンスへの影響の分析に支障をきたすことがあります。この問題に対処するため、Query Insights には ORM インストルメンテーション ライブラリである sqlcommenter というオープンソース ライブラリが用意されています。このライブラリは、デベロッパーが ORM と管理者を使用して、パフォーマンスの問題を引き起こしているアプリケーション コードを検出するのに役立ちます。

ORM と sqlcommenter を組み合わせて使用している場合、タグが自動的に作成されます。カスタムコードの変更やアプリケーションへの追加は必要もありません。

sqlcommenter はアプリケーション サーバーにインストールできます。インストゥルメンテーション ライブラリを使用すると、MVC フレームワークに関連するアプリケーション情報を、SQL コメントとしてクエリとともにデータベースに伝播できます。データベースはこれらのタグを取得し、正規化されたクエリによって集計される統計とは無関係に、タグによる統計の記録と集計を開始します。Query Insights でタグが表示されるため、クエリ負荷の原因となったアプリケーションを把握できます。この情報により、パフォーマンスの問題を引き起こしているアプリケーション コードを検出できます。

SQL データベース ログの結果を調べると、次のように表示されます。

SELECT * from USERS /*action='run+this',
controller='foo%3',
traceparent='00-01',
tracestate='rojo%2'*/

サポートされるタグには、コントローラ名、ルート、フレームワーク、アクションが含まれます。

一連の sqlcommenter の ORM は、さまざまなプログラミング言語でサポートされています。

Python	Django psycopg2 Sqlalchemy Flask
Java	Hibernate Spring
Ruby	Rails
Node.js	Knex.js Sequelize.js Express.js

sqlcommenter の詳細と、ORM フレームワークで sqlcommenter を使用する方法については、GitHub の sqlcommenter のドキュメントをご覧ください。

sqlcommenter を使用した手動でのタグの追加

ORM を使用していない場合は、SQL クエリに手動で sqlcommenter タグを追加する必要があります。クエリでは、シリアル化された Key-Value ペアを含むコメントで各 SQL ステートメントを拡張する必要があります。次のキーの少なくとも 1 つを使用します。

• action=''
• controller=''
• framework=''
• route=''
• application=''
• db driver=''

Query Insights は、他のすべてのキーを無視します。正しい SQL コメント形式については、sqlcommenter のドキュメントをご覧ください。

実行時間と実行時間

クエリ分析情報には、平均実行時間（ms）指標があります。これは、すべての並列ワーカーのすべてのサブタスクがクエリを完了するために要した合計時間を報告します。この指標は、CPU オーバーヘッドが最も高いクエリを特定して最適化することで、データベースの総リソース使用率を最適化するのに役立ちます。

経過時間を表示するには、psql クライアントで \timing コマンドを実行してクエリの所要時間を測定します。クエリの受信から PostgreSQL サーバーがレスポンスを送信するまでの時間を測定します。この指標は、特定のクエリに時間がかかっている理由を分析し、実行時間を短縮するために最適化するかどうかを判断するのに役立ちます。

クエリが単一のタスクによってシングルスレッドで完了した場合、所要時間と平均実行時間は同じです。

次のステップ

• Query Insights の概要
• AlloyDB の Enhanced Query Insights を使用してクエリのパフォーマンスを向上させる
• AlloyDB の指標
• SQL Commenter についてのブログ: Sqlcommenter のご紹介: オープンソース ORM の自動インストルメンテーション ライブラリ
• 手法についてのブログ: Sqlcommenter を使用してクエリのタグ付けを有効にする