Optimera GQL-frågeprestanda för diagram i Microsoft Fabric

Den här artikeln innehåller vägledning för att skriva GQL-frågor (Graph Query Language) som presterar förutsägbart och effektivt när du arbetar med diagram i Microsoft Fabric. Rekommendationerna baseras på aktuellt plattformsbeteende och dokumenterade begränsningar.

Hårda gränser för grafstorlek, resultatstorlek och tidsgräns för frågor finns i Aktuella begränsningar. Flera rekommendationer i den här artikeln gäller också hur du utformar grafschemat. Mer information finns i Designa ett diagramschema.

Placera filter enligt deras semantik

Placera ett predikat i ett grafmönster när det definierar vilken nod eller kant som kan delta i matchningen. Använd ett satsnivåvillkor MATCH ... WHERE för att efterfiltrera den avslutade matchningen, eller ett separat FILTER uttalande när predikatet gäller för raden som produceras av ett tidigare påstående.

Använd till exempel mönsternivåklausuler WHERE för villkor på de matchade noderna:

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 uttrycka samma villkor efter en vanlig obligatorisk matchning som använder standardsökningen ALL för sökväg:

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

Frågeoptimeraren kan tillämpa motsvarande predikat under skanning när det bevarar frågesemantiken, så inline-syntaxen är inte automatiskt snabbare. Välj det formulär som uttrycker när villkoret gäller.

Predikatplacering kan ändra resultat med ANY SHORTEST. Inline-predikat begränsar de sökvägar som kan väljas vid beräkning av kortaste väg. En satsnivå WHERE eller efterföljande FILTER gäller efter val av väg, så den kan ta bort en vald kortaste väg utan att välja en längre väg istället. För den aktuella MATCH ... WHERE begränsningen och ett tillförlitligt placeringsmönster, se Place-predikater före eller efter val av väg.

Placering spelar också roll med OPTIONAL MATCH, där en inline WHERE begränsar den valfria matchningen men en efterföljande FILTER kan ta bort den null-utökade raden.

Tips/Råd

Tänk på mönsternivå WHERE som analogt med ett SQL-villkor JOIN ... ON . Den beskriver vilka matchningar som kvalificerar sig istället för att filtrera den resulterande raden efteråt.

Returnera endast de egenskaper som du behöver

Returnera endast de nod- och gränsegenskaper som ditt scenario kräver. Undvik att returnera fullständiga noder eller använda RETURN * när du bara behöver en delmängd av egenskaperna.

Om du väljer onödiga egenskaper ökar dataläsningen, serialiseringskostnaden och svarsstorleken. Under grafmodellering, välj endast de källkolumner du behöver som nodtypegenskaper.

Rekommenderas: Smal projektion.

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

Undvik: Att returnera fullständiga noder.

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

Anmärkning

Lägg bara till egenskaper för nodtyp under grafmodellering när de behövs för frågor eller analys. Färre egenskaper per nod minskar både storage och frågeomkostnader.

Begränsa resultatuppsättningens storlek

Tillämpa LIMIT eller andra avgränsningsvillkor när du frågar efter noder eller relationer som kan ha hög kardinalitet. Obundna grafmatchningar kan ge mycket stora resultatuppsättningar som närmar sig plattformsgränser.

Rekommenderas: Begränsade resultat.

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

Undvik: Obegränsad matchning med hög kardinalitet.

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

Viktigt!

Grafen förkortar frågesvar vars interna binära representation överstiger 64 MB. Ett förkortat svar inkluderar en ytterligare status med offentlig kod 01000 och kanonisk GQLSTATUS 01M11. Använd filter, smala projektioner och LIMIT för att minska resultatstorleken. Mer information finns i Aktuella begränsningar.

Håll genomgångar ytliga och målinriktade

Undvik djupt kapslade eller mycket komplexa grafmönster. Använd enkla, riktade blädderingar som svarar direkt på en specifik fråga. Varje extra hopp i ett mönster med variabel längd kan exponentiellt öka antalet sökvägar som motorn utvärderar, särskilt i tätt anslutna grafer.

Rekommenderas: Snäva 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

Undvik: Ett stort förflyttningsområde utan tydligt behov.

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

Viktigt!

Den visuella frågebyggaren begränsar varierande längder till åtta hopp, men denna användargränssnittsbegränsning gäller inte för GQL i kodredigeraren. Använd den snävaste gränsen som ditt scenario tillåter eftersom ett bredare omfång kan matcha fler vägar.

Använd TRAIL när stigarna inte får upprepa kanter

Använd TRAIL vägläge när en giltig väg inte får upprepa en kant. I grafer med cykler kan denna begränsning också minska antalet matchande vägar jämfört med standardläget 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

Utan TRAIL, kan samma fråga på en cyklisk graf returnera vägar som upprepar en kant. Använd det läge som motsvarar den vägsemantik som krävs i stället för att behandla TRAIL som en allmän prestandaoptimering.

Ett obegränsat ALL WALK mönster stöds inte eftersom cykler kan producera oändligt många vägar. Även om obegränsade TRAIL, SIMPLE och ACYCLIC-mönster terminerar kan de ändå enumerera många vägar. Använd en ändlig övre gräns om inte frågan kräver obegränsad traversering.

Använda delade variabler för effektiva kopplingar

När en fråga kräver data från flera relationer använder du en delad variabel för att koppla mönster på samma entitet. Utan en delad variabel kan mönster producera en kartesisk produkt – varje kombination av matchningar från båda mönstren – vilket leder till en mycket större resultatuppsättning.

Rekommenderas: Delad variabel p kopplar ihop mönstren.

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

Undvik: Skilda mönster utan gemensam 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

En kartesisk produkt parar varje resultat från ett mönster med varje resultat från det andra. Om Person-workAt->Company matchar 1 000 rader och Person-isLocatedIn->City matchar 500 rader returnerar frågan 1 000 × 500 = 500 000 rader. Om du lägger till en delad variabel begränsas kopplingen så att endast matchande par returneras.

Filtrera på nyckelegenskaper vid identifiering av noder

Definiera nodnyckelbegränsningar för att unikt identifiera noder och upprätthålla dataintegritet. När du behöver en specifik nod, inkludera dess nyckelegenskap i mönsterpredikatet för att undvika att matcha orelaterade noder.

Om graftypen till exempel definierar id som nyckel för Person noder:

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

Filtrera sedan efter id när du behöver den personen:

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

Utan filtret matchar frågan varje Person nod innan den passerar workAt kanterna:

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

Tips/Råd

En nyckelbegränsning fastställer identitet och unikhet. Det garanterar inte enbart en specifik fysisk sökning eller sökplan.

Välj lämpliga datatyper

Välj den datatyp som representerar varje egenskaps värden och avsedda operationer. Till exempel, använd en numerisk typ för värden som du beräknar eller jämför numeriskt istället för att lagra formaterade siffror som strängar.

Information om datatyper som stöds finns i Aktuella begränsningar – Datatyper och egenskapstypersom stöds.

Om möjligt hämtar du relaterade entiteter i ett enda diagrammönster i stället för att utfärda separata frågor som passerar samma kanter oberoende av varandra. Genom att kombinera blädderingar undviker du redundant mönstermatchning och förhindrar N+1-frågeproblemet, där en inledande fråga utlöser en separat fråga för varje resultatrad.

Rekommenderas: Enkelt kombinerat mönster.

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

Undvika: Två separata frågor som passerar samma 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

Testa frågor mot realistiska datavolymer

Frågor som fungerar bra på små datauppsättningar kanske inte skalas linjärt. Testa dina frågor med datavolymer som representerar din förväntade produktionsarbetsbelastning.

  • Föredrar konservativa frågeformer som innehåller filter och gränser.
  • Undvik undersökande "returnera allt"-frågor mot stora grafer.
  • Övervaka frågevaraktighet i förhållande till tidsgränsen på 20 minuter.

Relaterat innehåll

  • Last updated on