Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
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 nombradas, que se pueden usar para recrear un TinkerPopTraverser
El primer paso en el procesamiento de consultas de Gremlin consiste en analizar la consulta para convertirla en un objeto TinkerPop transversal, compuesto por una serie.V() se representa y ejecuta a la vez mediante. TinkerPop GraphStep
Como estos off-the-shelf TinkerPop pasos son ejecutables, un TinkerPop Traversal de este tipo puede ejecutar cualquier consulta de Gremlin y producir la respuesta correcta. Sin embargo, cuando se ejecuta con un gráfico grande, TinkerPop los pasos 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. Pero cuando se encuentra un paso que no se puede convertir, Neptune interrumpe la ejecución nativa y aplaza toda la ejecución de consultas desde ese punto hasta los pasos. 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 un flujo de soluciones que luego se convierte de nuevo en un flujo de objetos de TinkerPop Traverser.
Serialización de los resultados de las consultas
Actualmente, Amazon Neptune utiliza los serializadores de mensajes de TinkerPop respuesta para convertir los resultados de las consultas (TinkerPop Traversers) en datos serializados que se enviarán por cable 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 TinkerPop serializadores no intentan evitar la duplicación de búsquedas, lo que suele provocar que muchas búsquedas se repitan innecesariamente.
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. Gremlin en Neptune profile API le permite ver cuántas llamadas de búsqueda se realizan durante la ejecución de consultas y durante la serialización.
