Cómo se procesan las consultas de Gremlin en Neptune
En Amazon Neptune, los recorridos más complejos se pueden representar mediante una serie de patrones que crean una relación basada en la definición de variables con nombre que se pueden compartir entre patrones para crear uniones. Esto se muestra en el siguiente ejemplo.
Pregunta: ¿Cuál es el vecindario de dos saltos del vértice v1?
Gremlin code: g.V(‘v1’).out('knows').out('knows').path() Pattern: (?1=<v1>, <knows>, ?2, ?) X Pattern(?2, <knows>, ?3, ?) The pattern produces a three-column relation (?1, ?2, ?3) like this: ?1 ?2 ?3 ================ v1 v2 v3 v1 v2 v4 v1 v5 v6
Cuando se comparte la variable ?2 entre los dos patrones (en la posición O en el primer patrón y en la posición S del segundo patrón), se crea una combinación entre los vecinos del primer salto y los vecinos del segundo salto. Cada solución de Neptune tiene enlaces para las tres variables con nombre, que se pueden utilizar para volver a crear un recorrido de TinkerPop
El primer paso en el procesamiento de consultas de Gremlin consiste en analizar la consulta en un objeto derecorrido.V() está representado y ejecutado por TinkerPop GraphStep
Puesto que estos pasos de TinkerPop estándar son ejecutables, un recorrido de TinkerPop puede ejecutar cualquier consulta de Gremlin y generar la respuesta correcta. Sin embargo, cuando se ejecutan en un gráfico grande, los pasos de TinkerPop a veces pueden ser muy ineficientes y lentos. En lugar de utilizarlos, Neptune intenta convertir el recorrido en una forma declarativa compuesta por grupos de patrones, tal y como se ha descrito anteriormente.
Neptune no admite actualmente todos los operadores de Gremlin (pasos) en su motor de consultas nativo. Por lo tanto, intenta contraer tantos pasos como sea posible en un único NeptuneGraphQueryStep, que contiene el plan de consulta lógica declarativa para todos los pasos que se han convertido. Idealmente, se convierten todos los pasos. Sin embargo, cuando se encuentra un paso que no se puede convertir, Neptune interrumpe la ejecución nativa y aplaza toda la ejecución de consultas de ese punto en adelante hasta los pasos de TinkerPop. No intenta entrelazar y salir de la ejecución nativa.
Después de convertir los pasos en un plan de consulta lógica, Neptune ejecuta una serie de optimizadores de consultas que reescriben el plan de consulta en función del análisis estático y las cardinalidades estimadas. Esos optimizadores realizan tareas como reordenar operadores en función del recuento de rangos, eliminar operadores innecesarios o redundantes, reorganizar filtros, insertar operadores en diferentes grupos, etc.
Después de generar un plan de consulta optimizado, Neptune crea una canalización de operadores físicos que realizan el trabajo de ejecución de la consulta. Esto incluye la lectura de datos de los índices de instrucción, la realización de combinaciones de varios tipos, el filtrado, la ordenación, etc. La canalización produce una secuencia de soluciones que, a continuación, se convierte de nuevo en una secuencia de objetos de recorrido de TinkerPop.
Serialización de los resultados de las consultas
En la actualidad, Amazon Neptune se basa en los serializadores de mensajes de respuesta de TinkerPop para convertir los resultados de las consultas (recorridos de TinkerPop) en los datos serializados que se van a enviar a través de la red de nuevo al cliente. Estos formatos de serialización suelen ser bastante específicos.
Por ejemplo, para serializar el resultado de una consulta de vértice como g.V().limit(1), el motor de consultas de Neptune debe realizar una única búsqueda para producir el resultado de la consulta. Sin embargo, el serializador de GraphSON realizaría un gran número de búsquedas adicionales para empaquetar el vértice en el formato de serialización. Tendría que realizar una búsqueda para obtener la etiqueta, una para obtener las claves de propiedad y una búsqueda por clave de propiedad para el vértice para obtener todos los valores de cada clave.
Algunos de los formatos de serialización son más eficientes, pero todos requieren búsquedas adicionales. Además, los serializadores de TinkerPop no intentan evitar búsquedas duplicadas, lo que suele dar lugar a que muchas búsquedas se repitan de forma innecesaria.
Esto hace que sea muy importante escribir sus consultas para que soliciten específicamente solo la información que necesitan. Por ejemplo, g.V().limit(1).id() devolvería solo el ID de vértice y eliminaría todas las búsquedas de serializador adicionales. API profile de Gremlin en Neptune le permite ver cuántas llamadas de búsqueda se realizan durante la ejecución de consultas y durante la serialización.
