Partager via

Surveiller les performances des graphiques dans Microsoft Fabric

Note

Cette fonctionnalité est actuellement disponible en préversion publique. Cette préversion est fournie sans contrat de niveau de service, et n’est pas recommandée pour les charges de travail de production. Certaines fonctionnalités peuvent être limitées ou non prises en charge. Pour plus d’informations, consultez les Conditions d’utilisation Complémentaires de Microsoft Azure Previews.

Les performances du graphe dans Microsoft Fabric dépendent de la taille du graphique, de la complexité du modèle, des modèles de requête et de la disponibilité de la capacité. Découvrez comment surveiller, identifier les goulots d’étranglement et les actions à entreprendre lorsque les travaux d’actualisation sont lents ou que les requêtes ne retournent pas de résultats comme prévu.

Pour le suivi de l’état des travaux d’actualisation de base, consultez Surveiller les charges de travail de graphe. Pour connaître les techniques d’optimisation des requêtes GQL, consultez Optimiser les performances des requêtes GQL.

Prerequisites

Avant de commencer, vérifiez que vous :

Facteurs qui affectent les performances du graphique

Plusieurs facteurs interconnectés affectent les performances du graphique. Diagnostiquer les actualisations lentes et les requêtes lentes en comprenant ce qui les pilote.

Taille et complexité du graphique

  • Les graphiques avec plus de 500 millions de nœuds et de arêtes entraînent des performances instables. Pour obtenir la liste complète des limites, consultez limitations actuelles.
  • Chaque type de nœud supplémentaire, type de périphérie et propriété ajoute aux données que le graphique charge pendant une actualisation. La suppression des types de nœuds inutilisés, des types de périphérie et des propriétés de votre modèle réduit le temps d’actualisation.
  • Les graphiques denses (de nombreux bords par nœud) augmentent le coût de traversée. Si la plupart des nœuds se connectent à des milliers d’autres nœuds, les requêtes qui parcourent plusieurs tronçons deviennent coûteuses.

Caractéristiques des données sources

  • Le graphique lit directement des tables du lakehouse dans OneLake. Les tables sources volumineuses avec de nombreuses colonnes prennent plus de temps à ingérer.
  • Si vos tables sources incluent des colonnes dont vous n’avez pas besoin dans le graphe, supprimez ces propriétés pendant la modélisation de graphe. Chaque propriété ajoute aux données lues pendant l’actualisation et l’empreinte mémoire du graphique interrogeable.

Modèles de requête

  • Les requêtes qui parcourent de nombreux tronçons, retournent des nœuds complets (RETURN *) ou produisent des jeux de résultats non liés consomment plus de ressources et prennent plus de temps à s’exécuter.
  • Les filtres au niveau du schéma, les projections étroites et LIMIT clauses réduisent le travail effectué par le moteur de requête. Pour obtenir des techniques spécifiques, consultez Optimiser les performances des requêtes GQL.

Capacité et concurrence

  • Les travaux d’actualisation du graphique et les requêtes consomment des unités de capacité Fabric mises en pool . D’autres charges de travail dans la même capacité sont en concurrence pour ces ressources.
  • Si les travaux d’actualisation sont constamment lents, vérifiez si d’autres charges de travail à forte consommation s’exécutent en même temps à l’aide de l’application Métriques de capacité Microsoft Fabric.

Surveiller les performances d’actualisation

Utilisez le hub de surveillance pour suivre la durée d’actualisation des graphiques et déterminer s’ils réussissent ou échouent. Pour obtenir des instructions pas à pas sur l’accès au hub de monitoring, consultez Surveiller les charges de travail graphiques.

Identifier les actualisations lentes

Comparez les durées d’actualisation au fil du temps pour établir une base de référence pour votre graphique. Une actualisation qui prend beaucoup plus de temps que d’habitude peut indiquer :

  • Croissance des données sources : les tables lakehouse sous-jacentes ont augmenté, en ajoutant davantage de données pour l’ingestion de graphiques.
  • Augmentation de la complexité du modèle : de nouveaux types de nœuds, types de périphérie ou propriétés ont été ajoutés au modèle.
  • Pression de la capacité : d’autres charges de travail consomment une plus grande part de la capacité disponible.

Répondre aux échecs d’actualisation

Les travaux d’actualisation du graphique peuvent échouer lorsqu’ils dépassent le délai d’expiration de 20 minutes. Pour les graphiques volumineux, ce délai d’expiration peut entraîner une défaillance jusqu’à une fois par semaine. Si une actualisation échoue :

  1. Ouvrez le hub de surveillance et recherchez le travail d’actualisation ayant échoué.
  2. Sélectionnez la tâche pour afficher les détails de l’erreur et les informations de synchronisation.
  3. Si l'échec est dû à un délai d'expiration, réessayez ; l'actualisation suivante réussit habituellement. Si des délais d’expiration se produisent à plusieurs reprises, réduisez la taille du graphique en supprimant les types de nœuds inutilisés, les types de périphérie ou les propriétés.
  4. Si l’échec a été provoqué par une erreur de configuration, ouvrez votre modèle de graphe et vérifiez que les mappages de types de nœud et de périphérie, les colonnes d’ID et les colonnes de clé étrangère sont corrects.

Pour plus d’informations sur la résolution des problèmes, consultez résolution des problèmes et FAQ.

Superviser les performances des requêtes

Pendant la préversion, les métriques de requête GQL individuelles ne sont pas disponibles dans le hub de surveillance. Utilisez plutôt ces approches pour comprendre et améliorer les performances des requêtes.

Observer le comportement des requêtes dans l’éditeur de code

Lorsque vous exécutez une requête GQL dans l’éditeur de code, observez :

  • Temps de réponse : durée pendant laquelle la requête retourne les résultats. Les requêtes lentes impliquent généralement des traversées profondes, des correspondances non liées ou des jeux de résultats volumineux.
  • Taille du résultat : les jeux de résultats volumineux (approche de la limite de troncation de 64 Mo) indiquent que la requête a besoin de limites ou de filtrage plus strictes. Si les résultats sont tronqués, ajoutez LIMIT, FILTERou WHERE des clauses pour affiner la sortie.
  • Résultats vides après une actualisation réussie : cette situation signifie généralement que la configuration du modèle de graphique ne correspond pas aux données sous-jacentes. Vérifiez que les mappages de type de nœud pointent vers les tables et colonnes sources appropriées.

Problèmes de performance des requêtes et actions possibles

Symptôme Cause probable Action
La requête prend plus de quelques secondes Traversée profonde (nombre de tronçons élevés) ou filtres manquants Ajoutez des clauses de modèle de niveau WHERE, réduisez la portée de saut, et appliquez LIMIT.
La requête ne retourne aucun résultat Configuration incorrecte des types de nœud ou de périphérie ou tables sources vides Vérifiez les mappages de modèles et vérifiez que les données sources existent.
Les résultats de la requête sont tronqués Le jeu de résultats dépasse 64 Mo Projections étroites avec des propriétés spécifiques au lieu de RETURN *, et ajouter LIMIT.
Les agrégations sont lentes ou instables Le jeu de résultats dépasse 128 Mo avant l’agrégation Ajoutez des filtres pour réduire les résultats intermédiaires avant GROUP BY.
Délai d’expiration des requêtes (limite de 20 minutes) Traversée multisaut non bornée sur un graphe dense Utilisez TRAIL pour empêcher les revisites de liens, resserrer les limites des sauts et ajouter LIMIT.

Pour obtenir des stratégies détaillées d’optimisation des requêtes, consultez Optimiser les performances des requêtes GQL.

Suivre l’utilisation de la capacité

Utilisez l’application Métriques de capacité Microsoft Fabric pour comprendre comment les charges de travail de graphique affectent votre consommation globale de capacité. L’application vous aide à :

  • Comparez l’utilisation de la capacité entre les travaux d’actualisation de graphique et d’autres charges de travail Fabric.
  • Identifiez les périodes où la pression de la capacité peut ralentir les actualisations du graphique.
  • Décidez quand mettre à l’échelle votre capacité vers le haut ou vers le bas en fonction des tendances d’utilisation.

Pour plus d’informations, consultez Installer l’application Métriques de capacité Microsoft Fabric.

Résumé des meilleures pratiques en matière de performances

  • Taille appropriée de votre modèle : supprimez les types de nœuds, les types de périphérie et les propriétés dont vous n’avez pas besoin. Les modèles plus petits s’actualisent plus rapidement et consomment moins de mémoire.
  • Filtrez tôt, projetez de manière ciblée : utilisez des clauses de niveau WHERE motif et retournez uniquement les propriétés dont vous avez besoin. Évitez RETURN *.
  • Limitez vos résultats : appliquez LIMIT aux requêtes à cardinalité élevée. Conservez les résultats largement en dessous du seuil de troncation de 64 Mo.
  • Garder les traversées superficielles : utilisez la plage de tronçons la plus serrée que votre scénario autorise. Permet TRAIL d’éviter les chemins redondants dans des graphiques denses.
  • Surveiller les tendances d’actualisation : établissez une durée d’actualisation de référence et examinez quand les actualisations s’écartent considérablement.
  • Vérifier la capacité pendant les ralentissements : utilisez l’application Métriques de capacité pour déterminer si la pression de capacité est la cause.

Contenu connexe

  • Last updated on