Optimer GQL-forespørgselsydelse for graf i Microsoft Fabric

Denne artikel giver vejledning til at skrive GQL (Graph Query Language) forespørgsler, der fungerer forudsigeligt og effektivt, når man arbejder med graf i Microsoft Fabric. Anbefalingerne er baseret på den aktuelle platformadfærd og dokumenterede begrænsninger.

For hårde grænser for grafstørrelse, resultatstørrelse og forespørgselstimeout, se Nuværende begrænsninger.

Filtrer tidligt i mønstre

Placer filtre i grafmønstre i stedet for i senere udsagn. Pattern-level WHERE clauses reducerer antallet af mellemliggende resultater før joins og efterfølgende statements kører, hvilket sænker den samlede eksekveringsomkostning.

Anbefalet: Filtrer under mønstermatchning.

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

Undgå: Filtrering sent med en separat FILTER-sætning.

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

Begge forespørgsler returnerer de samme resultater, men den første version lader forespørgselsmotoren beskære rækker tidligere i evalueringsprocessen.

Returner kun de ejendomme, du har brug for

Returner kun de node- og kantegenskaber, som dit scenarie kræver. Undgå at returnere fulde noder eller bruge RETURN * dem, når du kun har brug for et delmængde af egenskaber.

I grafen tabellerer OneLake nodeegenskaberne. Valg af unødvendige egenskaber øger datalæsning, serialiseringsomkostninger og svarstørrelse. Under grafmodellering tilføjes alle kolonner fra kildetabellen som egenskaber som standard, medmindre du fjerner dem.

Anbefalet: Smal projektion.

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

Undgå: Returnerer fulde noder.

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

Grænsemængde resultatmængde

Anvend LIMIT eller andre afgrænsningsbetingelser, når du forespørger noder eller relationer, der kan have høj kardinalitet. Ubegrænsede grafmatches kan producere meget store resultatsæt, der nærmer sig platformgrænser.

Anbefalet: Begrænsede resultater.

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

Undgå: Ubegrænset højkardinalitet-match.

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

Hold krydsninger lave og målrettede

Undgå dybt indlejrede eller meget komplekse grafmønstre. Foretræk simple, målrettede traversaler, der direkte besvarer et specifikt spørgsmål. Hvert ekstra hop i et variabelt længdemønster kan eksponentielt øge antallet af stier, motoren evaluerer, især i tæt forbundne grafer.

Anbefalet: Snævre grænser.

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

Undgå: Maksimal dybde uden klar nødvendighed.

-- Exploring the full 8-hop limit on a dense graph is expensive
MATCH (p:Person)-[:knows]->{1,8}(friend:Person)
RETURN *

Brug TRAIL for at forhindre gentagne gennemløb

Brug TRAIL sti-tilstand for at forhindre, at forespørgselsmotoren vender tilbage til den samme kant. I tætte grafer kan cyklusser forårsage eksponentiel stieksplosion. TRAIL sikrer, at hver kant besøges højst én gang pr. sti, hvilket forbedrer både korrekthed og ydeevne.

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

Uden TRAILkan den samme forespørgsel på en cyklisk graf producere et meget større (og ofte overflødigt) resultatsæt.

Brug delte variable til effektive joins

Når en forespørgsel kræver data fra flere relationer, brug en delt variabel til at joine mønstre på den samme enhed. Uden en delt variabel kan mønstre producere et kartesisk produkt – hver kombination af matches fra begge mønstre – hvilket fører til et meget større resultatsæt.

Anbefalet: Den delte variabel p tilslutter mønstrene.

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

Undgå: Uafhængige mønstre uden fælles variabel.

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

Et kartesisk produkt parrer hvert resultat fra det ene mønster med hvert resultat fra det andet. Hvis Person-workAt->Company matcher 1.000 rækker og Person-isLocatedIn->City matcher 500 rækker, returnerer forespørgslen 1.000 × 500 = 500.000 rækker. Tilføjelse af en delt variabel begrænser joinet, så kun matchende par returneres.

Definér nøglebegrænsninger på noder

Definér node-nøglebegrænsninger i din graftype. Nøglebegrænsninger gør det muligt for systemet at optimere forespørgsler, der slår specifikke noder op efter deres nøgleegenskaber, ligesom primære nøgleindekser i relationelle databaser.

For eksempel, hvis din graftype definerer id som nøglen for Person noder:

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

Så kan forespørgsler, der filtreres på id , bruge den nøgle til et direkte opslag:

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

Uden filteret på nøgleegenskaben skal motoren scanne hver Person node:

-- Slower: scans all Person nodes before traversing
MATCH (p:Person)-[:workAt]->(c:Company)
RETURN p.firstName, c.name

Vælg relevante datatyper

Vælg den mest specifikke datatype for hver egenskab under grafmodelleringen. At vælge de rigtige typer er vigtigt både for storage-effektivitet og forespørgselsydelse. For eksempel er numeriske sammenligninger på INT egenskaber hurtigere end strengsammenligninger på ækvivalente STRING værdier.

For understøttede datatyper, se Nuværende begrænsninger — Datatyper og Understøttede egenskabstyper.

Kombiner relaterede traversaler i en enkelt forespørgsel

Hvor det er muligt, hent relaterede enheder i et enkelt grafmønster i stedet for at udsende separate forespørgsler, der uafhængigt bevæger sig gennem de samme kanter. Kombinationen af gennemgange undgår overflødig mønstergenkendelse og forhindrer N+1-forespørgselsproblemet, hvor én indledende forespørgsel udløser en separat forespørgsel for hver resultatrække.

Anbefalet: Enkelt kombineret mønster.

MATCH (c:Customer)-[:purchased]->(o:Order)-[:contains]->(product:Product)
RETURN c.id, o.id, product.name
LIMIT 1000

Undgå: To separate forespørgsler, der går langs samme Customer → Order kant.

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

Testforespørgsler mod realistiske datavolumener

Forespørgsler, der klarer sig godt på små datasæt, skalerer måske ikke lineært. Test dine forespørgsler med datavolumener, der repræsenterer din forventede produktionsarbejdsbyrde.

• Foretræk konservative forespørgselsformer, der inkluderer filtre og grænser.
• Undgå udforskende "returner alt"-forespørgsler mod store grafer.
• Overvåg forespørgselsvarigheden i forhold til 20-minutters timeout-grænsen.

Relateret indhold

• GQL-sprogvejledning
• GQL-graftyper
• GQL-grafmønstre
• Nuværende begrænsninger
• Fejlfinding og FAQ