Optimización del rendimiento de las consultas GQL para el grafo en Microsoft Fabric

En este artículo se proporcionan instrucciones para escribir consultas de GQL (lenguaje de consulta graph) que funcionan de forma predecible y eficaz al trabajar con grafos en Microsoft Fabric. Las recomendaciones se basan en el comportamiento actual de la plataforma y las restricciones documentadas.

Para conocer los límites estrictos del tamaño del gráfico, el tamaño del resultado y el tiempo de espera de consulta, consulte Limitaciones actuales. Varias recomendaciones de este artículo también se relacionan con el diseño del esquema de grafos. Para obtener más información, consulte Diseño de un esquema de grafo.

Colocar filtros según su semántica

Coloca un predicado dentro de un patrón de grafo cuando defina qué nodo o arista puede participar en la coincidencia. Utiliza una condición de nivel de instrucción MATCH ... WHERE para filtrar posteriormente la coincidencia completa, o una instrucción independiente FILTER cuando el predicado se aplica a la fila producida por una instrucción anterior.

Por ejemplo, utiliza cláusulas a nivel WHERE de patrón para las condiciones en los nodos emparejados:

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

Un FILTER independiente puede expresar la misma condición tras una coincidencia obligatoria normal que utiliza la búsqueda de ruta ALL predeterminada:

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

El optimizador de consultas puede aplicar predicados equivalentes durante el escaneo cuando al hacerlo se preserva la semántica de consulta, por lo que la sintaxis en línea no es intrínsecamente más rápida. Elige la forma que expresa cuándo se aplica la condición.

La colocación de predicados puede cambiar los resultados con ANY SHORTEST. Los predicados en línea limitan las rutas que pueden seleccionarse como ruta más corta. Un nivel WHERE de sentencia o un subsecuente FILTER se aplica tras la selección de caminos, por lo que puede eliminar un camino más corto seleccionado sin elegir uno más largo. Para la limitación actual MATCH ... WHERE y un patrón de colocación fiable, véase Colocar predicados antes o después de la selección de caminos.

La colocación también importa con OPTIONAL MATCH, donde un WHERE en línea restringe el emparejamiento opcional, pero un FILTER posterior puede eliminar la fila ampliada con valores nulos.

Devolver solo las propiedades que necesita

Devuelve solo las propiedades de nodo y perimetral que requiere el escenario. Evite devolver nodos completos o usar RETURN * cuando solo necesite un subconjunto de propiedades.

La selección de propiedades innecesarias aumenta la lectura de datos, el costo de serialización y el tamaño de respuesta. Durante el modelado de grafos, selecciona solo las columnas fuente que necesitas como propiedades de tipo de nodo.

Recomendado: Proyección estrecha.

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

Evite: Devolver nodos completos.

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

Limitar el tamaño del conjunto de resultados

Aplique LIMIT u otras condiciones de límite al consultar nodos o relaciones que puedan tener una cardinalidad alta. Las coincidencias de gráficos sin límites pueden producir conjuntos de resultados muy grandes que se aproximan a los límites de la plataforma.

Recomendado: Resultados limitados.

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

Evite: Coincidencia de alta cardinalidad sin límites.

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

Mantener los recorridos poco profundos y dirigidos

Evite patrones de grafos profundamente anidados o muy complejos. Use recorridos simples y dirigidos que respondan directamente a una pregunta específica. Cada salto adicional en un patrón de longitud variable puede aumentar exponencialmente el número de caminos que evalúa el motor, especialmente en grafos densamente conectados.

Recomendado: Límites estrechos.

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

Evitar: Un amplio rango de recorrido sin una necesidad clara.

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

Usa TRAIL cuando los caminos no deben repetir aristas

Utiliza TRAIL el modo camino cuando un camino válido no debe repetir una arista. En grafos con ciclos, esta restricción también puede reducir el número de caminos de coincidencia en comparación con el modo por defecto 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

Sin TRAIL, la misma consulta en un grafo cíclico puede devolver caminos que repiten una arista. Utiliza el modo que coincida con la semántica de ruta necesaria en lugar de considerar TRAIL una optimización general del rendimiento.

No se soporta un patrón ilimitado ALL WALK porque los ciclos pueden producir infinitos caminos. Aunque los patrones TRAIL, SIMPLE y ACYCLIC no están acotados, terminan, pero todavía pueden enumerar muchos caminos. Utiliza una cota superior finita a menos que la consulta requiera un recorrido no acotado.

Uso de variables compartidas para combinaciones eficaces

Cuando una consulta requiere datos de varias relaciones, use una variable compartida para combinar patrones en la misma entidad. Sin una variable compartida, los patrones pueden producir un producto cartesiano , cada combinación de coincidencias de ambos patrones, lo que conduce a un conjunto de resultados mucho mayor.

Recomendado: La variable p compartida combina los patrones.

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

Evite: Patrones independientes sin variable compartida.

-- 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 producto cartesiano combina cada resultado de un patrón con cada resultado del otro. Si Person-workAt->Company coincide con 1000 filas y Person-isLocatedIn->City coincide con 500 filas, la consulta devuelve 1000 × 500 = 500 000 filas. Agregar una variable compartida restringe la combinación para que solo se devuelvan pares coincidentes.

Filtra por propiedades clave al identificar nodos

Define las restricciones de clave de nodo para identificar los nodos de forma única y hacer cumplir la integridad de los datos. Cuando necesites un nodo específico, incluye su propiedad clave en el predicado del patrón para evitar que coincidan con nodos no relacionados.

Por ejemplo, si el tipo de grafo define id como clave para Person nodos:

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

Luego filtra por id cuando necesites a esa persona:

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

Sin el filtro, la consulta coincide con todos los nodos Person antes de recorrer las aristas workAt:

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

Elección de los tipos de datos adecuados

Seleccione el tipo de dato que represente los valores y operaciones previstas de cada propiedad. Por ejemplo, usa un tipo numérico para los valores que calculas o comparas numéricamente en lugar de almacenar números formateados como cadenas.

Para ver los tipos de datos admitidos, consulte Limitaciones actuales: tipos de datos y tipos de propiedades admitidos.

Combinar recorridos relacionados en una sola consulta

Siempre que sea posible, recupere entidades relacionadas en un único patrón de grafo en lugar de emitir consultas independientes que atraviesan los mismos bordes de forma independiente. La combinación de recorridos evita la coincidencia de patrones redundantes y evita el problema de consulta N+1, donde una consulta inicial desencadena una consulta independiente para cada fila de resultados.

Recomendado: Patrón combinado único.

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

Evite: Dos consultas independientes que atraviesan el mismo Customer → Order borde.

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

Prueba de consultas en volúmenes de datos realistas

Es posible que las consultas que funcionan bien en conjuntos de datos pequeños no se escalen linealmente. Pruebe las consultas con volúmenes de datos que representan la carga de trabajo de producción esperada.

• Se prefieren formas de consulta conservadoras que incluyen filtros y límites.
• Evite consultas exploratorias del tipo "devolver todo" en grafos grandes.
• Supervise la duración de la consulta en relación con el límite de tiempo de espera de 20 minutos.

Contenido relacionado

• Guía del lenguaje GQL
• Tipos de grafos GQL
• Patrones de grafos de GQL
• Limitaciones actuales
• Solución de problemas y preguntas frecuentes