Prestaties van GQL-query's optimaliseren voor grafiek in Microsoft Fabric

Dit artikel bevat richtlijnen voor het schrijven van GQL-query's (Graph Query Language) die voorspelbaar en efficiënt werken met grafieken in Microsoft Fabric. De aanbevelingen zijn gebaseerd op het huidige platformgedrag en gedocumenteerde beperkingen.

Zie Huidige beperkingen voor de huidige beperkingen voor de grafiekgrootte, de resultaatgrootte en de time-out van query's. Verschillende aanbevelingen in dit artikel hebben ook betrekking op hoe u uw grafiekschema ontwerpt. Zie Een grafiekschema ontwerpen voor meer informatie.

Plaats filters volgens hun semantiek

Plaats een predicaat binnen een graafpatroon wanneer het definieert welke knoop of rand aan de match kan deelnemen. Gebruik een statement-level MATCH ... WHERE voorwaarde om de voltooide match na te filteren, of een aparte FILTER statement wanneer het predicaat van toepassing is op de rij die door een eerdere statement wordt geproduceerd.

Gebruik bijvoorbeeld patroonniveauclausules WHERE voor voorwaarden op de bijbehorende knooppunten:

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

Een aparte FILTER kan dezelfde voorwaarde uitdrukken na een gewone verplichte match die de standaard ALL padzoekopdracht gebruikt:

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

De query-optimizer kan equivalente predicaten toepassen tijdens het scannen, terwijl dit de query-semantiek behoudt, waardoor de inline-syntaxis niet per se sneller is. Kies de vorm die aangeeft wanneer de voorwaarde van toepassing is.

Predicaatplaatsing kan de resultaten met ANY SHORTESTveranderen. Inline predikaten beperken de paden die in aanmerking komen voor de selectie van het kortste pad. Een WHERE of daaropvolgende FILTER op statementniveau wordt toegepast na padselectie, waardoor het een geselecteerd kortste pad kan verwijderen zonder in plaats daarvan een langer pad te kiezen. Zie Plaats predicaten vóór of na de padselectie voor de huidige beperking van MATCH ... WHERE en een betrouwbaar patroon voor plaatsing.

Plaatsing is ook belangrijk met OPTIONAL MATCH, waarbij een inline WHERE de optionele match beperkt, maar een volgende FILTER de null-uitgebreide rij kan verwijderen.

Aanbeveling

U kunt een patroonniveau WHERE beschouwen als vergelijkbaar met een SQL-voorwaarde JOIN ... ON . Het beschrijft welke matches in aanmerking komen, in plaats van de resulterende reeks daarna te filteren.

Alleen de eigenschappen retourneren die u nodig hebt

Retourneer alleen de knooppunt- en edge-eigenschappen die uw scenario nodig heeft. Vermijd het retourneren van volledige knooppunten of het gebruik ervan RETURN * wanneer u slechts een subset met eigenschappen nodig hebt.

Als u onnodige eigenschappen selecteert, worden de lees- en serialisatiekosten en de reactiegrootte verhoogd. Selecteer tijdens het grafmodelleren alleen de bronkolommen die je nodig hebt als nodetype-eigenschappen.

Aanbevolen: Smalle projectie.

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

Vermijden: Het retourneren van volledige knooppunten.

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

Opmerking

Voeg alleen eigenschappen van het knooppunttype toe tijdens grafiekmodellering wanneer ze nodig zijn voor query's of analyse. Minder eigenschappen per knooppunt verminderen zowel storage als queryoverhead.

Grootte van resultatenset beperken

Pas LIMIT of andere begrenzingsvoorwaarden toe bij het uitvoeren van query's op knooppunten of relaties die een hoge kardinaliteit kunnen hebben. Onbegrensde grafiekovereenkomsten kunnen zeer grote resultatensets produceren die platformlimieten benaderen.

Aanbevolen: Gebonden resultaten.

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

Vermijden: Onbegrensde overeenkomst met hoge cardinaliteit.

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

Belangrijk

Graaf kortst query-antwoorden af waarvan de interne binaire representatie groter is dan 64 MB. Een afgekorte reactie bevat een extra status met publieke code 01000 en canonieke GQLSTATUS 01M11. Gebruik filters, smalle projecties en LIMIT om de resultaatgrootte te verkleinen. Zie Huidige beperkingen voor meer informatie.

Houd traversals oppervlakkig en doelgericht.

Vermijd diep geneste of zeer complexe grafiekpatronen. Gebruik eenvoudige, gerichte traversals die rechtstreeks een specifieke vraag beantwoorden. Elke extra hop in een patroon met variabele lengte kan het aantal paden dat de engine evalueert exponentieel verhogen, met name in dicht verbonden grafieken.

Aanbevolen: Strakke grenzen.

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

Vermijd: Een breed traverseringsbereik zonder duidelijke noodzaak.

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

Belangrijk

De visuele querybuilder beperkt paden met variabele lengte tot acht hops, maar deze gebruikersinterface-limiet geldt niet voor GQL in de code-editor. Gebruik het kleinst mogelijke bereik dat uw scenario toestaat, omdat een breder bereik met meer paden kan overeenkomen.

Gebruik TRAIL wanneer paden geen herhalingsranden mogen hebben

Gebruik TRAIL padmodus wanneer een geldig pad een rand niet mag herhalen. In grafen met cycli kan deze beperking ook het aantal overeenkomende paden verminderen ten opzichte van de standaardmodus 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

Zonder TRAIL kan dezelfde query op een cyclische graaf paden teruggeven die een kant herhalen. Gebruik de modus die past bij de vereiste padsemantiek in plaats van het als een algemene prestatieoptimalisatie te behandelen TRAIL .

Een onbegrensd ALL WALK patroon wordt niet ondersteund omdat cycli oneindig veel paden kunnen opleveren. Hoewel onbegrensde TRAIL, SIMPLE, en patronen ACYCLIC eindigen, kunnen ze nog steeds vele paden opsommen. Gebruik een eindige bovengrens, tenzij de query onbegrensde doorloop vereist.

Gedeelde variabelen gebruiken voor efficiënte joins

Wanneer voor een query gegevens uit meerdere relaties zijn vereist, gebruikt u een gedeelde variabele om patronen op dezelfde entiteit samen te voegen. Zonder een gedeelde variabele kunnen patronen een cartesisch product produceren - elke combinatie van overeenkomsten van beide patronen - wat leidt tot een veel grotere resultatenset.

Aanbevolen: Met gedeelde variabelen p worden de patronen samengevoegd.

-- 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

Vermijden: Onafhankelijke patronen zonder gedeelde variabele.

-- 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

Een cartesisch product paart elk resultaat van één patroon met elk resultaat van het andere. Als Person-workAt->Company deze overeenkomt met 1000 rijen en Person-isLocatedIn->City overeenkomt met 500 rijen, retourneert de query 1000 × 500 = 500.000 rijen. Als u een gedeelde variabele toevoegt, wordt de join beperkt, zodat alleen overeenkomende paren worden geretourneerd.

Filter op sleuteleigenschappen bij het identificeren van knooppunten

Definieer knooppuntsleutelbeperkingen om knooppunten uniek te identificeren en gegevensintegriteit af te dwingen. Wanneer je één specifieke knoop nodig hebt, neem dan de sleuteleigenschap ervan op in het patroonpredicaat om te voorkomen dat niet-gerelateerde knooppunten worden overeengekomen.

Als uw grafiektype bijvoorbeeld definieert id als de sleutel voor Person knooppunten:

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

Filter dan op id wanneer je die persoon nodig hebt:

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

Zonder filter komt de query overeen met elke Person-knoop voordat workAt-randen worden doorlopen:

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

Aanbeveling

Een belangrijke beperking stelt identiteit en uniciteit vast. Het garandeert op zichzelf geen specifieke fysieke zoekopdracht of queryplan.

De juiste gegevenstypen kiezen

Selecteer het datatype dat de waarden en beoogde bewerkingen van elke eigenschap weergeeft. Gebruik bijvoorbeeld een numeriek type voor waarden die je numeriek berekent of vergelijkt, in plaats van geformatteerde getallen als strings op te slaan.

Zie Huidige beperkingen voor ondersteunde gegevenstypen: gegevenstypen en ondersteunde eigenschapstypen.

Haal, waar mogelijk, gerelateerde entiteiten op in één grafiekpatroon in plaats van afzonderlijke query's uit te geven die dezelfde randen onafhankelijk doorlopen. Het samenvoegen van doorkruisingen vermijdt redundante patroonherkenning en voorkomt het N+1-queryprobleem, waarbij een enkele initiële query een aparte query triggert voor elke resultaatrij.

Aanbevolen: Eén gecombineerd patroon.

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

Vermijden: Twee afzonderlijke query's die dezelfde Customer → Order rand doorlopen.

-- 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

Queries testen met realistische gegevensvolumes

Query's die goed presteren op kleine gegevenssets, worden mogelijk niet lineair geschaald. Test uw query's met gegevensvolumes die uw verwachte productieworkload vertegenwoordigen.

  • Geef de voorkeur aan conservatieve queryshapes die filters en limieten bevatten.
  • Vermijd verkennende query's 'alles retourneren' voor grote grafieken.
  • Bewaak de queryduur ten opzichte van de time-outlimiet van 20 minuten.