Prácticas recomendadas para las consultas de gráficos

En este documento, se describen las prácticas recomendadas para optimizar tus consultas de BigQuery Graph.

Comienza el recorrido de la ruta desde nodos de baja cardinalidad

Para mantener pequeños los conjuntos de resultados intermedios y acelerar la ejecución de las consultas, escribe tus consultas de gráficos de modo que el recorrido de la ruta comience desde nodos de menor cardinalidad, independientemente de la dirección del recorrido de la ruta. Las siguientes sentencias MATCH usan filtros de propiedades para reducir la cantidad de nodos iniciales posibles en lugar de calcular todas las coincidencias y, luego, filtrar:

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

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

Esto es especialmente importante para las consultas de rutas cuantificadas:

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

Usa la sintaxis ANY o ANY SHORTEST para las verificaciones de conectividad

Las consultas de rutas cuantificadas pueden mostrar rutas duplicadas entre los nodos de origen y los nodos de destino. Si tu objetivo es verificar la conectividad y no necesitas todas las rutas posibles, usa ANY o ANY SHORTEST para reducir los cálculos redundantes y mejorar la eficiencia de la búsqueda de rutas. Por ejemplo, la siguiente sentencia MATCH usa ANY SHORTEST para conservar solo una ruta entre cada par de nodos:

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

Usa el recorrido de la ruta direccional

Los esquemas de BigQuery Graph son direccionales, lo que significa que cada arista tiene un nodo de origen y un nodo de destino. Aunque la sintaxis de las consultas de gráficos permite el recorrido de la ruta en cualquier dirección (por ejemplo, -[edge]-), te recomendamos que uses el recorrido de la ruta direccional (por ejemplo, -[edge]-> o <-[edge]-) para obtener un mejor rendimiento. Cualquier recorrido de la ruta direccional puede provocar una pérdida de rendimiento.

La siguiente sentencia MATCH usa cualquier recorrido de la ruta direccional:

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

En su lugar, combina dos recorridos direccionales con UNION ALL:

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

Especifica etiquetas de forma explícita

Si se omiten las etiquetas de nodos o aristas en una consulta, BigQuery Graph enumera todas las etiquetas de nodos y aristas aptas. Esta enumeración puede hacer que se analicen más etiquetas de las necesarias. Para evitar esto, especifica etiquetas para todos los nodos y aristas de tu consulta siempre que sea posible.

Por ejemplo, la siguiente consulta especifica las etiquetas Account y Transfers:

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

Evita omitir etiquetas, ya que podría analizar otras relaciones innecesarias entre los nodos. En la siguiente consulta, a1 puede representar una cuenta o una persona, y t puede representar una transferencia o la propiedad de una cuenta.

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

Prefiere una sola sentencia MATCH

BigQuery Graph te permite incluir varias sentencias MATCH en una sola consulta de gráficos. Estas sentencias están conectadas por variables declaradas de forma múltiple que representan el mismo nodo o arista. Sin embargo, usar varias sentencias MATCH puede disminuir los beneficios de la cardinalidad en todas las sentencias. Cuando sea posible, usa una sola sentencia MATCH para obtener un mejor rendimiento.

Por ejemplo, las siguientes consultas son equivalentes, pero la primera funciona mejor porque usa una sola sentencia 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;

Limita las aristas recorridas de nodos de alta cardinalidad

Cuando consultas gráficos, algunos nodos pueden tener una cantidad significativamente mayor de aristas entrantes o salientes en comparación con otros nodos. Estos nodos de alta cardinalidad a veces se denominan supernodos o nodos centrales. Los supernodos pueden causar problemas de rendimiento porque los recorridos a través de ellos pueden implicar el procesamiento de grandes cantidades de datos, lo que genera una asimetría de datos y tiempos de ejecución prolongados.

Para optimizar una consulta de un gráfico con supernodos, usa la ROW_NUMBER() función dentro de una cláusula FILTER o cláusula WHERE en MATCH para limitar la cantidad de aristas que la consulta recorre desde un nodo o hacia él. Esta técnica es muy útil cuando no necesitas una enumeración completa de todas las conexiones desde un supernodo o hacia él.

Por ejemplo, si algunas cuentas en FinGraph tienen una gran cantidad de transacciones, puedes usar ROW_NUMBER() para limitar la cantidad de aristas Transfers que se deben considerar para cada Account y evitar una 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;

Muestrea nodos o aristas intermedios en consultas de varios saltos

También puedes mejorar la eficiencia de las consultas usando ROW_NUMBER() para muestrear nodos intermedios en consultas de varios saltos. Esta técnica mejora la eficiencia, ya que limita la cantidad de rutas que la consulta considera para cada nodo intermedio. Para ello, divide una consulta de varios saltos en varias sentencias MATCH separadas por NEXT y aplica ROW_NUMBER() en el punto medio en el que necesitas muestrear:

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;

¿Qué sigue?