Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Annotazioni
Questa funzionalità è attualmente disponibile in anteprima pubblica. Questa anteprima viene messa a disposizione senza contratto di servizio e non è consigliata per i carichi di lavoro di produzione. Alcune funzionalità potrebbero non essere supportate o potrebbero presentare funzionalità limitate. Per altre informazioni, vedere Supplemental Terms of Use for Microsoft Azure Previews.
Questo articolo fornisce indicazioni per la scrittura di query GQL (Graph Query Language) che eseguono prestazioni prevedibili ed efficienti quando si lavora con graph in Microsoft Fabric. Le raccomandazioni sono basate sul comportamento corrente della piattaforma e sui vincoli documentati.
Per i limiti rigidi relativi alle dimensioni del grafo, alle dimensioni dei risultati e al timeout delle query, vedere Limitazioni correnti.
Filtrare in anticipo i modelli
Posizionare i filtri all'interno dei modelli di grafo anziché nelle istruzioni successive. Le clausole a livello WHERE di pattern riducono il numero di risultati intermedi prima dell'esecuzione dei join e delle istruzioni successive, riducendo così il costo complessivo di esecuzione.
Consigliato: Filtrare durante la corrispondenza di modelli.
-- 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
Evitare: Filtrare tardi con un'istruzione FILTER distinta.
-- 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
Entrambe le query restituiscono gli stessi risultati, ma la prima versione consente al motore di query di eliminare le righe in precedenza nel processo di valutazione.
Suggerimento
Pensa al livello di pattern WHERE lì come analogo a una condizione SQL JOIN ... ON. Limita le corrispondenze al momento della valutazione invece di filtrare il set di risultati completo.
Restituisce solo le proprietà necessarie
Restituisce solo le proprietà del nodo e dei bordi richiesti dallo scenario. Evitare di restituire nodi completi o usare RETURN * quando è necessario solo un subset di proprietà.
Nel grafico, OneLake supporta le proprietà del nodo. La selezione di proprietà non necessarie aumenta le dimensioni di lettura, serializzazione e risposta dei dati. Durante la modellazione del grafo, tutte le colonne della tabella di origine vengono aggiunte come proprietà per impostazione predefinita, a meno che non vengano rimosse.
Consigliato: Proiezione ridotta.
MATCH (p:Person)-[:workAt]->(c:Company)
RETURN p.firstName, p.lastName, c.name
Evitare: Evitare di restituire nodi completi.
MATCH (p:Person)-[:workAt]->(c:Company)
RETURN *
Annotazioni
Rimuovere le proprietà inutilizzate durante la modellazione del grafo selezionando l'icona del cestino accanto a ogni proprietà. Un numero minore di proprietà per nodo riduce sia lo storage che l'overhead delle query.
Limitare le dimensioni del set di risultati
Applicare LIMIT o altre condizioni di limitazione al momento di eseguire query su nodi o relazioni con cardinalità elevata. Le corrispondenze del grafico illimitato possono produrre set di risultati molto grandi che si avvicinano ai limiti della piattaforma.
Consigliato: Risultati delimitati.
MATCH (p:Person)-[:knows]->(friend:Person)
RETURN p.firstName, friend.firstName
LIMIT 1000
Evitare: Corrispondenza con cardinalità elevata non limitata.
MATCH (p:Person)-[:knows]->(friend:Person)
RETURN p.firstName, friend.firstName
Importante
Il grafico tronca le risposte superiori a 64 MB e le prestazioni di aggregazione possono essere instabile quando i risultati superano 128 MB. Usare FILTER, LIMITe GROUP BY per mantenere i risultati all'interno di questi limiti. Per altre informazioni, vedere le limitazioni correnti.
Mantenere gli attraversamenti superficiali e mirati
Evitare modelli a grafo profondamente annidati o altamente complessi. Preferisce attraversamenti semplici e mirati che rispondono direttamente a una domanda specifica. Ogni hop aggiuntivo in un modello a lunghezza variabile può aumentare in modo esponenziale il numero di percorsi valutati dal motore, specialmente in grafici con connessione densa.
Consigliato: Vincoli stretti.
-- Use the narrowest hop range that answers your question
MATCH (p:Person)-[:knows]->{1,3}(friend:Person)
RETURN p.firstName, friend.firstName
LIMIT 1000
Evitare: Traversata di profondità massima senza una necessità chiara.
-- Exploring the full 8-hop limit on a dense graph is expensive
MATCH (p:Person)-[:knows]->{1,8}(friend:Person)
RETURN *
Importante
graph supporta fino a otto passaggi nei modelli a lunghezza variabile. Anche in questo caso, usare i limiti più stretti consentiti dallo scenario. Nell'esempio il {1,3} modello è notevolmente più economico rispetto {1,8} allo stesso grafico.
Usare TRAIL per impedire attraversamenti ridondanti
Usare la modalità percorso TRAIL per impedire al motore di query di ripercorrere lo stesso arco. Nei grafici densi, i cicli possono causare un'esplosione esponenziale del percorso.
TRAIL assicura che ogni arco venga visitato al massimo una volta per ogni percorso, migliorando sia la correttezza che le prestazioni.
-- 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
Senza TRAIL, la stessa query su un grafico ciclico può produrre un set di risultati molto più grande (e spesso ridondante).
Usare variabili condivise per unioni efficienti
Quando una query richiede dati di più relazioni, usare una variabile condivisa per unire i modelli nella stessa entità. Senza una variabile condivisa, i modelli possono produrre un prodotto cartesiano, ogni combinazione di corrispondenze di entrambi i modelli, portando a un set di risultati molto più ampio.
Consigliato: La variabile p condivisa unisce i modelli.
-- 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
Evitare: Modelli indipendenti senza variabile condivisa.
-- 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
Un prodotto cartesiano associa ogni risultato da un modello con ogni risultato dall'altro. Se Person-workAt->Company corrisponde a 1.000 righe e Person-isLocatedIn->City corrisponde a 500 righe, la query restituisce 1.000 × 500 = 500.000 righe. L'aggiunta di una variabile condivisa vincola il join in modo che vengano restituite solo le coppie corrispondenti.
Definire i vincoli di chiave nei nodi
Definire i vincoli di chiave del nodo nel tuo tipo di grafo. I vincoli di chiave consentono al sistema di ottimizzare le query che cercano nodi specifici in base alle relative proprietà chiave, in modo analogo agli indici di chiave primaria nei database relazionali.
Ad esempio, se il tipo di grafo definisce id come chiave per i Person nodi:
CONSTRAINT person_pk
FOR (n:Person) REQUIRE n.id IS KEY
Le query che filtrano su id possono quindi usare tale chiave per una ricerca diretta:
-- 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
Senza il filtro sulla proprietà chiave, il motore deve analizzare ogni Person nodo:
-- Slower: scans all Person nodes before traversing
MATCH (p:Person)-[:workAt]->(c:Company)
RETURN p.firstName, c.name
Suggerimento
Quando è necessario un nodo specifico, filtrarne la MATCH proprietà chiave nel modello per sfruttare il vincolo definito.
Scegliere i tipi di dati appropriati
Selezionare il tipo di dati più specifico per ogni proprietà durante la modellazione del grafo. La scelta dei tipi corretti è importante sia per l'efficienza dell'archiviazione che per le prestazioni delle interrogazioni. Ad esempio, i confronti numerici sulle INT proprietà sono più veloci rispetto ai confronti di stringhe su valori equivalenti STRING .
Per i tipi di dati supportati, vedere Limitazioni correnti - Tipi di dati e Tipi di proprietà supportati.
Combinare attraversamenti correlati in una singola query
Se possibile, recuperare le entità correlate in un singolo modello a grafo anziché eseguire query separate che attraversano gli stessi bordi in modo indipendente. La combinazione di attraversamenti evita gli abbinamenti di pattern ridondanti e impedisce il problema N+1 delle query, in cui una query iniziale attiva una query separata per ogni riga di risultato.
Consigliato: Modello combinato singolo.
MATCH (c:Customer)-[:purchased]->(o:Order)-[:contains]->(product:Product)
RETURN c.id, o.id, product.name
LIMIT 1000
Evitare: Due query separate che attraversano lo stesso Customer → Order arco.
-- 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
Testare query con volumi di dati realistici
Le query che funzionano correttamente su set di dati di piccole dimensioni potrebbero non essere ridimensionate in modo lineare. Testare le query con volumi di dati che rappresentano il carico di lavoro di produzione previsto.
- Preferisce forme di query conservatrici che includono filtri e limiti.
- Evitare interrogazioni esplorative che restituiscono tutto su grafici di grandi dimensioni.
- Monitorare la durata della query rispetto al limite di timeout di 20 minuti.