Résoudre les problèmes de régression des performances des requêtes

Cette page explique comment détecter les changements de vitesse d'exécution des requêtes, inspecter les plans d'exécution des requêtes et spécifier un autre index pour les futures requêtes si nécessaire.

Obtenir le profil détaillé d'une requête au format JSON à l'aide de l'API REST

Par défaut, lorsque vous exécutez une requête, l'API ne renvoie que les résultats de l'instruction. En effet, queryMode est défini sur NORMAL. Pour inclure des statistiques d'exécution détaillées dans les résultats de la requête, définissez queryMode sur PROFILE.

Créer une session

Avant de mettre à jour votre mode de requête, créez une session, qui représente un canal de communication avec le service de base de données Spanner.

  1. Accédez à la page projects.instances.databases.sessions.create.

  2. Indiquez l'ID du projet, l'ID de l'instance et l'ID de la base de données au format suivant :

    projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID

  3. Cliquez sur Exécuter. La réponse indique la session que vous venez de créer comme suit :

    projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID/sessions/SESSION_ID

    Utilisez cette session pour profiler la requête à l'étape suivante. Une session reste active pendant une heure au maximum entre deux utilisations consécutives avant que Spanner ne la supprime.

Pour en savoir plus sur l'utilisation des sessions, consultez Sessions.

Profil de la requête

Activez le mode PROFILE pour la requête.

  1. Accédez à la page projects.instances.databases.sessions.executeSql.

  2. Pour session, saisissez l'ID de session que vous avez créé dans Créer une session :

    projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID/sessions/SESSION_ID

  3. Pour le champ Request body (Corps de la requête), utilisez les lignes suivantes :

    { "sql": "SQL_QUERY", "queryMode": "PROFILE" }

  4. Cliquez sur Exécuter. La réponse inclut les résultats de la requête, le plan de requête et les statistiques d'exécution de la requête.

Résoudre les problèmes d'utilisation de l'index

Lorsque vous utilisez des requêtes SQL pour rechercher des données, Spanner utilise automatiquement tous les index secondaires susceptibles de récupérer les données plus efficacement. Toutefois, dans certains cas, Spanner peut choisir un index qui ralentit les requêtes. Par conséquent, vous remarquerez peut-être que certaines requêtes s'exécutent plus lentement que prévu.

Détecter les variations de la vitesse d'exécution des requêtes

Vous pouvez constater une modification de la vitesse d'exécution des requêtes après avoir apporté l'une des modifications suivantes :

  • Modification importante d'une grande quantité de données existantes associées à un index secondaire
  • Ajout, modification ou suppression d'un index secondaire

Vous pouvez utiliser plusieurs outils pour identifier une requête spécifique que Spanner exécute plus lentement que d'habitude :

Statistiques de l'optimiseur pour les bases de données récemment créées

Lorsque vous interrogez des bases de données nouvellement créées avec des données récemment insérées ou importées, il est possible que Spanner ne sélectionne pas les index les plus appropriés, car l'optimiseur de requêtes met jusqu'à trois jours pour collecter automatiquement les statistiques. Pour optimiser l'utilisation de l'index d'une nouvelle base de données Spanner plus rapidement, vous pouvez créer manuellement un package de statistiques.

Examinez le schéma.

Une fois que vous avez trouvé la requête à l'origine du ralentissement, examinez l'instruction SQL de la requête et identifiez les tables utilisées par l'instruction ainsi que les colonnes récupérées dans ces tables.

Ensuite, recherchez les index secondaires qui existent pour ces tables. Déterminez si l'un des index inclut les colonnes que vous interrogez, ce qui signifie que Spanner peut utiliser l'un des index pour traiter la requête.

  • S'il existe des index applicables, l'étape suivante consiste à rechercher l'index utilisé par Spanner pour la requête.

  • S'il n'y a pas d'index applicables, utilisez la commande gcloud spanner operations list pour vérifier si vous avez récemment supprimé un index applicable :

    gcloud spanner operations list \
    --instance=INSTANCE \
    --database=DATABASE \
    --filter="@TYPE:UpdateDatabaseDdlMetadata"

    Si vous avez supprimé un index applicable, cette modification peut avoir affecté les performances des requêtes. Rétablissez l'index secondaire dans la table. Une fois que Spanner a ajouté l'index, exécutez à nouveau la requête et examinez ses performances. Si les performances ne s'améliorent pas, l'étape suivante consiste à rechercher l'index utilisé par Spanner pour la requête.

    Si vous n'avez pas supprimé d'index applicable, cela signifie que la sélection d'index n'est pas à l'origine de la régression des performances de la requête. Recherchez d'autres modifications de vos données ou de vos modèles d'utilisation susceptibles d'avoir affecté les performances.

Trouver l'index utilisé pour une requête

Pour savoir quel index Spanner utilise pour traiter une requête, consultez le plan d'exécution de la requête dans la console Google Cloud  :

  1. Accédez à la page Instances de Spanner dans la consoleGoogle Cloud .

    Accéder à la page Instances

  2. Cliquez sur le nom de l'instance que vous souhaitez interroger.

  3. Dans le menu de navigation, sélectionnez la base de données que vous souhaitez interroger, puis cliquez sur Spanner Studio.

  4. Saisissez la requête à tester.

  5. Dans le menu Exécuter la requête, sélectionnez Explication uniquement. Spanner affiche le plan de requête.

Recherchez au moins un des opérateurs suivants dans le plan de requête :

  • table scan
  • index scan
  • cross apply ou distributed cross apply

Les sections suivantes présentent chaque opérateur.

Opérateur table scan

L'opérateur table scan indique que Spanner n'a pas utilisé d'index secondaire :

Opérateur d'analyse de table dans un plan de requête.

Par exemple, supposons que la table Albums ne comporte aucun index secondaire et que vous exécutez la requête suivante :

SELECT AlbumTitle FROM Albums WHERE STARTS_WITH(AlbumTitle, "Now");

Étant donné qu'il n'existe aucun index à utiliser, le plan de requête inclut un opérateur table scan.

Opérateur index scan

L'opérateur index scan indique que Spanner a utilisé un index secondaire lors du traitement de la requête :

Opérateur d'analyse d'index dans un plan de requête.

Par exemple, supposons que vous ajoutiez un index à la table Albums :

CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);

Vous exécutez ensuite la requête suivante :

SELECT AlbumTitle FROM Albums WHERE STARTS_WITH(AlbumTitle, "Now");

L'index AlbumsByAlbumTitle contient AlbumTitle, qui est la seule colonne sélectionnée par la requête. Par conséquent, le plan de requête inclut un opérateur index scan.

Opérateur cross apply

Dans certains cas, Spanner utilise un index qui ne contient que certaines des colonnes sélectionnées par la requête. Par conséquent, Spanner doit joindre l'index à la table de base.

Lorsque ce type de jointure se produit, le plan de requête inclut un opérateur cross apply ou distributed cross apply qui comporte les entrées suivantes :

  • Un opérateur index scan pour l'index d'une table
  • Un opérateur table scan pour la table propriétaire de l'index

Application croisée distribuée dans un plan de requête avec une analyse d'index et une analyse de table comme entrées.

Par exemple, supposons que vous ajoutiez un index à la table Albums :

CREATE INDEX AlbumsByAlbumTitle ON Albums(AlbumTitle);

Vous exécutez ensuite la requête suivante :

SELECT * FROM Albums WHERE STARTS_WITH(AlbumTitle, "Now");

L'index AlbumsByAlbumTitle contient AlbumTitle, mais la requête sélectionne toutes les colonnes de la table, et pas seulement AlbumTitle. Par conséquent, le plan de requête inclut un opérateur distributed cross apply, avec des opérateurs index scan AlbumsByAlbumTitle et table scan Albums comme entrées.

Choisir un autre index

Une fois que vous avez trouvé l'index utilisé par Spanner pour votre requête, essayez d'exécuter votre requête avec un autre index ou en analysant la table de base au lieu d'utiliser un index. Pour spécifier l'index, ajoutez une directive FORCE_INDEX à la requête.

Si vous trouvez une version plus rapide de la requête, mettez à jour votre application pour l'utiliser.

Consignes pour le choix d'un index

Suivez ces consignes pour déterminer l'index à tester pour la requête :

  • Si votre requête répond à l'un de ces critères, essayez d'utiliser la table de base au lieu d'un index secondaire :

    • La requête recherche l'égalité avec un préfixe de la clé primaire de la table de base (par exemple, SELECT * FROM Albums WHERE SingerId = 1).
    • De nombreuses lignes respectent les prédicats de requête (par exemple, SELECT * FROM Albums WHERE AlbumTitle != "There Is No Album With This Title").
    • La requête utilise une table de base qui ne contient que quelques centaines de lignes.

  • Si la requête contient un prédicat très sélectif (par exemple, REGEXP_CONTAINS, STARTS_WITH, <, <=, >, >= ou !=), essayez d'utiliser un index qui inclut les mêmes colonnes que celles que vous utilisez dans le prédicat.

Tester la requête mise à jour

Utilisez la console Google Cloud pour tester la requête mise à jour et découvrir le temps nécessaire pour la traiter.

Si votre requête inclut des paramètres de requête et si l'un d'entre eux est associé à certaines valeurs beaucoup plus souvent que d'autres, associez le paramètre de requête à l'une de ces valeurs dans vos tests. Par exemple, si la requête inclut un prédicat tel que WHERE country = @countryId, et si presque toutes vos requêtes associent @countryId à la valeur US, associez @countryId à US pour vos tests de performances. Cette approche vous permet d'optimiser les requêtes que vous exécutez le plus fréquemment.

Pour tester la requête mise à jour dans la console Google Cloud , procédez comme suit :

  1. Accédez à la page Instances de Spanner dans la consoleGoogle Cloud .

    Accéder à la page Instances

  2. Cliquez sur le nom de l'instance que vous souhaitez interroger.

  3. Dans le menu de navigation, cliquez sur la base de données que vous souhaitez interroger, puis sur Spanner Studio.

  4. Saisissez la requête à tester, y compris la directive FORCE_INDEX, puis cliquez sur Exécuter la requête.

    La console Google Cloud ouvre l'onglet Tableau des résultats, puis affiche les résultats de la requête, y compris le temps nécessaire au service Spanner pour traiter la requête.

    Cette métrique n'inclut pas les autres sources de latence, telles que le temps nécessaire à la console Google Cloud pour interpréter et afficher les résultats de la requête.

Limitation des requêtes

Lors de l'exécution d'une requête, Spanner peut limiter les requêtes à plusieurs endroits.

Le temps d'attente du client et le retard de la file d'attente du serveur sont les deux principales métriques de limitation.

Temps d'attente du client

Le temps d'attente du client représente le temps que le client Spanner attend que l'application consomme les résultats. Cela indique que le client ne peut pas traiter les résultats aussi rapidement que Spanner les produit. Pour résoudre ce problème, augmentez les performances de l'application consommatrice ou mettez en mémoire tampon tous les résultats dans l'application cliente et traitez-les une fois la requête terminée.

Délai de la file d'attente du serveur

Le retard de la file d'attente du serveur se produit lorsque le serveur de traitement retarde la planification de l'exécution de la requête. Dans le volet Résumé de la requête, vérifiez la métrique Délai de file d'attente du serveur. Si la métrique n'est pas présente, aucun délai de serveur ne s'est produit.

Ce délai peut indiquer que les serveurs exécutant la requête sont surchargés. Pour vérifier si un hotspot existe, consultez Rechercher des hotspots dans votre base de données. Pour résoudre les problèmes de hotspots, consultez Résoudre les problèmes de hotspots à l'aide des statistiques de division à chaud.

Données récemment modifiées

Les modifications apportées aux données d'une table peuvent affecter les performances des requêtes.

Package de statistiques obsolète

Si l'optimiseur utilise un package de statistiques obsolète, il peut choisir un plan non optimal. Dans la section Résumé de la requête, vous pouvez consulter le package de statistiques. Si le package est obsolète ou manquant, exécutez ANALYZE pour vous assurer que les statistiques de l'optimiseur sont à jour.

Package de statistiques dans le récapitulatif de la requête

Pour en savoir plus, consultez Packages de statistiques.

Modifications du contenu des tables

Les performances des requêtes dépendent des données qu'elles traitent. La meilleure façon de résoudre un problème de performances des requêtes dépend de la manière dont les données ont changé :

  • Asymétrie dans la distribution des valeurs : le package de statistiques capture cette asymétrie, mais l'optimiseur de requêtes ne peut utiliser ces informations que lorsque vous utilisez des valeurs littérales dans la requête.
  • Variation importante du nombre de lignes : évaluez si les prédicats filtrent suffisamment les lignes à mesure que la taille de la table augmente.
  • Asymétrie de la taille des valeurs : l'asymétrie de la taille des valeurs est problématique lorsqu'elle est associée à des prédicats scalaires coûteux (par exemple, l'exécution d'un prédicat LIKE sur une valeur STRING contenant des chaînes volumineuses).

Pour obtenir plus d'insights sur l'exécution des requêtes, utilisez l'API REST.