Otimizar o desempenho da consulta GQL para grafo no Microsoft Fabric

Este artigo fornece diretrizes para escrever consultas GQL (Graph Query Language) que têm um desempenho previsível e eficiente ao trabalhar com grafo em Microsoft Fabric. As recomendações se baseiam no comportamento atual da plataforma e nas restrições documentadas.

Para obter limites rígidos sobre o tamanho do grafo, o tamanho do resultado e o tempo limite da consulta, consulte as limitações atuais. Várias recomendações neste artigo também estão relacionadas à forma como você projeta seu esquema de grafo. Para obter mais informações, consulte Criar um esquema de grafo.

Coloque filtros de acordo com sua semântica

Coloque um predicado dentro de um padrão de grafo quando ele define qual nó ou aresta pode participar da correspondência. Use uma condição MATCH ... WHERE no nível da instrução para pós-filtrar a correspondência concluída, ou uma instrução FILTER separada quando o predicado se aplica à linha produzida por uma instrução anterior.

Por exemplo, use cláusulas WHERE no nível do padrão para condições nos nós correspondentes:

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

Um(a) FILTER separado(a) pode expressar a mesma condição após uma correspondência obrigatória normal que usa a pesquisa de caminho ALL padrão:

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

O otimizador de consultas pode aplicar predicados equivalentes na varredura quando isso preserva a semântica da consulta, portanto a sintaxe inline não é inerentemente mais rápida. Escolha a forma que expressa quando a condição se aplica.

A colocação de predicados pode alterar os resultados com ANY SHORTEST. Predicados em linha restringem os caminhos elegíveis para seleção do caminho mais curto. Uma instrução no nível WHERE ou um FILTER subsequente se aplica após a seleção do caminho, de modo que pode remover o caminho mais curto selecionado sem, em vez disso, escolher um caminho mais longo. Para conhecer a limitação atual MATCH ... WHERE e um padrão de posicionamento confiável, consulte Coloque predicados antes ou depois da seleção de caminho.

A posição também importa com OPTIONAL MATCH, em que um WHERE inline restringe a correspondência opcional, mas um FILTER subsequente pode remover a linha estendida por nulos.

Retornar somente as propriedades necessárias

Retorne apenas as propriedades de borda e nó que o seu cenário requer. Evite retornar nós completos ou usar RETURN * quando precisar apenas de um subconjunto de propriedades.

Selecionar propriedades desnecessárias aumenta a leitura de dados, o custo de serialização e o tamanho da resposta. Durante a modelagem de grafos, selecione apenas as colunas de origem que você precisa como propriedades do tipo de nó.

Recomendado: Projeção estreita.

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

Evitar: Retornar nós completos.

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

Limitar o tamanho do conjunto de resultados

Aplique LIMIT ou outras condições delimitadoras ao consultar nós ou relações que possam ter alta cardinalidade. Correspondências de grafos ilimitadas podem produzir conjuntos de resultados muito grandes que se aproximam dos limites da plataforma.

Recomendado: Resultados limitados.

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

Evitar: Correspondência de alta cardinalidade sem limites.

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

Manter os percursos superficiais e direcionados

Evite padrões de grafo profundamente aninhados ou altamente complexos. Use passagens simples e direcionadas que respondem diretamente a uma pergunta específica. Cada salto extra em um padrão de comprimento variável pode aumentar exponencialmente o número de caminhos que o mecanismo avalia, especialmente em grafos densamente conectados.

Recomendado: Limites estritos.

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

Evite: Uma ampla faixa de deslocamento sem uma necessidade clara.

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

Use TRAIL quando os caminhos não devem repetir as bordas

Use TRAIL o modo caminho quando um caminho válido não deve repetir uma aresta. Em grafos com ciclos, essa restrição também pode reduzir o número de caminhos correspondentes em comparação com o modo padrão 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

Sem TRAIL, a mesma consulta em um grafo cíclico pode retornar caminhos que repetem uma aresta. Use o modo que corresponda à semântica de caminho exigida, em vez de tratar TRAIL como uma otimização geral de desempenho.

Um padrão ilimitado ALL WALK não é suportado porque ciclos podem produzir infinitos caminhos. Embora os padrões TRAIL, SIMPLE e ACYCLIC ilimitados terminem, eles ainda podem enumerar muitos caminhos. Use um limite superior finito, a menos que a consulta exija travessia ilimitada.

Usar variáveis compartilhadas para junções eficientes

Quando uma consulta requer dados de várias relações, use uma variável compartilhada para unir padrões na mesma entidade. Sem uma variável compartilhada, os padrões podem produzir um produto cartesiano - cada combinação de correspondências de ambos os padrões - levando a um conjunto de resultados muito maior.

Recomendado: A variável p compartilhada une os padrões.

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

Evitar: Padrões independentes sem variável compartilhada.

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

Um produto cartesiano emparelha cada resultado de um padrão com cada resultado do outro. Se Person-workAt->Company corresponder a 1.000 linhas e Person-isLocatedIn->City corresponder a 500 linhas, a consulta retornará 1.000 × 500 = 500.000 linhas. Adicionar uma variável compartilhada restringe a junção para que somente pares correspondentes sejam retornados.

Filtrar por propriedades-chave ao identificar os nós

Defina restrições de chave de nós para identificar nós de forma única e garantir a integridade dos dados. Quando precisar de um nó específico, inclua sua propriedade-chave no predicado do padrão para evitar fazer correspondência com nós não relacionados.

Por exemplo, se o seu tipo de grafo definir id como a chave para os nós Person:

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

Em seguida, filtre por id quando precisar dessa pessoa:

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

Sem o filtro, a consulta corresponde a todos Person os nós antes de atravessar workAt as arestas:

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

Escolher tipos de dados apropriados

Selecione o tipo de dado que representa os valores e operações pretendidas de cada propriedade. Por exemplo, use um tipo numérico para valores que você calcula ou compara numericamente, em vez de armazenar números formatados como cadeias de caracteres.

Para tipos de dados com suporte, consulte As limitações atuais — tipos de dados e tipos de propriedade com suporte.

Combinar percursos relacionados em uma única consulta

Sempre que possível, recupere entidades relacionadas em um único padrão de grafo em vez de emitir consultas separadas que percorram as mesmas bordas de forma independente. A combinação de iterações evita padrões de correspondência redundantes e impede o problema da consulta N+1, em que uma consulta inicial aciona uma consulta separada para cada linha de resultado.

Recomendado: Padrão combinado único.

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

Evitar: Duas consultas separadas que atravessam a mesma Customer → Order aresta.

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

Testar consultas em volumes de dados realistas

As consultas que têm um bom desempenho em pequenos conjuntos de dados podem não ser dimensionadas linearmente. Teste suas consultas com volumes de dados que representam sua carga de trabalho de produção esperada.

• Prefira formas de consulta conservadoras que incluam filtros e limites.
• Evite consultas exploratórias de "retornar tudo" em grafos grandes.
• Monitore a duração da consulta em relação ao limite de tempo de 20 minutos.

Conteúdo relacionado

• Guia de idioma GQL
• Tipos de grafo GQL
• Padrões de grafo GQL
• Limitações atuais
• Solução de problemas e perguntas frequentes