Optimiser les performances des requêtes GQL pour le graphique dans Microsoft Fabric

Cet article fournit des conseils pour l’écriture de requêtes GQL (Graph Query Language) qui s’exécutent de manière prévisible et efficace lors de l’utilisation du graphique dans Microsoft Fabric. Les recommandations sont basées sur le comportement actuel de la plateforme et les contraintes documentées.

Pour connaître les limites strictes sur la taille du graphique, la taille des résultats et le délai d’expiration des requêtes, consultez les limitations actuelles. Plusieurs recommandations de cet article concernent également la façon dont vous concevez votre schéma de graphe. Pour plus d’informations, consultez Concevoir un schéma de graphe.

Placez les filtres selon leur sémantique

Placez un prédicat à l’intérieur d’un motif de graphe lorsqu’il définit quel nœud ou arête peut participer à la correspondance. Utilisez une condition au niveau MATCH ... WHERE de l’instruction pour postfiltrer la correspondance complète, ou une instruction distincte FILTER lorsque le prédicat s’applique à la ligne produite par une instruction antérieure.

Par exemple, utilisez des clauses WHERE au niveau du motif pour définir des conditions sur les nœuds correspondants :

MATCH (p:Person WHERE p.birthday < 19940101)-[:workAt]->(c:Company WHERE c.id > 1000)
RETURN p.firstName, p.lastName, c.name

Un FILTER distinct peut exprimer la même condition après une mise en correspondance obligatoire classique qui utilise la recherche de chemin ALL par défaut :

MATCH (p:Person)-[:workAt]->(c:Company)
FILTER p.birthday < 19940101 AND c.id > 1000
RETURN p.firstName, p.lastName, c.name

L’optimiseur de requête peut appliquer des prédicats équivalents lors de la numérisation lorsque cela permet de préserver la sémantique des requêtes, donc la syntaxe en ligne n’est pas intrinsèquement plus rapide. Choisissez la forme qui exprime quand la condition s’applique.

Le placement des prédicats peut modifier les résultats avec ANY SHORTEST. Les prédicats intégrés limitent les chemins admissibles pour la sélection du chemin le plus court. Un WHERE au niveau de l’instruction ou un FILTER ultérieur s’applique après la sélection du chemin, de sorte qu’il peut supprimer un plus court chemin sélectionné sans sélectionner à la place un chemin plus long. Pour en savoir plus sur la limitation actuelle MATCH ... WHERE et sur un modèle de placement fiable, voir Placer les prédicats avant ou après la sélection de chemin.

Le placement a également son importance avec OPTIONAL MATCH, où une clause WHERE en ligne restreint la correspondance facultative, mais une clause FILTER ultérieure peut supprimer la ligne étendue par des valeurs NULL.

Conseil / Astuce

Considérez le niveau WHERE du modèle comme analogue à une condition SQL JOIN ... ON . Il indique quelles correspondances répondent aux critères, au lieu de filtrer ensuite la ligne obtenue.

Renvoyer uniquement les propriétés dont vous avez besoin

Retournez uniquement les propriétés de nœud et de périphérie dont votre scénario a besoin. Évitez de retourner des nœuds complets ou d’utiliser RETURN * quand vous n’avez besoin que d’un sous-ensemble de propriétés.

La sélection de propriétés inutiles augmente la lecture des données, le coût de sérialisation et la taille de la réponse. Lors de la modélisation de graphes, sélectionnez uniquement les colonnes sources dont vous avez besoin comme propriétés de type de nœud.

Recommandé : Projection étroite.

MATCH (p:Person)-[:workAt]->(c:Company)
RETURN p.firstName, p.lastName, c.name

Évitez de retourner des nœuds complets.

MATCH (p:Person)-[:workAt]->(c:Company)
RETURN *

Note

Ajoutez uniquement des propriétés de type de nœud lors de la modélisation de graphiques lorsqu’elles sont nécessaires pour les requêtes ou l’analyse. Moins de propriétés par nœud réduisent à la fois le stockage et la surcharge des requêtes.

Limiter la taille du jeu de résultats

Appliquez LIMIT ou d'autres conditions de limitation lors de la requête de nœuds ou de relations susceptibles d'avoir une cardinalité élevée. Les correspondances de graphiques sans limites peuvent produire des jeux de résultats très volumineux qui approchent les limites de la plateforme.

Recommandé: Résultats limités.

MATCH (p:Person)-[:knows]->(friend:Person)
RETURN p.firstName, friend.firstName
LIMIT 1000

Éviter: Correspondance haute cardinalité sans limite.

MATCH (p:Person)-[:knows]->(friend:Person)
RETURN p.firstName, friend.firstName

Important

Graph tronque les réponses aux requêtes dont la représentation binaire interne dépasse 64 Mo. Une réponse tronquée comprend un statut supplémentaire avec le code public 01000 et le GQLSTATUS canonique 01M11. Utilisez des filtres, des projections étroites, et LIMIT pour réduire la taille du résultat. Pour plus d’informations, consultez les limitations actuelles.

Conserver les traversées superficielles et ciblées

Évitez les modèles graphiques profondément imbriqués ou hautement complexes. Utilisez des traversées simples et ciblées qui répondent directement à une question spécifique. Chaque étape supplémentaire d’un modèle de longueur variable peut augmenter de façon exponentielle le nombre de chemins évalués par le moteur, en particulier dans les graphiques densément connectés.

Recommandé: Limites serrées.

-- Use the narrowest hop range that answers your question
MATCH (p:Person)-[:knows]->{1,3}(friend:Person)
RETURN p.firstName, friend.firstName
LIMIT 1000

Éviter : un périmètre de parcours étendu sans besoin clairement identifié.

-- A wider range on a dense graph is more expensive
MATCH (p:Person)-[:knows]->{1,8}(friend:Person)
RETURN *

Important

Le générateur visuel de requêtes limite les chemins de longueur variable à huit sauts, mais cette limitation de l’interface utilisateur ne s’applique pas à GQL dans l’éditeur de code. Utilisez la limite la plus serrée que votre scénario permet, car une plus grande portée peut correspondre à plus de chemins.

Utilisez TRAIL lorsque les chemins ne doivent pas répéter les arêtes

Utilisez TRAIL le mode chemin lorsqu’un chemin valide ne doit pas répéter une arête. Dans les graphes avec des cycles, cette restriction peut aussi réduire le nombre de chemins d’appariement par rapport au mode par défaut WALK .

-- TRAIL prevents revisiting the same :knows edge
MATCH TRAIL (src:Person)-[:knows]->{1,4}(dst:Person)
WHERE src.firstName = 'Alice' AND dst.firstName = 'Bob'
RETURN count(*) AS numPaths

Sans TRAIL, la même requête sur un graphe cyclique peut retourner des chemins qui répètent une arête. Utilisez le mode qui correspond à la sémantique de chemin requise plutôt que de le traiter TRAIL comme une optimisation générale des performances.

Un motif non borné ALL WALK n’est pas supporté car les cycles peuvent produire une infinité de chemins. Bien que les motifs TRAIL, SIMPLE et ACYCLIC non bornés se terminent, ils peuvent néanmoins énumérer de nombreux chemins. Utilisez une borne supérieure finie sauf si la requête nécessite une traversée non bornée.

Utiliser des variables partagées pour des jointures efficaces

Lorsqu’une requête nécessite des données provenant de plusieurs relations, utilisez une variable partagée pour joindre des modèles sur la même entité. Sans variable partagée, les modèles peuvent produire un produit cartésien , toutes les combinaisons de correspondances des deux modèles, ce qui entraîne un jeu de résultats beaucoup plus volumineux.

Recommandé: La variable p partagée joint les modèles.

-- Single shared variable ensures an efficient join
MATCH (p:Person)-[:workAt]->(c:Company),
      (p)-[:isLocatedIn]->(city:City)
RETURN p.firstName, c.name AS company, city.name AS city
LIMIT 1000

Éviter: Modèles indépendants sans variable partagée.

-- Without a shared variable, this produces a cartesian product
MATCH (p1:Person)-[:workAt]->(c:Company),
      (p2:Person)-[:isLocatedIn]->(city:City)
RETURN p1.firstName, c.name, p2.firstName, city.name

Un produit cartésien associe chaque résultat d’un modèle à chaque résultat de l’autre. Si Person-workAt->Company elle correspond à 1 000 lignes et Person-isLocatedIn->City correspond à 500 lignes, la requête retourne 1 000 × 500 = 500 000 lignes. L’ajout d’une variable partagée limite la jointure afin que seules les paires correspondantes soient retournées.

Filtrez les propriétés clés lors de l’identification des nœuds

Définir les contraintes de clé des nœuds afin d’identifier les nœuds de manière unique et d’assurer l’intégrité des données. Lorsque vous avez besoin d’un nœud spécifique, incluez sa propriété clé dans le prédicat du motif pour éviter de correspondre des nœuds non liés.

Par exemple, si votre type de graphique définit id comme clé pour Person les nœuds :

CONSTRAINT person_pk
  FOR (n:Person) REQUIRE n.id IS KEY

Ensuite, filtrez selon id le moment où vous avez besoin de cette personne :

MATCH (p:Person WHERE p.id = 12345)-[:workAt]->(c:Company)
RETURN p.firstName, c.name

Sans le filtre, la requête sélectionne chaque nœud Person avant de parcourir les arêtes workAt :

MATCH (p:Person)-[:workAt]->(c:Company)
RETURN p.firstName, c.name

Conseil / Astuce

Une contrainte clé établit l’identité et l’unicité. Cela ne garantit pas en soi un plan de recherche physique ou de requête particulier.

Choisir les types de données appropriés

Sélectionnez le type de données représentant les valeurs et les opérations prévues de chaque propriété. Par exemple, utilisez un type numérique pour les valeurs que vous calculez ou comparez numériquement au lieu de stocker des nombres formatés sous forme de chaînes.

Pour les types de données pris en charge, consultez limitations actuelles : types de données et types de propriétés pris en charge.

Si possible, récupérez les entités associées dans un seul modèle de graphe plutôt que d’émettre des requêtes distinctes qui parcourent les mêmes arêtes indépendamment. La combinaison de traversées évite la correspondance de modèles redondants et empêche le problème de requête N+1, où une requête initiale déclenche une requête distincte pour chaque ligne de résultat.

Recommandé: Modèle combiné unique.

MATCH (c:Customer)-[:purchases]->(o:`Order`)-[:`contains`]->(product:`Product`)
RETURN c.fullName, o, product.productName
LIMIT 1000

Éviter : Deux requêtes distinctes qui parcourent la même Customer → Order arête.

-- Query 1: fetch 100 orders
MATCH (c:Customer)-[:purchases]->(o:`Order`)
RETURN c.fullName, o
LIMIT 100

-- Query 2: repeat for each returned order, substituting its key value
MATCH (o:`Order` WHERE o.SalesOrderDetailID_K = 12345)-[:`contains`]->(product:`Product`)
RETURN o, product.productName

Tester des requêtes sur des volumes de données réalistes

Les requêtes qui s’exécutent correctement sur de petits ensembles de données peuvent ne pas évoluer de façon linéaire. Testez vos requêtes avec des volumes de données qui représentent votre charge de travail de production attendue.

  • Préférez les formes de requête conservatrices qui incluent des filtres et des limites.
  • Évitez les requêtes exploratoires de renvoi de tous les éléments sur des graphes volumineux.
  • Surveillez la durée des requêtes par rapport à la limite de délai d’attente de 20 minutes.

Contenu connexe

  • Last updated on