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. Flere anbefalinger i denne artikel vedrører også, hvordan du designer dit grafskema. For mere information, se Design et grafskema.

Placer filtre efter deres semantik

Placer et prædikat i et grafmønster, når det definerer, hvilken node eller kant der kan deltage i matchet. Brug en sætningsniveau-betingelse MATCH ... WHERE til at postfiltrere det færdige match, eller en separat FILTER sætning, når prædikatet gælder for rækken, der er produceret af en tidligere sætning.

For eksempel brug mønsterniveau-klausuler WHERE for betingelser på de matchede noder:

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

En separat FILTER kan udtrykke den samme betingelse efter et almindeligt obligatorisk match, der bruger standardsti-søgningen ALL :

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

Forespørgselsoptimeringen kan anvende ækvivalente prædikater under scanning, når det bevarer forespørgselssemantikken, så inline-syntaksen er ikke automatisk hurtigere. Vælg den formular, der angiver, hvornår betingelsen gælder.

Prædikatplacering kan ændre resultater med ANY SHORTEST. Inline-prædikater begrænser de stier, der er berettigede til valg af korteste sti. Et sætningsniveau WHERE eller efterfølgende FILTER gælder efter stivalg, så det kan fjerne en valgt korteste sti uden at vælge en længere sti i stedet. For den nuværende MATCH ... WHERE begrænsning og et pålideligt placeringsmønster, se Place-prædikater før eller efter stivalg.

Placering betyder også noget med OPTIONAL MATCH, hvor en inline WHERE begrænser det valgfrie match, men en efterfølgende FILTER kan fjerne den null-udvidede række.

Tips

Tænk på mønsterniveau WHERE som analogt med en SQL-betingelse JOIN ... ON . Den beskriver, hvilke matches der kvalificerer sig, i stedet for at filtrere den resulterende række bagefter.

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.

Valg af unødvendige egenskaber øger datalæsning, serialiseringsomkostninger og svarstørrelse. Under grafmodellering skal du kun vælge de kildekolonner, du har brug for som nodetypeegenskaber.

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 *

Bemærkning

Tilføj kun nodetype-egenskaber under grafmodellering, når de er nødvendige til forespørgsler eller analyse. Færre egenskaber pr. node reducerer både storage- og forespørgselsoverhead.

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

Vigtigt!

Grafen afkorter forespørgselssvar, hvis interne binære repræsentation overstiger 64 MB. Et afkortet svar inkluderer en ekstra status med offentlig kode 01000 og kanonisk GQL-status 01M11. Brug filtre, smalle projektioner og LIMIT for at reducere resultatstørrelsen. For mere information, se Nuværende begrænsninger.

Hold krydsninger lave og målrettede

Undgå dybt indlejrede eller meget komplekse grafmønstre. Brug simple, målrettede traverser, 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å: Et bredt bevægelsesområde uden klar nødvendighed.

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

Vigtigt!

Den visuelle forespørgselsbygger begrænser variable længdestier til otte hop, men denne brugergrænsefladebegrænsning gælder ikke for GQL i kodeeditoren. Brug den snævreste grænse, dit scenarie tillader, fordi et bredere område kan matche flere stier.

Brug TRAIL, når stier ikke må gentage kanter

Brug TRAIL sti-tilstand, når en gyldig sti ikke må gentage en kant. I grafer med cyklusser kan denne begrænsning også reducere antallet af matchende stier sammenlignet med standardtilstanden 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

Uden , kan den samme forespørgsel på en cyklisk graf returnere stier, der gentager TRAILen kant. Brug den tilstand, der matcher den krævede sti-semantik, i stedet for at behandle TRAIL det som en generel ydelsesoptimering.

Et ubegrænset ALL WALK mønster understøttes ikke, fordi cyklusser kan producere uendeligt mange stier. Selvom ubegrænsede TRAIL, SIMPLE, og ACYCLIC mønstre afsluttes, kan de stadig opregne mange stier. Brug en endelig øvre grænse, medmindre forespørgslen kræver ubegrænset gennemgang.

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.

Filtrer på nøgleegenskaber ved identifikation af noder

Definer nodenøglebegrænsninger for entydigt at identificere noder og håndhæve dataintegritet. Når du har brug for en specifik node, inkluder dens nøgleegenskab i mønsterprædikatet for at undgå at matche ikke-relaterede noder.

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

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

Filtrer derefter på id , når du har brug for den person:

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

Uden filteret matcher forespørgslen hver Person node, før den passerer workAt kanterne:

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

Tips

En nøglebegrænsning fastslår identitet og unikhed. Det garanterer ikke i sig selv en bestemt fysisk søgning eller forespørgselsplan.

Vælg relevante datatyper

Vælg datatypen, der repræsenterer hver ejendoms værdier og tilsigtede operationer. For eksempel kan du bruge en numerisk type til værdier, som du beregner eller sammenligner numerisk, i stedet for at gemme formaterede tal som strenge.

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

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)-[:purchases]->(o:`Order`)-[:`contains`]->(product:`Product`)
RETURN c.fullName, o, product.productName
LIMIT 1000

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

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

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

  • Sidst opdateret den