Práticas recomendadas para consultas de gráfico

É possível otimizar o desempenho das consultas do BigQuery Graph estruturando as consultas da Graph Query Language (GQL) para minimizar os dados verificados e os resultados intermediários.

Iniciar a travessia de caminhos em nós de baixa cardinalidade

Para manter os conjuntos de resultados intermediários pequenos e acelerar a execução da consulta, escreva as consultas de gráfico de modo que a travessia de caminho comece em nós de cardinalidade mais baixa, independentemente da direção da travessia de caminho. As seguintes instruções MATCH usam filtros de propriedade para reduzir o número de possíveis nós iniciais em vez de calcular todas as correspondências e depois filtrar:

MATCH (p:Person {id: 10})-[own:Owns]->(a:Account)

MATCH (a:Account WHERE balance > 10)<-[own:Owns]-(p:Person)

Isso é especialmente importante para consultas de caminho quantificadas:

MATCH (p:Person {id: 10})-[own:Owns]->{1,3}(a:Account)

Usar a sintaxe ANY ou ANY SHORTEST para verificações de conectividade

As consultas de caminho quantificadas podem retornar caminhos duplicados entre nós de origem e nós de destino. Se o objetivo for verificar a conectividade e você não precisar de todos os caminhos possíveis, use ANY ou ANY SHORTEST para reduzir cálculos redundantes e melhorar a eficiência da pesquisa de caminhos. Por exemplo, a seguinte instrução MATCH usa ANY SHORTEST para manter apenas um caminho entre cada par de nós:

MATCH ANY SHORTEST (a1:Account)-[t:Transfers]->{1,3}(a2:Account)

Usar a travessia de caminho direcional

Os esquemas do BigQuery Graph são direcionais, o que significa que cada aresta tem um nó de origem e um nó de destino. Embora a sintaxe de consulta de gráfico permita a travessia de caminho em qualquer direção (por exemplo, -[edge]-), recomendamos o uso da travessia de caminho direcional (por exemplo, -[edge]-> ou <-[edge]-) para melhorar o desempenho. Qualquer travessia de caminho de direção pode causar perda de desempenho.

A instrução MATCH a seguir usa a travessia de caminho em qualquer direção:

-- Avoid.
MATCH (a1:Account {id: 7})-[t:Transfers]-(a2:Account)

Em vez disso, combine duas travessias direcionais com UNION ALL:

MATCH (a1:Account {id: 7})-[t:Transfers]->(a2:Account)
...
UNION ALL
...
MATCH (a1:Account  {id: 7})<-[t:Transfers]-(a2:Account)

Especificar rótulos explicitamente

Se os rótulos de nós ou arestas forem omitidos em uma consulta, o BigQuery Graph vai enumerar todos os rótulos de nós e arestas qualificados. Essa enumeração pode fazer com que mais rótulos sejam verificados do que o necessário. Para evitar isso, especifique rótulos para todos os nós e arestas na consulta sempre que possível.

Por exemplo, a consulta a seguir especifica os rótulos Account e Transfers:

GRAPH graph_db.FinGraph
MATCH (a1:Account)-[t:Transfers]->(a2:Account)
RETURN COUNT(*) AS num_transfers;

Evite omitir rótulos, porque isso pode verificar outras relações desnecessárias entre nós. Na consulta a seguir, a1 pode representar uma conta ou uma pessoa, e t pode representar uma transferência ou a propriedade de uma conta.

GRAPH graph_db.FinGraph
MATCH (a1)-[t]->(a2)
RETURN COUNT(*) AS num_transfers;

Preferir uma única instrução MATCH

O BigQuery Graph permite incluir várias instruções MATCH em uma única consulta de grafo. Essas instruções são conectadas por variáveis declaradas várias vezes que representam o mesmo nó ou aresta. No entanto, o uso de várias instruções MATCH pode diminuir os benefícios de cardinalidade entre as instruções. Quando possível, use uma única instrução MATCH para melhorar o desempenho.

Por exemplo, as consultas a seguir são equivalentes, mas a primeira tem um desempenho melhor porque usa uma única instrução MATCH:

-- Preferred syntax.
GRAPH graph_db.FinGraph
MATCH
  (p:Person {id: 1})-[o:Owns]->
  (a:Account)-[t:Transfers]->(a2:Account)
RETURN o.account_id, t.amount;

-- Avoid this syntax.
GRAPH graph_db.FinGraph
MATCH (p:Person {id: 1})-[o:Owns]->(a:Account)
MATCH (a:Account)-[t:Transfers]->(a2:Account)
RETURN o.account_id, t.amount;

Limitar as arestas atravessadas de nós de alta cardinalidade

Ao consultar gráficos, alguns nós podem ter um número significativamente maior de arestas de entrada ou saída em comparação com outros nós. Esses nós de alta cardinalidade às vezes são chamados de supernós ou nós de hub. Os supernós podem causar problemas de desempenho, porque as travessias por eles podem envolver o processamento de grandes quantidades de dados, o que leva a desvios de dados e longos tempos de execução.

Para otimizar uma consulta de um gráfico com supernós, use a função ROW_NUMBER() em uma cláusula FILTER ou WHERE em MATCH para limitar o número de arestas que a consulta atravessa de ou para um nó. Essa técnica é particularmente útil quando você não precisa de uma enumeração completa de todas as conexões de ou para um supernó.

Por exemplo, se algumas contas em FinGraph tiverem um grande número de transações, use ROW_NUMBER() para limitar o número de arestas Transfers a serem consideradas para cada Account e evitar uma consulta ineficiente:

GRAPH graph_db.FinGraph
MATCH (a1:Account)-[e1:Transfers WHERE e1 IN {
  GRAPH graph_db.FinGraph
  -- Sample 5 edges per source node
  MATCH -[selected_e:Transfers]->
    FILTER ROW_NUMBER() OVER (
      PARTITION BY SOURCE_NODE_ID(selected_e)) < 5
    RETURN selected_e
}]->{1,3}(a2:Account)
RETURN COUNT(*) AS cnt;

Amostra de nós ou arestas intermediários em consultas de vários saltos

Também é possível melhorar a eficiência da consulta usando ROW_NUMBER() para amostrar nós intermediários em consultas de vários saltos. Essa técnica melhora a eficiência ao limitar o número de caminhos que a consulta considera para cada nó intermediário. Para fazer isso, divida uma consulta de vários saltos em várias instruções MATCH separadas por NEXT e aplique ROW_NUMBER() no ponto médio em que você precisa fazer a amostragem:

GRAPH graph_db.FinGraph
MATCH (a1:Account)-[e1:Transfers]->(a2:Account)
-- Sample 5 destination nodes per a1 source node
FILTER ROW_NUMBER() OVER (PARTITION BY ELEMENT_ID(a1)) < 5
RETURN a1, a2
NEXT
MATCH (a2)-[e2:Transfers]->(a3:Account)
RETURN a1.id AS src_id, a2.id AS mid_id, a3.id AS dst_id;

A seguir