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.
# Descripción de cómo funcionan las consultas de Gremlin en Neptune
Para sacar el máximo partido de los informes `explain` y `profile` de Gremlin en Amazon Neptune, es útil tener información general sobre las consultas de Gremlin.
**Topics**
+ [Instrucciones de Gremlin en Neptune](gremlin-explain-background-statements.md)
+ [Cómo procesa Neptune las consultas de Gremlin mediante índices de instrucción](gremlin-explain-background-indexing-examples.md)
+ [Cómo se procesan las consultas de Gremlin en Neptune](gremlin-explain-background-querying.md)
# Instrucciones de Gremlin en Neptune
Los datos de gráficos de propiedades en Amazon Neptune se componen de instrucciones de cuatro posiciones (cuádruples). Cada una de estas instrucciones representa una unidad atómica individual de datos de gráficos de propiedades. Para obtener más información, consulte [Modelo de datos de gráficos de Neptune.](feature-overview-data-model.md). Al igual que el modelo de datos del marco de descripción de recursos (RDF), estas cuatro posiciones son las siguientes:
+ `subject (S)`
+ `predicate (P)`
+ `object (O)`
+ `graph (G)`
Cada instrucción es una afirmación sobre uno o varios recursos. Por ejemplo, una instrucción puede afirmar la existencia de una relación entre dos recursos o puede asociar una propiedad (par clave/valor) a algún recurso.
Puede considerar el predicado como el verbo de la instrucción, que describe el tipo de relación o propiedad. El objeto es el objetivo de la relación o el valor de la propiedad. La posición del gráfico es opcional y se puede utilizar de muchas maneras diferentes. En el caso de los datos de gráficos-propiedades (PG) de Neptune, o bien no se usan (gráfico nulo) o se utilizan para representar el identificador de un borde. Un conjunto de instrucciones con identificadores de recursos compartidos crea un gráfico.
Existen tres clases de instrucciones en el modelo de datos de gráficos de propiedades de Neptune:
**Topics**
+ [Instrucciones de etiqueta de vértice](#gremlin-explain-background-vertex-labels)
+ [Instrucciones de borde](#gremlin-explain-background-edge-statements)
+ [Instrucciones de propiedades](#gremlin-explain-background-property-statements)
## Instrucciones de etiqueta de vértice de Gremlin
Las instrucciones de etiqueta de vértice en Neptune sirven para dos fines:
+ Realizan un seguimiento de las etiquetas de un vértice.
+ La presencia de al menos una de estas instrucciones es lo que implica la existencia de un vértice determinado en el gráfico.
El asunto de estas instrucciones es un identificador de vértice y el objeto es una etiqueta que especifica el usuario. Puede utilizar un predicado fijo especial para estas instrucciones, que se muestra como `<~label>`, y un identificador de gráfico predeterminado (el gráfico nulo), que se muestra como `<~>`.
Por ejemplo, fíjese en el siguiente recorrido de `addV`.
```
g.addV("Person").property(id, "v1")
```
Este recorrido hace que se añada la siguiente instrucción al gráfico.
```
StatementEvent[Added( <~label> <~>) .]
```
## Instrucciones de borde de Gremlin
Una instrucción de borde de Gremlin es lo que implica la existencia de un límite entre dos vértices en un gráfico en Neptune. El asunto (S) de una instrucción de borde es el vértice `from` de origen. El predicado (P) es una etiqueta de borde proporcionada por el usuario. El objeto (O) es el vértice `to` de destino. El gráfico (G) es un identificador de borde proporcionado por el usuario.
Por ejemplo, fíjese en el siguiente recorrido de `addE`.
```
g.addE("knows").from(V("v1")).to(V("v2")).property(id, "e1")
```
El recorrido hace que se añada la siguiente instrucción al gráfico.
```
StatementEvent[Added( ) .]
```
## Instrucciones de propiedades de Gremlin
Una instrucción de propiedad de Gremlin en Neptune confirma un valor de propiedad individual para un vértice o borde. El asunto es un vértice o un identificador de borde proporcionado por el usuario. El predicado es el nombre de la propiedad (clave) y el objeto es el valor de la propiedad individual. El gráfico (G) es de nuevo el identificador de gráfico predeterminado, el gráfico nulo, que se muestra como `<~>`.
Considere el siguiente ejemplo de propiedad de vértice.
```
g.V("v1").property("name", "John")
```
Esta instrucción da como resultado lo siguiente.
```
StatementEvent[Added( "John" <~>) .]
```
Las instrucciones de propiedad difieren de otras en que su objeto es un valor primitivo (`string`, `date`, `byte`, `short`, `int`, `long`, `float` o `double`). Su objeto no es un identificador de recursos que pueda utilizarse como sujeto de otra afirmación.
Para varias propiedades, cada valor de propiedad individual del conjunto recibe su propia instrucción.
```
g.V("v1").property(set, "phone", "956-424-2563").property(set, "phone", "956-354-3692 (tel:9563543692)")
```
Se obtiene el siguiente resultado:
```
StatementEvent[Added( "956-424-2563" <~>) .]
StatementEvent[Added( "956-354-3692" <~>) .]
```
Las propiedades de arista se gestionan de forma similar a las de los vértices, pero utilizan el identificador de arista en la posición (S). Por ejemplo, añadir una propiedad a un borde:
```
g.E("e1").property("weight", 0.8)
```
Esto da como resultado que se añada la siguiente declaración al gráfico.
```
StatementEvent[Added( 0.8 <~>) .]
```
# Cómo procesa Neptune las consultas de Gremlin mediante índices de instrucción
Para acceder a las instrucciones en Amazon Neptune, se utilizan tres índices de instrucción, tal y como se detalla en [Cómo se indexan las instrucciones en Neptune](feature-overview-storage-indexing.md). Neptune extrae un *patrón* de instrucciones de una consulta de Gremlin en el que se conocen algunas posiciones y el resto se deja para que se descubran mediante una búsqueda de índices.
Neptune asume que el tamaño del esquema de gráfico de propiedades no es grande. Esto significa que el número de etiquetas de borde y nombres de propiedades distintos es bastante bajo, lo que genera un número total bajo de predicados distintos. Neptune realiza un seguimiento de los predicados distintos en un índice independiente. Utiliza esta caché de predicados para realizar un análisis de unión de `{ all P x POGS }` en lugar de utilizar un índice de OSGP. Evitar la necesidad de un índice de OSGP de recorrido inverso ahorra espacio de almacenamiento y rendimiento de carga.
La Explain/Profile API Neptune Gremlin le permite obtener el recuento de predicados en su gráfico. A continuación, puede determinar si la aplicación invalida la suposición de Neptune de que el esquema de gráficos de propiedades es pequeño.
Los siguientes ejemplos ayudan a demostrar cómo utiliza Neptune los índices para procesar consultas de Gremlin.
**Pregunta: ¿Cuáles son las etiquetas del vértice `v1`?**
```
Gremlin code: g.V('v1').label()
Pattern: (, <~label>, ?, ?)
Known positions: SP
Lookup positions: OG
Index: SPOG
Key range: :<~label>:*
```
**Pregunta: ¿Cuáles son los bordes de tipo "knows" (conoce) del vértice `v1`?**
```
Gremlin code: g.V('v1').out('knows')
Pattern: (, , ?, ?)
Known positions: SP
Lookup positions: OG
Index: SPOG
Key range: ::*
```
**Pregunta: ¿Qué vértices tienen una etiqueta de vértice de `Person`?**
```
Gremlin code: g.V().hasLabel('Person')
Pattern: (?, <~label>, , <~>)
Known positions: POG
Lookup positions: S
Index: POGS
Key range: <~label>::<~>:*
```
**Pregunta: ¿Cuáles son los from/to vértices de una arista determinada? `e1`**
```
Gremlin code: g.E('e1').bothV()
Pattern: (?, ?, ?, )
Known positions: G
Lookup positions: SPO
Index: GPSO
Key range: :*
```
Un índice de instrucción que **no** tiene Neptune es un índice OSGP de recorrido inverso. Este índice podría utilizarse para reunir todos los bordes entrantes de todas las etiquetas de borde, como en el siguiente ejemplo.
**Pregunta: ¿Cuáles son los vértices `v1` adyacentes entrantes?**
```
Gremlin code: g.V('v1').in()
Pattern: (?, ?, , ?)
Known positions: O
Lookup positions: SPG
Index: OSGP // <-- Index does not exist
```
# 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=, , ?2, ?) X Pattern(?2, , ?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](http://tinkerpop.apache.org/docs/current/reference/#_the_traverser) (incluida la información de la ruta).
```
```
[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](http://tinkerpop.apache.org/docs/current/reference/#traversal) de pasos. TinkerPop ](http://tinkerpop.apache.org/docs/current/reference/#graph-traversal-steps) Estos pasos, que forman parte del [ TinkerPop proyecto Apache](http://tinkerpop.apache.org/) de código abierto, son los operadores lógicos y físicos que componen un recorrido de Gremlin en la implementación de referencia. Ambos se utilizan para representar el modelo de la consulta. Son operadores ejecutables que pueden producir soluciones de acuerdo con la semántica del operador que representan. Por ejemplo, `.V()` está representado y ejecutado a la vez por. TinkerPop [GraphStep](http://tinkerpop.apache.org/docs/current/reference/#graph-step)
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. 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 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. [API `profile` de Gremlin en Neptune](gremlin-profile-api.md) le permite ver cuántas llamadas de búsqueda se realizan durante la ejecución de consultas y durante la serialización.