Utiliser des jointures de sous-requêtes pour combiner des requêtes

Une grande partie des données stockées dans New Relic se rapportent à d'autres données : Transaction et TransactionError, PageView et PageAction, Log et événement infrastructure , et plus encore. Vous pouvez effectuer des analyses et calculer des corrélations entre ces événements à l'aide de jointures de sous-requêtes.

Comment écrire une jointure de sous-requête

Une sous-requête est une requête imbriquée dans une autre requête. Avec les jointures de sous-requêtes, vous pouvez combiner le résultat d'une sous-requête avec le résultat de sa requête externe en fonction d'une clé, permettant ainsi l'analyse et l'enrichissement des ensembles de données.

Une jointure de sous-requête nécessite trois composants : deux ensembles de données et une clé primaire pour les lier ensemble.

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

Les jointures de sous-requêtes contiennent des règles simples concernant la syntaxe :

• La clause JOIN doit toujours suivre immédiatement la clause FROM .
• Vous pouvez préfixer le JOIN avec le type de jointure. INNER ou LEFT est facultatif et la valeur par défaut est INNER lorsqu'il est omis.
• Les parenthèses contenant une sous-requête doivent immédiatement suivre la clause JOIN .
• La clause ON doit suivre immédiatement la sous-requête et a deux formes (plus de détails ci-dessous).

Vous pouvez également avoir plusieurs clauses JOIN dans une requête. Par exemple, cette requête utilise deux JOINdans les sous-requêtes :

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

L'image ci-dessous contient deux ensembles de données : le pourcentage moyen de CPU du conteneur infrastructure (ProcessSample) et la durée moyenne des transactions d'application par conteneur.

Souvent, les données provenant de différentes sources sont corrélées. Dans ce cas, vous pouvez déterminer si l'utilisation plus élevée du processeur d'un conteneur entraîne des transactions plus lentes en utilisant la jointure de sous-requête suivante :

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

Avec cette requête, vous pouvez voir les conteneurs qui ont une durée de transaction moyenne plus élevée compte tenu de leur utilisation CPU, et étudier la valeur hors norme pour voir s'il y a un bug à corriger ou des optimisations à faire.

Limitations de jointure de sous-requête

Les jointures de sous-requêtes présentent les limitations suivantes :

• La sous-requête jointe continuera d'avoir une valeur par défaut LIMIT de 10, avec un maximum LIMIT de 5 000. Notez que le LIMIT de la requête externe n'affecte pas la requête interne.
• L'utilisation de TIMESERIES dans la sous-requête jointe n'est pas prise en charge. Si votre requête externe utilise TIMESERIES, gardez à l'esprit que la sous-requête jointe fournira un seul résultat pour toute la durée de la requête.
• L'utilisation de COMPARE WITH dans la sous-requête jointe n'est pas prise en charge. Si votre requête externe utilise COMPARE WITH, gardez à l'esprit que la sous-requête jointe fournira un résultat unique basé sur la durée de base de la requête et ne fournira pas de valeur distincte pour la requête externe par rapport à la durée.
• Comme toutes les sous-requêtes, les sous-requêtes jointes ne peuvent pas être utilisées en condition d'alerte.
• Bien que SELECT * soit pris en charge dans la requête parent, il n'est pas pris en charge dans la sous-requête jointe.
• La cardinalité de la jointure est limitée à 1 : 100, ce qui signifie qu'une seule clé de jointure ne peut pas correspondre à plus de cent lignes dans le résultat de la sous-requête.
• La clause ON prend uniquement en charge les conditions d’égalité.
• La clé JOIN ne peut pas être un attribut complexe, comme une valeur métrique.
• Nous n'effectuons aucune contrainte sur les types d'attributs dans la condition JOIN . Le côté gauche de la condition ON de JOIN doit être du même type que le côté droit de la condition ON .
• les caractères génériques métriques ne sont pas pris en charge dans la condition ON de JOIN
• La sous-requête ne peut pas être une requête métrique par ligne.
• Le côté droit de la condition ON du JOIN doit être un identifiant projeté par la requête. Il ne peut pas utiliser de fonction ou d’opération mathématique.
• La sous-requête jointe ne peut pas projeter un résultat uniques() .

Exemples de jointure de sous-requête

Voici quelques exemples de jointures de sous-requêtes :

Ajouter les données manquantes

Dans cet exemple, les données APM se trouvent à deux endroits : PageView fournit des informations sur une page visitée par un utilisateur final, tandis que PageAction fournit les actions effectuées sur la page. Ces deux événements ont tous deux des identifiants de session qui identifient la session d'un utilisateur final, mais certaines données sont contenues dans un événement et pas dans l'autre.

Ici, city est un attribut dans PageView mais pas dans PageAction, tandis que currentUrl est un attribut dans PageAction mais pas PageView.

Avec les jointures de sous-requêtes, vous pouvez enrichir l'ensemble de données PageAction avec les données manquantes. En combinant les données à l'aide de l'ID de session, vous pouvez voir non seulement l'URL avec le plus de clics, mais également d'où dans le monde proviennent ces actions :

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

Copier

Astuce : incluez LIMIT MAX dans la sous-requête interne pour maximiser le nombre de résultats joints à la requête externe. La limite maximale actuelle des résultats est de 5 000 lignes.

Calculs sur plusieurs ensembles de données

Dans cet exemple, deux ensembles de données log seront analysés pour correspondre l'un à l'autre, puis des calculs seront exécutés pour trouver le pourcentage d'erreur log .

Les logs peuvent souvent contenir des données enfouies dans le message de log. En utilisant des fonctions d'analyse de chaîne améliorées telles que aparse() , vous pouvez extraire la valeur clé. Dans ce cas, l'identifiant de clé primaire d'application se trouve dans le message de log de Log et Log_Error:

Afin de trouver le pourcentage d'erreur par application, un LEFT JOIN est requis. Cela est dû au fait que toutes les applications ne comportent pas d’erreurs et qu’un INNER JOIN exclurait ces applications.

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

Copier

Même si les données étaient stockées dans deux partitions log différentes et que l'identifiant d'application était caché dans le message de log, les jointures de sous-requêtes ont permis d'analyser les données nécessaires et de calculer le pourcentage d'erreur. L’utilisation de latest() était également utile pour garantir que les agrégations de la requête interne étaient calculées correctement avec la requête externe.