Optimalizace výkonu dotazů GQL pro graf v Microsoft Fabric

Tento článek obsahuje pokyny pro psaní dotazů GQL (Graph Query Language), které provádějí předvídatelně a efektivně při práci s grafem v Microsoft Fabric. Doporučení vycházejí z aktuálního chování platformy a zdokumentovaných omezení.

Pevné limity velikosti grafu, velikosti výsledku a časového limitu dotazu najdete v tématu Aktuální omezení. Několik doporučení v tomto článku se týká také návrhu schématu grafu. Další informace najdete v tématu Návrh schématu grafu.

Filtrujte v rané fázi vzorů

Umístěte filtry do vzorů grafu místo v pozdějších příkazech. Klauzule na úrovni WHERE vzoru snižují počet průběžných výsledků před spojením a následným spuštěním příkazů, což snižuje celkové náklady na spuštění.

Doporučené: Filtrování během porovnávání vzorů

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

Vyhněte se: Pozdnímu filtrování pomocí samostatného příkazu FILTER.

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

Oba dotazy vrátí stejné výsledky, ale první verze umožňuje dotazovacímu stroji vyřadit řádky dříve v procesu vyhodnocení.

Návod

Představte si vzorovou úroveň WHERE jako analogii s podmínkou SQL JOIN ... ON . Omezuje porovnání při vyhodnocování místo následného filtrování sady výsledků.

Vrátí jenom vlastnosti, které potřebujete.

Vrátí jenom vlastnosti uzlu a hrany, které váš scénář vyžaduje. Vyhněte se vrácení celých uzlů nebo použití RETURN * , pokud potřebujete jenom podmnožinu vlastností.

V grafu tabulky OneLake vrátí vlastnosti uzlu. Výběr nepotřebných vlastností zvyšuje náklady na čtení dat, náklady na serializaci a velikost odpovědi. Během modelování grafu ručně vyberte sloupce ze zdrojové tabulky, které chcete přidat jako vlastnosti typu uzlu.

Doporučené: Úzká projekce.

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

Zabránit: Vrácení celých uzlů.

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

Poznámka:

Vlastnosti typu uzlu můžete přidat pouze při modelování grafů, pokud jsou potřeba pro dotazy nebo analýzu. Méně vlastností na uzel snižuje režijní náklady na storage i dotazy.

Omezení velikosti sady výsledků

Při dotazování uzlů nebo relací, které můžou mít vysokou kardinalitu, použijte LIMIT nebo jiné ohraničující podmínky. Neomezené shody grafů mohou vytvářet velmi velké sady výsledků, které dosahují limitů platformy.

Doporučené: Vázané výsledky.

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

Vyhněte se: Nevázané shodě s vysokou kardinalitou

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

Důležité

Graf zkracuje odpovědi větší než 64 MB a výkon agregace může být nestabilní, pokud výsledky překročí 128 MB. Pomocí funkce FILTER, LIMITa GROUP BY zachovat výsledky v těchto mezích. Další informace najdete v tématu Aktuální omezení.

Udržujte procházení mělké a cílené

Vyhněte se hluboko vnořeným nebo vysoce složitým vzorům grafů. Používejte jednoduché cílené procházení, které přímo odpovídají na konkrétní otázku. Každý další skok ve vzoru s proměnlivou délkou může exponenciálně zvýšit počet cest, které stroj vyhodnotí, zejména v hustě propojených grafech.

Doporučené: Pevné hranice.

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

Vyhněte se: Maximálnímu hloubkovému procházení bez jasné potřeby.

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

Důležité

Graph podporuje až osm skoků ve vzorech s proměnlivou délkou. I tak použijte ty nejtěsnější hranice, které váš scénář umožňuje. V tomto příkladu je vzor {1,3} výrazně levnější než {1,8} na téže grafu.

Použijte TRAIL, aby se zabránilo redundantnímu procházení

Pomocí TRAIL režimu cesty zabráníte dotazovacímu stroji revidovat stejnou hranu. V hustých grafech mohou cykly způsobit exponenciální explosi cest. TRAIL zajišťuje, že každá hrana je projita nejvýše jednou na jednu cestu, což zvyšuje přesnost a výkonnost.

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

Bez TRAIL, stejný dotaz na cyklický graf může vytvořit mnohem větší (a často redundantní) sadu výsledků.

Použití sdílených proměnných pro efektivní spojení

Pokud dotaz vyžaduje data z více relací, použijte sdílenou proměnnou ke spojení vzorů ve stejné entitě. Bez sdílené proměnné můžou vzory vytvořit kartézský součin – každou kombinaci shod z obou vzorů – což vede k mnohem větší sadě výsledků.

Doporučené: Sdílená proměnná p spojuje vzory.

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

Vyhnout se: Nezávislým vzorům bez sdílené proměnné

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

Kartézský produkt spáruje každý výsledek z jednoho vzoru s každým výsledkem z druhého. Pokud Person-workAt->Company odpovídá 1 000 řádkům a Person-isLocatedIn->City odpovídá 500 řádkům, vrátí dotaz 1 000 × 500 = 500 000 řádků. Přidání sdílené proměnné omezuje spojení tak, aby se vrátily pouze odpovídající páry.

Definování klíčových omezení na uzlech

Definujte klíčová omezení uzlu ve vašem typu grafu. Klíčová omezení umožňují systému optimalizovat dotazy, které vyhledávají konkrétní uzly podle jejich klíčových vlastností, podobně jako indexy primárních klíčů v relačních databázích.

Pokud například váš typ grafu definuje id jako klíč pro Person uzly:

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

Dotazy, které filtrují id , pak můžou tento klíč použít pro přímé vyhledávání:

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

Bez filtru na klíčovou vlastnost musí stroj prohledávat každý Person uzel.

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

Návod

Pokud potřebujete konkrétní uzel, vyfiltrujte jeho klíčovou vlastnost ve vzoru MATCH, abyste využili definovaného omezení.

Výběr vhodných datových typů

Při modelování grafu vyberte pro každou vlastnost nejtypičtější datový typ. Volba správných typů je důležitá pro účinnost úložiště i výkon dotazů. Například číselné porovnání INT vlastností jsou rychlejší než porovnání řetězců s ekvivalentními STRING hodnotami.

Informace o podporovaných datových typech najdete v tématu Aktuální omezení – Datové typy a podporované typy vlastností.

Pokud je to možné, načtěte související entity v jednom grafu namísto vydávání samostatných dotazů, které procházejí stejnými okraji nezávisle. Kombinace procházení zabraňuje redundantnímu porovnávání vzorů a zabraňuje problému s dotazem N+1, kdy jeden počáteční dotaz aktivuje samostatný dotaz pro každý řádek výsledku.

Doporučené: Jeden kombinovaný vzor.

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

Vyhněte se: Dva samostatné dotazy, které procházejí stejnou Customer → Order hranou.

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

Testování dotazů na reálné objemy dat

Dotazy, které dobře fungují u malých datových sad, nemusí být škálovatelné lineárně. Otestujte dotazy pomocí datových svazků, které představují očekávané produkční úlohy.

  • Upřednostněte konzervativní tvary dotazů, které obsahují filtry a omezení.
  • Vyhněte se průzkumným dotazům, které vracejí všechny možné výsledky na velkých grafech.
  • Sledujte dobu trvání dotazu vzhledem k 20minutovému časovému limitu.

Související obsah

  • Last updated on