Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
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.
Cet article fournit des conseils sur l’écriture de requêtes GQL (Graph Query Language) qui s’exécutent de manière prévisible et efficace lors de l’utilisation de graphe 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.
Filtrer tôt dans les modèles
Placez des filtres à l’intérieur des modèles de graphique plutôt que dans les instructions ultérieures. Les clauses de niveau WHERE modèle réduisent le nombre de résultats intermédiaires avant l’exécution des jointures et des instructions suivantes, ce qui réduit le coût d’exécution global.
Recommandé: Filtrez pendant l'analyse de motifs.
-- Pattern-level WHERE reduces intermediate results
MATCH (p:Person WHERE p.birthday < 19940101)-[:workAt]->(c:Company WHERE c.id > 1000)
RETURN p.firstName, p.lastName, c.name
Éviter: Filtrer tardivement avec une instruction FILTER distincte.
-- Statement-level filter runs after all pattern matches are produced
MATCH (p:Person)-[:workAt]->(c:Company)
FILTER p.birthday < 19940101 AND c.id > 1000
RETURN p.firstName, p.lastName, c.name
Les deux requêtes retournent les mêmes résultats, mais la première version permet au moteur de requête de découper les lignes plus tôt dans le processus d’évaluation.
Conseil / Astuce
Considérez le niveau WHERE du modèle comme analogue à une condition SQL JOIN ... ON . Elle limite les correspondances au point d'évaluation au lieu de filtrer ensuite l'ensemble complet des résultats.
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.
Dans le graphique, les tables OneLake prennent en charge les propriétés des nœuds. 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. Pendant la modélisation des graphiques, toutes les colonnes de la table source sont ajoutées en tant que propriétés par défaut, sauf si vous les supprimez.
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
Supprimez les propriétés inutilisées pendant la modélisation de graphiques en sélectionnant l’icône corbeille en regard de chaque propriété. 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
Le graphique tronque les réponses supérieures à 64 Mo et les performances d'agrégation peuvent être instables lorsque les résultats dépassent 128 Mo. Utilisez FILTER, LIMITet GROUP BY pour conserver les résultats dans ces limites. 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. Préférez les 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
Évitez : Exploration en profondeur maximale sans nécessité évidente.
-- Exploring the full 8-hop limit on a dense graph is expensive
MATCH (p:Person)-[:knows]->{1,8}(friend:Person)
RETURN *
Important
le graphe prend en charge jusqu’à huit sauts pour des schémas de longueur variable. Même si, utilisez les limites les plus étroites que votre scénario autorise. Dans l’exemple, le {1,3} modèle est beaucoup moins cher que {1,8} sur le même graphique.
Utiliser TRAIL pour empêcher les traversées redondantes
Utilisez le mode chemin TRAIL pour empêcher le moteur de requête de revisiter la même arête. Dans les graphiques denses, les cycles peuvent entraîner une explosion exponentielle du chemin.
TRAIL garantit que chaque arête est visitée au plus une fois par chemin, ce qui améliore à la fois la justesse et les performances.
-- 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 graphique cyclique peut produire un jeu de résultats beaucoup plus volumineux (et souvent redondant).
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.
Définir des contraintes clés sur les nœuds
Définissez des contraintes de clé de nœud dans votre type de graphique. Les contraintes de clé permettent au système d’optimiser les requêtes qui recherchent des nœuds spécifiques par leurs propriétés de clé, similaires aux index de clé primaire dans les bases de données relationnelles.
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, les requêtes qui filtrent sur id peuvent utiliser cette clé pour une consultation directe :
-- Fast: the engine can look up person 12345 directly using the key
MATCH (p:Person WHERE p.id = 12345)-[:workAt]->(c:Company)
RETURN p.firstName, c.name
Sans le filtre sur la propriété de clé, le moteur doit analyser chaque Person nœud :
-- Slower: scans all Person nodes before traversing
MATCH (p:Person)-[:workAt]->(c:Company)
RETURN p.firstName, c.name
Conseil / Astuce
Lorsque vous avez besoin d’un nœud spécifique, filtrez sur sa propriété de clé dans le MATCH modèle pour tirer parti de la contrainte que vous avez définie.
Choisir les types de données appropriés
Sélectionnez le type de données le plus spécifique pour chaque propriété pendant la modélisation de graphe. Le choix des types appropriés est important pour l’efficacité du stockage et les performances des requêtes. Par exemple, effectuer des comparaisons numériques sur les propriétés INT est plus rapide que d'effectuer des comparaisons de chaînes sur les valeurs équivalentes STRING.
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.
Combiner des traversées associées dans une seule requête
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)-[:purchased]->(o:Order)-[:contains]->(product:Product)
RETURN c.id, o.id, product.name
LIMIT 1000
Éviter : Deux requêtes distinctes qui parcourent la même Customer → Order arête.
-- Query 1: fetch 100 orders
MATCH (c:Customer)-[:purchased]->(o:Order)
RETURN c.id, o.id
-- Query 2: run once per order to get products (N+1 problem)
MATCH (o:Order)-[:contains]->(product:Product)
RETURN o.id, product.name
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.