Optimoi GQL-kyselyjen suorituskyky graafille Microsoft Fabric -sovelluksessa

Tämä artikkeli antaa ohjeita GQL (Graph Query Language) -kyselyiden kirjoittamiseen, jotka toimivat ennustettavasti ja tehokkaasti työskennellessä graafin kanssa Microsoft Fabric -ohjelmassa. Suositukset perustuvat nykyiseen alustan käyttäytymiseen ja dokumentoituihin rajoitteisiin.

Graafin koon, tuloskoon ja kyselyaikakatkaisun kovat rajat löytyvät kohdasta Nykyiset rajoitukset. Useat tämän artikkelin suositukset liittyvät myös siihen, miten suunnittelet graafiskeemaa. Lisätietoja löytyy kohdasta Graafiskeeman suunnittelu.

Aseta suodattimet semantiikan mukaan

Aseta predikaatti graafikuvioon, kun se määrittelee, mikä solmu tai reuna voi osallistua otteluun. Käytä lausetasoista MATCH ... WHERE ehtoa valmiin vastaavuuden jälkisuodattamiseen tai erillistä FILTER lausetta, kun predikaatti koskee aiemman lauseen tuottamaa riviä.

Esimerkiksi käytä kuviotason WHERE lausekkeita yhteensopivien solmujen ehdoille:

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

Erillinen FILTER voi ilmaista saman ehdon tavallisen pakollisen vastaavuuden jälkeen, joka käyttää oletuspolkuhakua ALL :

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

Kyselyoptimaattori voi soveltaa vastaavia predikaattia skannauksen aikana, jolloin se säilyttää kyselyjen semantiikkaa, joten inline-syntaksi ei ole itsessään nopeampi. Valitse muoto, joka ilmaisee, milloin ehto pätee.

Predikaattisijoittelu voi muuttaa tuloksia .ANY SHORTEST Inline-predikaatit rajoittavat lyhimmän polun valintaan soveltuvia polkuja. Lausetaso WHERE tai seuraava FILTER reitti sovelletaan polun valinnan jälkeen, joten se voi poistaa valitun lyhimmän polun valitsematta pidempää polkua. Nykyisen MATCH ... WHERE rajoituksen ja luotettavan sijoitusmallin osalta katso Sijoituspredikaatit ennen tai jälkeen polun valinnan.

Sijoituksella on myös merkitystä , OPTIONAL MATCHjossa inline-rivi WHERE rajoittaa valinnaisen vastaavuuden, mutta seuraava FILTER voi poistaa nolla-laajennetun rivin.

Vinkki

Ajattele pattern-tasoa WHERE analogiana SQL-ehtoon JOIN ... ON . Se kuvaa, mitkä ottelut täyttävät kriteerit, sen sijaan että suodatettaisiin seuraava rivi.

Palauta vain tarvitsemasi kiinteistöt

Palauta vain ne solmu- ja reunaominaisuudet, joita skenaariosi vaatii. Vältä täyttä solmujen palauttamista tai niiden käyttöä RETURN * , kun tarvitset vain osan ominaisuuksista.

Tarpeettomien ominaisuuksien valinta lisää datan lukua, sarjoittamiskustannuksia ja vasteen kokoa. Graafimallinnuksen aikana valitse vain ne lähdesarakkeet, joita tarvitset solmutyyppiominaisuuksiksi.

Suositeltavat: Kapea projektio.

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

Vältä: Palautan täydet solmut.

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

Muistio

Lisää solmutyyppiset ominaisuudet graafimallinnuksen aikana vain, kun niitä tarvitaan kyselyihin tai analyysiin. Vähemmän ominaisuuksia solmua kohden vähentää sekä storage- että kyselykuormaa.

Raja-tulosjoukon koko

Sovella LIMIT tai muita rajoittavia ehtoja, kun kysytään solmuja tai suhteita, joilla voi olla korkea kardinaalisuus. Rajoittamattomat graafisovitukset voivat tuottaa erittäin suuria tulosjoukkoja, jotka lähestyvät alustan rajoja.

Suositeltavat: Rajoitetut tulokset.

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

Vältä: Rajoittamaton korkean kardinaalisuuden ottelu.

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

Tärkeää

Graafi katkaisee kyselyvastukset, joiden sisäinen binääriesitys ylittää 64 MB. Katkaistu vastaus sisältää lisästatuksen, jossa on julkinen koodi 01000 ja kanoninen GQLSTATUS 01M11. Käytä suodattimia, kapeita projektioita ja LIMIT pienennä tuloksen kokoa. Lisätietoja löytyy kohdasta Nykyiset rajoitukset.

Pidä liikkumiset matalissa ja kohdennetuina

Vältä syvälle sisäkkäisiä tai erittäin monimutkaisia graafikuvioita. Käytä yksinkertaisia, kohdennettuja kulkuja, jotka vastaavat suoraan tiettyyn kysymykseen. Jokainen ylimääräinen hyppy muuttuvan pituuden kuviossa voi eksponentiaalisesti kasvattaa moottorin arvioimien polkujen määrää, erityisesti tiheästi yhdistetyissä graafeissa.

Suositeltavat: Tiukat rajat.

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

Vältä: Laaja liikkumisalue ilman selvää tarvetta.

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

Tärkeää

Visuaalinen kyselyrakentaja rajoittaa muuttuvan pituiset polut kahdeksaan hyppyyn, mutta tämä käyttöliittymärajoitus ei koske GQL:ää koodieditorissa. Käytä tiukinta rajoitusta, jonka skenaariosi sallii, koska laajempi alue voi vastata useampiin polkuihin.

Käytä TRAILia, kun polut eivät saa toistaa reunoja

Käytä TRAIL polkutilaa, kun kelvollinen polku ei saa toistaa reunaa. Syklikaavioissa tämä rajoitus voi myös vähentää yhteensopivien polkujen määrää verrattuna oletustilaan 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

Ilman TRAIL, sama kysely syklisestä graafista voi palauttaa polkuja, jotka toistavat reunan. Käytä tilaa, joka vastaa vaadittua polkusemantiikkaa, sen sijaan että sitä kohdellaan TRAIL yleisenä suorituskyvyn optimoinnina.

Rajoittamatonta ALL WALK kuviota ei tueta, koska syklit voivat tuottaa äärettömän monta polkua. Vaikka rajoittamattomat TRAIL, SIMPLE, ja ACYCLIC kuviot päättyvät, ne voivat silti luetella monia polkuja. Käytä äärellistä ylärajaa, ellei kysely vaadi rajoittamatonta kulkua.

Käytä jaettuja muuttujia tehokkaisiin liitoksiin

Kun kysely vaatii dataa useista suhteista, käytä jaettua muuttujaa yhdistämään kuvioita samalla entiteettillä. Ilman yhteistä muuttujaa kuviot voivat tuottaa karteesisen tulon – jokaisen molempien mallien yhdistelmän – mikä johtaa paljon suurempaan tulosjoukkoon.

Suositeltavat: Yhteinen muuttuja p liittyy kuvioihin.

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

Vältä: Itsenäiset kuviot ilman yhteistä muuttujaa.

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

Karteesinen tulo yhdistää jokaisen tuloksen yhdestä kuviosta jokaiseen toisen tuloksiin. Jos Person-workAt->Company vastaa 1 000 riviä ja Person-isLocatedIn->City 500 riveä, kysely palauttaa 1 000 × 500 = 500 000 riviä. Jaetun muuttujan lisääminen rajoittaa liitosta, joten palautuvat vain vastaavat parit.

Suodata avainominaisuuksia solmujen tunnistamisessa

Määrittele solmuavainrajoitteet solmujen yksilöllisyyden varmistamiseksi ja tietojen eheyden varmistamiseksi. Kun tarvitset yhden tietyn solmun, sisällytä sen avainominaisuus kuviopredikaattiin, jotta välttääksesi toisiinsa liittymättömien solmujen yhdistämisen.

Esimerkiksi, jos graafityyppisi määrittelee id solmujen avaimen Person :

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

Sitten suodatetaan, id kun tarvitset kyseistä henkilöä:

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

Ilman suodatinta kysely vastaa jokaista Person solmua ennen reunojen workAt läpikulkua:

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

Vinkki

Keskeinen rajoite määrittää identiteetin ja ainutlaatuisuuden. Se ei itsessään takaa tiettyä fyysistä haku- tai hakusuunnitelmaa.

Valitse asianmukaiset tietotyypit

Valitse tietotyyppi, joka edustaa kunkin ominaisuuden arvoja ja tarkoitettuja operaatioita. Esimerkiksi käytä numeerista tyyppiä arvoille, joita lasket tai vertaat numeerisesti, sen sijaan että tallennat muotoiltuja lukuja merkkijonoina.

Tuetuista tietotyypeistä katso Nykyiset rajoitukset — Tietotyypit ja Tuetut ominaisuustyypit.

Mahdollisuuksien mukaan hae siihen liittyvät yksiköt yhdellä graafikuviolla sen sijaan, että lähettäisit erillisiä kyselyitä, jotka kulkevat samoja reunoja itsenäisesti. Läpikäyntien yhdistäminen välttää päällekkäiset kuvioiden sovittamisen ja estää N+1-kyselyongelman, jossa yksi alkuperäinen kysely laukaisee erillisen kyselyn jokaiselle tulosriville.

Suositeltavat: Yksittäinen yhdistetty kuvio.

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

Vältä: Kaksi erillistä kyselyä, jotka kulkevat saman Customer → Order reunan läpi.

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

Testaa kyselyt realistisia datamääriä vastaan

Kyselyt, jotka toimivat hyvin pienillä aineistoilla, eivät välttämättä skaalaa lineaarisesti. Testaa kyselysi datavolyymeilla, jotka edustavat odotettua tuotantokuormaasi.

  • Suosi konservatiivisia kyselymuotoja, joissa on suodattimia ja rajoituksia.
  • Vältä tutkivia "palauta kaikki" -kyselyjä suuria kaavioita vastaan.
  • Seuraa kyselyn kestoa suhteessa 20 minuutin aikarajaan.

Liittyvä sisältö

  • Last updated on