サブクエリ結合を使用してクエリを結合する

New Relic 内に保存されているデータの多くは、他のデータ ( TransactionとTransactionError 、 PageViewとPageAction 、 Log 、インフラストラクチャ イベントなど) に関連しています。 サブクエリ結合を使用して、分析を実行し、これらのイベント間の相関関係を計算できます。

サブクエリ結合の書き方

サブクエリは 、別のクエリ内にネストされたクエリです。サブクエリ結合を使用すると、キーに基づいてサブクエリの結果とその外部クエリの結果を組み合わせることができ、データセット全体の分析と強化が可能になります。

サブクエリ結合には、2 つのデータセットと、2 つをリンクする主キーという 3 つのコンポーネントが必要です。

FROM Event [INNER|LEFT] JOIN (subquery) ON [key =] key SELECT ...

サブクエリ結合には、構文に対する簡単なルールが含まれています。

• JOIN句は常にFROM句の直後に続く必要があります。
• JOIN先頭に結合タイプを付けることができます。 INNERまたはLEFTはオプションで、省略した場合のデフォルトはINNERです。
• サブクエリを含むかっこは、 JOIN句の直後に置く必要があります。
• ON句はサブクエリの直後に続く必要があり、2 つの形式があります (詳細は以下を参照)。

1 つのクエリに複数のJOIN句を含めることもできます。 たとえば、このクエリはサブクエリ内で 2 つのJOINを使用します。

FROM JavaScriptError
  JOIN (
    FROM PageAction
      JOIN (
        FROM PageView SELECT count(*) FACET session AS pageViewSession, city
        LIMIT MAX
      ) ON session = pageViewSession
    SELECT count(*) FACET city, currentUrl, session AS pageActionSession
  ) ON session = pageActionSession
SELECT count(*) FACET city, currentUrl, session, errorClass

以下の画像には、インフラストラクチャ コンテナ ( ProcessSample ) の平均 CPU パーセンテージとコンテナによるアプリの平均継続時間の 2 つのデータセットが含まれています。

多くの場合、異なるソースからのデータは相互に関連付けられます。 この場合、次のサブクエリ結合を使用して、コンテナーの CPU 使用率の上昇がトランザクションの速度低下の原因となっているかどうかを判断できます。

FROM Transaction
  JOIN (FROM ProcessSample SELECT average(cpuPercent) AS cpu
  FACET containerId LIMIT MAX) ON containerId
SELECT average(duration)/latest(cpu) FACET containerId, containerName

このクエリを使用すると、CPU 使用率を考慮して平均トランザクション時間が長いコンテナーを確認し、異常値を調査して修正すべきバグや最適化が必要かどうかを確認できます。

サブクエリ結合の制限事項

サブクエリ結合には次の制限があります。

• 結合されたサブクエリのデフォルトのLIMITは引き続き 10 で、最大LIMITは 5,000 です。 外側のクエリのLIMIT内側のクエリに影響を与えないことに注意してください。
• 結合サブクエリでの TIMESERIES の使用はサポートされていません。外側のクエリで TIMESERIESを使用する場合、結合されたサブクエリはクエリのタイムスパン全体にわたって 1 つの結果を提供することに注意してください。
• 結合サブクエリでの COMPARE WITH の使用はサポートされていません。外側のクエリで COMPARE WITHを使用する場合、結合されたサブクエリはクエリの基本タイムスパンに基づいて単一の結果を提供し、タイムスパンと比較する外側のクエリに別の値を提供しないことに注意してください。
• すべてのサブクエリと同様に、結合されたサブクエリはアラート条件では使用できません。
• SELECT *は親クエリではサポートされていますが、結合されたサブクエリではサポートされていません。
• 結合のカーディナリティは 1:100 に制限されています。つまり、1 つの結合キーはサブクエリ結果の 100 を超える行にマップできません。
• ON句は等価条件のみをサポートします。
• JOINキーは、メトリクス値のような複雑な属性にすることはできません。
• JOIN条件では属性タイプの強制は行われません。 JOINのON条件の左側は、 ON条件の右側と同じ型である必要があります。
• メトリクス ワイルドカードは、 JOINのON条件ではサポートされていません
• サブクエリをメトリクスの行単位のクエリにすることはできません。
• JOINのON条件の右側は、クエリによって投影された識別子である必要があります。関数や数学演算は使用できません。
• 結合されたサブクエリは uniques() 結果を投影できません。

サブクエリ結合の例

サブクエリ結合の例をいくつか示します。

不足しているデータを追加する

この例では、APM データは 2 つの場所にあります。 PageView はエンド ユーザーが訪問したページに関する情報を提供し、 PageAction はページ上で実行されたアクションを提供します。これら 2 つのイベントには両方ともエンド ユーザーのセッションを識別するセッション ID がありますが、一部のデータは一方のイベントに含まれ、もう一方のイベントには含まれません。

ここで、 cityはPageViewの属性ですが、 PageActionではありません。一方、 currentUrlは、 PageActionの属性ですが、 PageViewではありません。

サブクエリ結合を使用すると、不足しているデータで PageAction データセットを強化できます。セッション ID を使用してデータを結合すると、最もクリック数が多かった URL だけでなく、これらのアクションがどこから来たのかも確認できます。

FROM PageAction
  JOIN (FROM PageView SELECT count(*) FACET session, city
  LIMIT MAX) ON session
SELECT count(*) FACET city, currentUrl

コピー

ヒント: 外側のクエリに結合される結果の数を最大化するには、内側のサブクエリにLIMIT MAXを含めます。 現在の最大結果制限は 5,000 行です。

データセット全体の計算

この例では、2 つのログ データセットが相互に一致するように解析され、ログ エラーの割合を求める計算が実行されます。

ログには、ログメッセージ内にデータが埋め込まれている場合があります。 aparse()のような強化された文字列解析関数を使用すると、キーの値を抽出できます。 この場合、主キーのアプリケーション ID は、 LogとLog_Errorの両方のログメッセージ内にあります。

アプリケーションごとのエラーの割合を確認するには、 LEFT JOINが必要です。 これは、すべてのアプリケーションにエラーがあるわけではなく、 INNER JOINによってこれらのアプリケーションが除外されるためです。

WITH numeric(aparse(message, '%applicationId: * %')) AS application_Id
FROM Log
  LEFT JOIN (FROM Log_Error SELECT count(*) AS errCnt
     FACET numeric(aparse(message, '%appId: * %')) AS app_Id
     SINCE 1 day ago LIMIT MAX) ON application_Id=app_Id
SELECT (latest(errorCount) OR 0)/count(*) AS errorPercentage
FACET app_name, application_Id SINCE 1 day ago

コピー

データが 2 つの異なるログ パーティションに保存されており、アプリケーション ID がログメッセージに隠されていたとしても、サブクエリ結合により必要なデータを解析し、エラーの割合を計算することができました。 latest()を使用すると、内部クエリの集計が外部クエリで正しく計算されていることを確認するのにも役立ちます。