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.
# Prácticas recomendadas: sacar el máximo partido de Neptune
Estas son algunas recomendaciones generales para trabajar con Amazon Neptune. Utilice esta información como referencia para encontrar rápidamente recomendaciones para usar Amazon Neptune y maximizar el rendimiento.
**Contents**
+ [Directrices operativas básicas de Amazon Neptune](best-practices-general-basic.md)
+ [Prácticas recomendadas de seguridad de Amazon Neptune](best-practices-general-security.md)
+ [Evite diferentes clases de instancia en un clúster](best-practices-general-basic.md#best-practices-loader-heterogeneous-instances)
+ [Evite reinicios repetidos durante la carga masiva](best-practices-general-basic.md#best-practices-loader-repeated-restarts)
+ [Habilite el índice OSGP si tiene un gran número de predicados](best-practices-general-basic.md#best-practices-general-predicates)
+ [Evite las transacciones de larga duración siempre que sea posible](best-practices-general-basic.md#best-practices-general-long-running-transactions)
+ [Prácticas recomendadas para utilizar métricas de Neptune](best-practices-general-metrics.md)
+ [Prácticas recomendadas para el ajuste de consultas de Neptune](best-practices-general-basic.md#best-practices-general-tuning)
+ [Equilibrio de carga entre réplicas de lectura](best-practices-general-basic.md#best-practices-general-loadbalance)
+ [Carga más rápida usando una instancia temporal más grande](best-practices-general-basic.md#best-practices-loader-tempinstance)
+ [Cambie el tamaño de la instancia de escritor mediante una conmutación por error a una réplica de lectura](best-practices-general-basic.md#best-practices-resize-instance)
+ [Reintente la carga tras el error de interrupción de la tarea de obtención previa de los datos](best-practices-general-basic.md#load-api-reference-status-interrupted)
+ [Prácticas recomendadas para utilizar Gremlin con Neptune](best-practices-gremlin.md)
+ [Configuración de Heartbeat para Neptune Serverless](best-practices-gremlin-heartbeat-serverless.md)
+ [Estructure las consultas de actualización o inserción para aprovechar el motor DFE](best-practices-gremlin.md#best-practices-gremlin-upserts)
+ [Pruebe el código de Gremlin en el contexto en el que lo va a implementar](best-practices-gremlin-console-glv-differences.md)
+ [Creación de escrituras de Gremlin eficientes de múltiples subprocesos](best-practices-gremlin-multithreaded-writes.md)
+ [Depuración de registros con la propiedad de hora de creación](best-practices-gremlin-prune.md)
+ [Uso del método `datetime( )` para datos de tiempo de Groovy](best-practices-gremlin-datetime.md)
+ [Uso de la fecha y hora nativas para los datos de tiempo de GLV](best-practices-gremlin-datetime-glv.md)
+ [Prácticas recomendadas del uso del cliente Java de Gremlin con Neptune](best-practices-gremlin-java-client.md)
+ [Vuelva a utilizar el objeto del cliente en varios subprocesos](best-practices-gremlin-java-reuse.md)
+ [Cree objetos de cliente Java de Gremlin independientes para puntos de conexión de lectura y escritura](best-practices-gremlin-java-separate.md)
+ [Añada varios puntos de conexión de réplica de lectura a un grupo de conexiones Java de Gremlin](best-practices-gremlin-java-multiple.md)
+ [Cierre el cliente para evitar el límite de conexiones](best-practices-gremlin-java-close-connections.md)
+ [Cree una nueva conexión después de una conmutación por error](best-practices-gremlin-java-new-connection.md)
+ [Establezca `maxInProcessPerConnection` y `maxSimultaneousUsagePerConnection` con el mismo valor.](best-practices-gremlin-java-maxes.md)
+ [Envíe consultas al servidor como bytecode en lugar de como cadenas](best-practices-gremlin-java-bytecode.md)
+ [Consume siempre por completo el iterador ResultSet or devuelto por una consulta](best-practices-gremlin-java-resultset.md)
+ [Añada vértices y bordes de forma masiva por lotes](best-practices-gremlin-java-batch-add.md)
+ [Deshabilitar el almacenamiento en caché de DNS en la máquina virtual de Java](best-practices-gremlin-java-disable-dns-caching.md)
+ [Opcionalmente, establezca tiempos de espera al nivel de consulta](best-practices-gremlin-java-per-query-timeout.md)
+ [Solución de problemas de `java.util.concurrent.TimeoutException`](best-practices-gremlin-java-exceptions-TimeoutException.md)
+ [Prácticas recomendadas de Neptune con openCypher y Bolt](best-practices-opencypher.md)
+ [Cree una nueva conexión después de una conmutación por error](best-practices-opencypher.md#best-practices-opencypher-renew-connection)
+ [Gestión de conexiones para aplicaciones de larga duración](best-practices-opencypher.md#best-practices-opencypher-long-connections)
+ [Manejo de conexiones para AWS Lambda](best-practices-opencypher.md#best-practices-opencypher-lambda-connections)
+ [En las consultas, utilice preferentemente bordes dirigidos en lugar de bidireccionales](best-practices-opencypher-directed-edges.md)
+ [Neptune no admite múltiples consultas simultáneas en una transacción](best-practices-opencypher-multiple-queries.md)
+ [Cierre los objetos del controlador cuando haya terminado](best-practices-opencypher-close-driver.md)
+ [Use modos de transacción explícitos para leer y escribir](best-practices-opencypher-use-explicit-txs.md)
+ [Transacciones de solo lectura](best-practices-opencypher-use-explicit-txs.md#best-practices-opencypher-read-txs)
+ [Transacciones de mutación](best-practices-opencypher-use-explicit-txs.md#best-practices-opencypher-mutation-txs)
+ [Lógica de reintentos para las excepciones](best-practices-opencypher-retry-logic.md)
+ [Establecimiento de varias propiedades a la vez mediante una sola cláusula SET](best-practices-content-0.md)
+ [Uso de la cláusula SET para eliminar varias propiedades a la vez](best-practices-content-0.md#best-practices-content-1)
+ [Uso de consultas parametrizadas](best-practices-content-2.md)
+ [Uso de mapas aplanados en lugar de mapas anidados en la cláusula UNWIND](best-practices-content-3.md)
+ [Inserción de nodos más restrictivos en el lado izquierdo en expresiones de ruta de longitud variable (VLP)](best-practices-content-4.md)
+ [Elusión de comprobaciones de etiquetas de nodos redundantes mediante el uso de nombres de relación granulares](best-practices-content-5.md)
+ [Especificación de etiquetas de borde cuando sea posible](best-practices-content-6.md)
+ [Elusión de la cláusula WITH cuando sea posible](best-practices-content-7.md)
+ [Inserción de filtros restrictivos lo antes posible en la consulta](best-practices-content-8.md)
+ [Comprobación explícita de la existencia de propiedades](best-practices-content-9.md)
+ [Elusión de rutas con nombre (a menos que sea necesario)](best-practices-content-10.md)
+ [Elusión de COLLECT (DISTINCT ())](best-practices-content-11.md)
+ [Preferencia de la función de propiedades sobre la búsqueda de propiedades individuales en la recuperación de todos los valores de las propiedades](best-practices-content-12.md)
+ [Realización de cálculos estáticos fuera de la consulta](best-practices-content-13.md)
+ [Entradas por lotes mediante UNWIND en lugar de instrucciones individuales](best-practices-content-14.md)
+ [Prefiere usar la opción personalizada para el nodo o la relación IDs](best-practices-content-15.md)
+ [Elusión de cálculos \$1id en la consulta](best-practices-content-16.md)
+ [Actualización/fusión de varios nodos](best-practices-merge-multiple-nodes.md)
+ [Prácticas recomendadas de Neptune con SPARQL](best-practices-sparql.md)
+ [Consulta de todos los gráficos con nombre de forma predeterminada](best-practices-sparql-query.md)
+ [Especificación de un gráfico con nombre para la carga](best-practices-sparql-graph.md)
+ [Elegir entre FILTER, FILTER... IN y VALUES en sus consultas](best-practices-sparql-batch.md)
# Directrices operativas básicas de Amazon Neptune
A continuación, se detallan las directrices operativas básicas que debe seguir cuando trabaje con Neptune.
+ Conozca las instancias de base de datos de Neptune para poder dimensionarlas correctamente en función de sus requisitos de rendimiento y casos de uso. Consulte [Clústeres e instancias de base de datos de Amazon Neptune](feature-overview-db-clusters.md).
+ Monitorice el uso de la memoria y de la CPU. Esto le servirá para saber cuándo migrar a una clase de instancia de base de datos con mayor capacidad de memoria o de CPU para conseguir el rendimiento de las consultas que necesita. Puedes configurar Amazon CloudWatch para que te notifique cuando cambien los patrones de uso o cuando te acerques a la capacidad de tu implementación. Si lo hace, le podrá servir para mantener el rendimiento y la disponibilidad del sistema. Consulte [Monitorización de instancias](feature-overview-db-clusters.md#feature-overview-monitoring-instances) y [Monitorización de Neptune](monitoring.md) para obtener más información.
Dado que Neptune tiene su propio administrador de memoria, es normal observar un uso de la memoria relativamente bajo incluso cuando se utiliza mucha CPU. Encontrar out-of-memory excepciones al ejecutar consultas es el mejor indicador de que necesita aumentar la memoria liberable.
+ Habilite las copias de seguridad automatizadas y configure la ventana de copia de seguridad para que se produzca cuando le convenga.
+ Pruebe la conmutación por error de la instancia de base de datos para comprender cuánto tiempo tarda el proceso en su caso de uso. También ayuda a asegurarse de que la aplicación que obtiene acceso a su instancia de base de datos puede conectarse automáticamente a la nueva instancia de base de datos tras una conmutación por error.
+ Si es posible, ejecute el cliente y el clúster de Neptune en la misma región y VPC, ya que las conexiones entre regiones con VPC interconexión pueden producir retrasos en los tiempos de respuesta de las consultas. Para obtener respuestas a consultas en milisegundos de un solo dígito, es necesario mantener el cliente y el clúster de Neptune en la misma región y VPC.
+ Cuando cree una instancia de réplica de lectura, esta debe tener, como mínimo, el mismo tamaño que la instancia de escritor principal. Esto ayudará a mantener el retraso de replicación bajo control y evitará los reinicios de la réplica. Consulte [Evite diferentes clases de instancia en un clúster](#best-practices-loader-heterogeneous-instances).
+ Antes de actualizar a una nueva versión principal del motor, asegúrese de probar la aplicación en ella. Para ello, puede clonar el clúster de base de datos para que el clúster clonado ejecute la nueva versión del motor y, a continuación, probar la aplicación en el clon.
+ Para facilitar la conmutación por error, lo ideal es que todas las instancias tengan el mismo tamaño.
**Topics**
+ [Prácticas recomendadas de seguridad de Amazon Neptune](best-practices-general-security.md)
+ [Evite diferentes clases de instancia en un clúster](#best-practices-loader-heterogeneous-instances)
+ [Evite reinicios repetidos durante la carga masiva](#best-practices-loader-repeated-restarts)
+ [Habilite el índice OSGP si tiene un gran número de predicados](#best-practices-general-predicates)
+ [Evite las transacciones de larga duración siempre que sea posible](#best-practices-general-long-running-transactions)
+ [Prácticas recomendadas para utilizar métricas de Neptune](best-practices-general-metrics.md)
+ [Prácticas recomendadas para el ajuste de consultas de Neptune](#best-practices-general-tuning)
+ [Equilibrio de carga entre réplicas de lectura](#best-practices-general-loadbalance)
+ [Carga más rápida usando una instancia temporal más grande](#best-practices-loader-tempinstance)
+ [Cambie el tamaño de la instancia de escritor mediante una conmutación por error a una réplica de lectura](#best-practices-resize-instance)
+ [Reintente la carga tras el error de interrupción de la tarea de obtención previa de los datos](#load-api-reference-status-interrupted)
# Prácticas recomendadas de seguridad de Amazon Neptune
Utilice cuentas AWS Identity and Access Management (IAM) para controlar el acceso a las acciones de la API de Neptune. Controle las acciones que crean, modifican o eliminan recursos de Neptune (como instancias de bases de datos, grupos de seguridad, grupos de opciones o grupos de parámetros) y las acciones que realizan tareas administrativas frecuentes (como realizar copias de seguridad y restaurar instancias de bases de datos).
+ Utilice credenciales temporales en lugar de persistentes siempre que sea posible.
+ Asigne una cuenta de IAM individual a cada persona que administre recursos de Amazon Relational Database Service (Amazon RDS). Nunca utilice usuarios raíz de AWS cuentas para administrar los recursos de Neptune. Cree un usuario de IAM para todos, incluido usted mismo.
+ Asigne a cada usuario el conjunto mínimo de permisos requerido para realizar sus tareas.
+ Use los grupos de IAM para administrar con eficacia los permisos para varios usuarios.
+ Rote con regularidad sus credenciales de IAM.
Para obtener más información sobre el uso de IAM para acceder a los recursos de Neptune, consulte [Protección de la base de datos de Amazon Neptune](security.md). Para obtener información general sobre cómo trabajar con IAM, consulte [AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/Welcome.html) y [Prácticas recomendadas de seguridad en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAMBestPractices.html) en la *Guía del usuario de IAM*.
## Evite diferentes clases de instancia en un clúster
Cuando el clúster de base de datos contiene instancias de clases diferentes, pueden surgir problemas con el paso del tiempo. El problema más común es que una instancia de lector pequeña puede entrar en un ciclo de reinicios repetidos debido al retardo en la replicación. Si un nodo de lector tiene una configuración de clase de instancia de base de datos más débil que la de una instancia de base de datos de escritor, el volumen de cambios puede ser demasiado grande para que el lector se adapte al ritmo.
**importante**
Para evitar reinicios repetidos a causa del retardo en la replicación, configure el clúster de base de datos de modo que todas las instancias tengan la misma clase (tamaño).
Puede ver el desfase entre la instancia de escritura (la principal) y los lectores de su clúster de base de datos mediante la `ClusterReplicaLag` métrica de Amazon CloudWatch. La métrica `VolumeWriteIOPs` también le permite detectar ráfagas de actividad de escritura en su clúster que pueden provocar un retardo en la replicación.
## Evite reinicios repetidos durante la carga masiva
Si experimenta un ciclo de reinicios repetidos de réplicas de lectura debido a un retardo en la replicación durante una carga masiva, es probable que sus réplicas no puedan mantener el ritmo del escritor en el clúster de base de datos.
Escale los lectores a un tamaño superior al del escritor o quítelos temporalmente durante la carga masiva y vuelva a crearlos una vez finalizada la operación.
## Habilite el índice OSGP si tiene un gran número de predicados
Si su modelo de datos contiene un gran número de predicados distintos (más de mil en la mayoría de los casos), es posible que el rendimiento se reduzca y aumenten los costos operativos.
Si es así, puede mejorar el rendimiento habilitando el [índice OSGP](feature-overview-storage-indexing.md#feature-overview-storage-indexing-osgp). Consulte [El índice OSGP](features-lab-mode.md#features-lab-mode-features-osgp-index).
## Evite las transacciones de larga duración siempre que sea posible
Las transacciones de larga duración, ya sean de solo lectura o de lectura y escritura, pueden provocar problemas inesperados de los siguientes tipos:
Una transacción de larga duración en una instancia de lector o de escritor con escrituras simultáneas puede provocar una gran acumulación de diferentes versiones de los datos. Esto puede dar lugar a latencias más altas en las consultas de lectura que filtran una gran parte de sus resultados.
En algunos casos, las versiones acumuladas a lo largo de varias horas pueden provocar una limitación de las escrituras nuevas.
Una transacción de lectura-escritura de larga duración con muchas escrituras también puede provocar problemas si la instancia se reinicia. Si una instancia se reinicia tras un evento de mantenimiento o un bloqueo, se revierten todas las escrituras no confirmadas. Por lo general, estas operaciones de deshacer se ejecutan en segundo plano y no impiden que la instancia vuelva a funcionar, pero cualquier escritura nueva que entre en conflicto con las operaciones que se están revirtiendo fallará.
Por ejemplo, si se vuelve a intentar la misma consulta después de interrumpir la conexión en la ejecución anterior, es posible que se produzca un error al reiniciar la instancia.
El tiempo necesario para deshacer las operaciones es proporcional al tamaño de los cambios involucrados.
# Prácticas recomendadas para utilizar métricas de Neptune
Para identificar los problemas de rendimiento causados por la falta de recursos y otros cuellos de botella frecuentes, puede monitorizar las métricas disponibles para su clúster de base de datos de Neptune.
Monitorice las métricas de desempeño con frecuencia para recopilar datos sobre los valores medios, máximos y mínimos de diversos intervalos de tiempo. Esto le servirá para identificar cuándo se degrada el rendimiento. Con estos datos, puedes configurar CloudWatch las alarmas de Amazon para determinados umbrales de métricas, de forma que recibas una alerta si se alcanzan.
Cuando se configura un nuevo clúster de base de datos y se ejecuta con una carga de trabajo típica, intente capturar los valores medio, máximo y mínimo de todas las métricas de rendimiento en diversos intervalos (por ejemplo, una hora, 24 horas, una semana, dos semanas). Esto permite hacerse una idea de lo que es normal. Ayuda a obtener comparaciones para las horas con picos y valles de funcionamiento. Puede usar esta información para saber cuándo cae el rendimiento por debajo de los niveles estándar y puede configurar las alarmas según corresponda.
Consulte [Monitorización de Neptune con Amazon CloudWatch](cloudwatch.md) para obtener información acerca de cómo ver las métricas de Neptune.
Las métricas más importantes con las que comenzar son las siguientes:
+ **BufferCacheHitRatio**— El porcentaje de solicitudes que atiende la caché del búfer. Los errores de caché añaden una latencia significativa a la ejecución de las consultas. Si la relación de aciertos de la caché es inferior al 99,9 % y la latencia es un problema para su aplicación, considere la posibilidad de actualizar el tipo de instancia para almacenar en caché más datos en memoria.
+ **Utilización de la CPU**: porcentaje de la capacidad de procesamiento del equipo que está en uso. Unos valores elevados de consumo de CPU podrían ser adecuados, en función de los objetivos de rendimiento de las consultas.
+ **Memoria que se puede liberar**: cuánta RAM está disponible en la instancia de base de datos en megabytes. Neptune tiene su propio administrador de memoria, por lo que esta métrica podría ser inferior a la esperada. Una buena señal de que deberías considerar la posibilidad de actualizar tu clase de instancia a una con más RAM es si las consultas suelen generar out-of-memory excepciones.
La línea roja de las métricas de la pestaña **Monitoring (Monitorización)** está marcada en el 75 % para las métricas de CPU y memoria. Si el consumo de memoria de instancia supera con frecuencia esta línea, significa que debe verificar la carga de trabajo y plantearse actualizar la instancia para mejorar el rendimiento de las consultas.
## Prácticas recomendadas para el ajuste de consultas de Neptune
Una de las formas más eficaces de mejorar el rendimiento de Neptune es ajustar las consultas más utilizadas y que más recursos consumen para que ejecutarlas resulte más económico.
Para obtener información sobre cómo ajustar las consultas de Gremlin, consulte [Sugerencias de consulta de Gremlin](gremlin-query-hints.md) y [Ajuste de las consultas de Gremlin](gremlin-traversal-tuning.md). Para obtener información sobre cómo ajustar las consultas SPARQL, consulte [Sugerencias de consulta SPARQL](sparql-query-hints.md).
## Equilibrio de carga entre réplicas de lectura
El enrutamiento de turnos rotativos para puntos de enlace de lectura funciona mediante el cambio del host al que apunta la entrada DNS. El cliente debe crear una conexión nueva y resolver el registro DNS para poder conectarse a una nueva réplica de lectura, ya que WebSocket las conexiones suelen mantenerse activas durante períodos prolongados.
Para obtener réplicas de lectura diferentes para las solicitudes sucesivas, asegúrese de que el cliente resuelva la entrada DNS cada vez que se conecte. Esto puede requerir cerrar la conexión y volver a conectarse al punto de enlace del lector.
También puede balancear la carga de las solicitudes en réplicas de lectura conectando los puntos de enlace de instancia explícitamente.
## Carga más rápida usando una instancia temporal más grande
Su rendimiento de carga aumenta con tamaños de instancia más grandes. Si no utiliza un tipo de instancia grande, pero desea aumentar la velocidad de carga, puede utilizar una instancia mayor para cargarla y, a continuación, eliminarla.
**nota**
El siguiente procedimiento es para un nuevo clúster. Si tiene un clúster existente, puede agregar una nueva instancia más grande y, a continuación, promoverla a una instancia de base de datos principal.
**Para cargar datos utilizando un tamaño de instancia mayor**
1. Cree un clúster con una sola instancia `r5.12xlarge`. Esta instancia es la instancia de base de datos principal.
1. Cree una o varias réplicas de lectura del mismo tamaño (`r5.12xlarge`).
Puede crear réplicas de lectura más pequeñas, pero si no son lo suficientemente grandes como para soportar las escrituras que realiza la instancia principal, es posible que tengan que reiniciarse con frecuencia. El tiempo de inactividad resultante reduce drásticamente el rendimiento.
1. En el comando de carga masiva, incluya `“parallelism” : “OVERSUBSCRIBE”` para indicarle a Neptune que utilice todos los recursos de CPU disponibles para la carga (consulte [Parámetros de solicitudes del programa de carga de Neptune](load-api-reference-load.md#load-api-reference-load-parameters)). La operación de carga se realizará entonces tan rápido como sea posible, I/O lo que generalmente requiere entre un 60 y un 70% de los recursos de la CPU.
1. Cargue sus datos mediante el programa de carga de Neptune. El trabajo de carga se ejecuta en la instancia de base de datos principal.
1. Cuando terminen de cargarse los datos, asegúrese de escalar verticalmente todas las instancias del clúster al mismo tipo de instancia para evitar cargos adicionales y problemas de reinicio repetidos (consulte [Evite distintos tamaños de instancias](#best-practices-loader-heterogeneous-instances)).
## Cambie el tamaño de la instancia de escritor mediante una conmutación por error a una réplica de lectura
La mejor forma de cambiar el tamaño de una instancia del clúster de base de datos, incluida la instancia de escritor, es crear o modificar una instancia de réplica de lectura para que tenga el tamaño deseado y, a continuación, realizar una conmutación por error deliberada a esa réplica de lectura. El tiempo de inactividad registrado por la aplicación es solo el tiempo necesario para cambiar la dirección IP del escritor, que debería ser de unos 3 a 5 segundos.
La API de administración de Neptune que se utiliza para conmutar por error la instancia de escritor actual a una instancia de réplica de lectura es [FailoverDBCluster](api-clusters.md#FailoverDBCluster) de forma deliberada. Si utiliza el cliente Java de Gremlin, es posible que tenga que crear un nuevo objeto de cliente tras la conmutación por error para seleccionar la nueva dirección IP, tal y como se menciona [aquí](best-practices-gremlin-java-new-connection.md).
Asegúrese de cambiar todas las instancias al mismo tamaño para evitar un ciclo de reinicios repetidos, como se explica a continuación.
## Reintente la carga tras el error de interrupción de la tarea de obtención previa de los datos
Cuando esté cargando datos en Neptune mediante el programa de carga masiva, ocasionalmente puede producirse un estado `LOAD_FAILED`, con los mensajes `PARSING_ERROR` y `Data prefetch task interrupted`, en respuesta a una solicitud de información detallada, como este:
```
"errorLogs" : [
{
"errorCode" : "PARSING_ERROR",
"errorMessage" : "Data prefetch task interrupted: Data prefetch task for 11467 failed",
"fileName" : "s3://amzn-s3-demo-bucket/some-source-file",
"recordNum" : 0
}
]
```
Si detecta este error, solo tiene que reintentar la solicitud de carga masiva.
El error se produce si ha habido una interrupción temporal no provocada normalmente por su solicitud o sus datos y, en general, puede resolverse ejecutando de nuevo la solicitud de carga masiva.
En caso de que esté usando la configuración predeterminada, es decir, `"mode":"AUTO"` y `"failOnError":"TRUE"`, el programa de carga omite los archivos que ya ha cargado correctamente y reanuda la carga de los archivos que aún no había cargado en el momento de la interrupción.
# Prácticas recomendadas para utilizar Gremlin con Neptune
Siga estas recomendaciones cuando utilice el lenguaje de recorrido de gráficos Gremlin con Neptune. Para obtener información sobre el uso de Gremlin con Neptune, consulte [Acceso al gráfico de Neptune con Gremlin](access-graph-gremlin.md).
**importante**
Se realizó un cambio en la TinkerPop versión 3.4.11 que mejora la corrección del procesamiento de las consultas, pero por el momento a veces puede afectar gravemente al rendimiento de las consultas.
Por ejemplo, una consulta de este tipo podría ejecutarse de una forma mucho más lenta:
```
g.V().hasLabel('airport').
order().
by(out().count(),desc).
limit(10).
out()
```
Los vértices situados tras el paso límite ahora se obtienen de forma no óptima debido al cambio de la versión 3.4.11. TinkerPop Para evitarlo, puede modificar la consulta añadiendo el paso barrier() en cualquier punto después de `order().by()`. Por ejemplo:
```
g.V().hasLabel('airport').
order().
by(out().count(),desc).
limit(10).
barrier().
out()
```
TinkerPop [La versión 3.4.11 estaba habilitada en la versión 1.0.5.0 del motor de Neptune.](engine-releases-1.0.5.0.md)
**Topics**
+ [Configuración de Heartbeat para Neptune Serverless](best-practices-gremlin-heartbeat-serverless.md)
+ [Estructure las consultas de actualización o inserción para aprovechar el motor DFE](#best-practices-gremlin-upserts)
+ [Pruebe el código de Gremlin en el contexto en el que lo va a implementar](best-practices-gremlin-console-glv-differences.md)
+ [Creación de escrituras de Gremlin eficientes de múltiples subprocesos](best-practices-gremlin-multithreaded-writes.md)
+ [Depuración de registros con la propiedad de hora de creación](best-practices-gremlin-prune.md)
+ [Uso del método `datetime( )` para datos de tiempo de Groovy](best-practices-gremlin-datetime.md)
+ [Uso de la fecha y hora nativas para los datos de tiempo de GLV](best-practices-gremlin-datetime-glv.md)
# Configuración de Heartbeat para Neptune Serverless
Al utilizar WebSocket clientes Gremlin con Neptune Serverless, debe configurar el intervalo de ping del cliente de forma adecuada para mantener conexiones estables durante los eventos de escalado. El cliente Gremlin utiliza WebSocket las conexiones y envía pings periódicos para comprobar que la conexión está activa. El cliente espera una respuesta del servidor dentro del intervalo de ping. Si el servidor no responde, el cliente cierra automáticamente la conexión.
**Para las instancias **aprovisionadas** por Neptune, recomendamos establecer el intervalo de ping en 5 segundos.** Para los **clústeres Neptune Serverless**, recomendamos establecer el intervalo de ping en al menos **20 segundos** para adaptarse a posibles retrasos durante las operaciones de escalado. Este parámetro controla el tiempo que el cliente espera entre escrituras en el servidor antes de enviar un ping para comprobar que la conexión sigue activa.
La configuración de este parámetro varía en función de la implementación del cliente:
**Configuración del cliente Java**
Para el cliente Java TinkerPop Gremlin, configure el `keepAliveInterval` parámetro:
```
Cluster.Builder builder = Cluster.build()
.addContactPoint(endpoint)
.keepAliveInterval(20000); // Configure ping interval in milliseconds
```
Para obtener más información sobre la configuración del controlador de Java, consulte la documentación de [Java TinkerPop ](https://tinkerpop.apache.org/docs/current/reference/#gremlin-java-configuration).
**Configuración del cliente Go**
Para el cliente Gremlin Go, configure el `KeepAliveInterval` parámetro:
```
rc, err := driver.NewDriverRemoteConnection(endpoint,
func(settings *driver.DriverRemoteConnectionSettings) {
settings.TraversalSource = "g"
settings.AuthInfo = auth
settings.KeepAliveInterval = 20 * time.Second // Configure ping interval
...
})
```
Para obtener más información sobre la configuración del controlador Go, consulte la documentación de [Go TinkerPop ](https://tinkerpop.apache.org/docs/current/reference/#gremlin-go-configuration).
**JavaScriptConfiguración del cliente de /Node.js**
Para el cliente Gremlin de JavaScript /Node.js, configure el `pingInterval` parámetro:
```
const gremlin = require('gremlin');
const DriverRemoteConnection = gremlin.driver.DriverRemoteConnection;
const connection = new DriverRemoteConnection(endpoint, {
traversalSource: 'g',
pingInterval: 20000 // Configure ping interval in milliseconds
});
```
[Para obtener más información sobre la configuración JavaScript del controlador, consulte la JavaScript TinkerPop documentación.](https://tinkerpop.apache.org/docs/current/reference/#gremlin-javascript-configuration)
**Configuración del cliente Python**
Para el cliente Python Gremlin, el intervalo de ping normalmente se gestiona en la capa de transporte. Consulte la documentación específica de implementación del transporte para ver las opciones de configuración:
```
from gremlin_python.driver.driver_remote_connection import DriverRemoteConnection
g = traversal().with_remote(
DriverRemoteConnection('wss://your-neptune-endpoint:your-neptune-port/gremlin','g',
transport_factory=lambda: AiohttpTransport(read_timeout=60,
write_timeout=20,
heartbeat=20, // Configure heartbeat
call_from_event_loop=True,
max_content_length=100*1024*1024,
ssl_options=ssl.create_default_context(Purpose.CLIENT_AUTH))))
```
Para obtener más información sobre la configuración del controlador de Python, consulte la [ TinkerPop documentación de Python](https://tinkerpop.apache.org/docs/current/reference/#gremlin-python-configuration).
Esta configuración garantiza que su cliente mantenga la estabilidad de la conexión durante los eventos de escalado de Neptune Serverless, lo que evita cierres de conexión innecesarios y mejora la confiabilidad de las aplicaciones.
## Estructure las consultas de actualización o inserción para aprovechar el motor DFE
En [Realización de actualizaciones o inserciones eficientes con los pasos `mergeV()` y `mergeE()` de Gremlin](gremlin-efficient-upserts.md), se explica cómo estructurar las consultas de actualización o inserción para utilizar el motor DFE de la forma más eficaz posible.
# Pruebe el código de Gremlin en el contexto en el que lo va a implementar
En Gremlin, los clientes pueden enviar consultas al servidor de varias maneras: mediante Bytecode GLV o mediante WebSocket la consola Gremlin mediante scripts basados en cadenas.
Es importante reconocer que la ejecución de las consultas de Gremlin puede variar según la forma en que se envíe la consulta. Una consulta que devuelve un resultado vacío puede considerarse correcta si se envía en el modo de Bytecode, pero puede considerarse que ha fallado si se envía en el modo de script. Por ejemplo, si incluyes una consulta `next()` en modo script, se envía al servidor, pero al usar el cliente, por lo general, `next()` se procesa por sí misma. ByteCode `next()` En el primer caso, la consulta falla si no se encuentra ningún resultado, pero en el segundo, la consulta se realiza correctamente independientemente de que el conjunto de resultados esté vacío o no.
Si desarrolla y prueba su código en un solo contexto (por ejemplo, la consola de Gremlin, que normalmente envía consultas en forma de texto), pero luego implementa el código en un contexto diferente (por ejemplo, mediante el controlador de Java con Bytecode), podría tener problemas, ya que su código podría comportarse de manera diferente en producción que en su entorno de desarrollo.
**importante**
Asegúrese de probar el código de Gremlin en el contexto de GLV en el que se va a implementar para evitar resultados inesperados.
# Creación de escrituras de Gremlin eficientes de múltiples subprocesos
Hay algunas directrices para la carga con múltiples subprocesos de datos en Neptune mediante Gremlin.
Si fuera posible, asigne a cada hilo un conjunto de vértices o bordes para su inserción o modificación que no colisionen. Por ejemplo, ID de direcciones de hilo 1, rango 1–50 000; ID de direcciones de hilo 2, rango 50 001–100 000, y así sucesivamente. Esto reduce el riesgo de alcanzar un `ConcurrentModificationException`. Para estar seguro, coloque un bloque `try/catch` alrededor de todas las escrituras. Si se produce cualquier error, puede volver a intentarlo después de un breve retraso.
Las operaciones de escritura por lotes en un tamaño de lote entre 50 y 100 (vértices o bordes) generalmente funcionan bien. Si está agregando una gran cantidad de propiedades para cada vértice, un número cercano al 50 en lugar de 100 podría ser una elección más acertada. Merece la pena experimentar. Por lo tanto, para las escrituras por lotes, puede utilizar algo así como esto:
```
g.addV(‘test’).property(id,’1’).as(‘a’).
addV(‘test’).property(id,’2’).
addE(‘friend’).to(‘a’).
```
Esto se repite en cada operación por lotes.
El uso de lotes es bastante más eficiente que la adición de un vértice o borde por cada viaje de ida y vuelta de Gremlin al servidor.
Si está utilizando un cliente de la variante de lenguaje Gremlin (GLV), puede crear un lote mediante programación creando en primer lugar un recorrido. Añádala y, por último, realice una iteración sobre ella. Por ejemplo:
```
t.addV(‘test’).property(id,’1’).as(‘a’)
t.addV(‘test’).property(id,’2’)
t.addE(‘friend’).to(‘a’)
t.iterate()
```
Si es posible, es mejor utilizar el cliente de la variante de lenguaje Gremlin. Sin embargo, puede hacer algo similar con un cliente que envía consultas como cadenas de texto concatenando cadenas para construir un lote.
Si utiliza una de las bibliotecas de clientes Gremlin en lugar de HTTP básicos de las consultas, todos los subprocesos deberán compartir el mismo cliente, clúster o grupo de conexiones. Es posible que tenga que ajustar la configuración para obtener el mejor rendimiento posible; por ejemplo, puede que tenga que ajustar el tamaño del grupo de conexiones y el número de subprocesos de trabajo que utiliza el cliente de Gremlin.
# Depuración de registros con la propiedad de hora de creación
Puede depurar los registros viejos almacenando la hora de creación como una propiedad en los vértices y descartándolos periódicamente.
Si necesita almacenar datos durante un periodo específico y, a continuación, eliminarlos del gráfico (tiempo de vida de vértice), puede almacenar una propiedad de marca temporal en la creación del vértice. A continuación, puede emitir periódicamente una consulta `drop()` para todos los vértices que se crearon antes de una hora determinada; por ejemplo:
```
g.V().has(“timestamp”, lt(datetime('2018-10-11')))
```
# Uso del método `datetime( )` para datos de tiempo de Groovy
Neptune proporciona el método `datetime` para especificar fechas y horas para las consultas enviadas en la variante **Groovy** de Gremlin. Esto incluye la consola de Gremlin, cadenas de texto que utilizan la API REST HTTP y cualquier otra serialización que utilice Groovy.
**importante**
Esto *solo* se aplica a aquellos casos en los que envíe la consulta de Gremlin como una *cadena de texto*. Si utiliza una variante del lenguaje Gremlin, debe usar las clases y funciones de fecha nativas para el lenguaje. Para obtener más información, consulte la siguiente sección, [Uso de la fecha y hora nativas para los datos de tiempo de GLV](best-practices-gremlin-datetime-glv.md).
Empezando por TinkerPop `3.5.2` (introducido en la [versión 1.1.1.0 del motor Neptune](engine-releases-1.1.1.0.md)), `datetime` es una parte integral de. TinkerPop
Puede utilizar el método `datetime` para almacenar y comparar fechas:
```
g.V('3').property('date',datetime('2001-02-08'))
```
```
g.V().has('date',gt(datetime('2000-01-01')))
```
# Uso de la fecha y hora nativas para los datos de tiempo de GLV
Si utiliza una variante del lenguaje Gremlin (GLV), debe usar las clases y funciones de fecha y hora nativas que proporciona el lenguaje de programación para los datos de tiempo de Gremlin.
Las TinkerPop bibliotecas oficiales son todas las bibliotecas de variantes del lenguaje Gremlin.
+ [Go](https://tinkerpop.apache.org/docs/current/reference/#gremlin-go)
+ [Java](https://tinkerpop.apache.org/docs/current/reference/#gremlin-java)
+ [Javascript](https://tinkerpop.apache.org/docs/current/reference/#gremlin-javascript)
+ [.NET](https://tinkerpop.apache.org/docs/current/reference/#gremlin-dotnet)
+ [Python](https://tinkerpop.apache.org/docs/current/reference/#gremlin-python)
**importante**
Esta página solo se aplica a las bibliotecas de la variante de lenguaje Gremlin (GLV). Si utiliza un método en el que envía la consulta de Gremlin como cadena de texto, debe utilizar la función datetime() de Gremlin. Esto incluye la consola de Gremlin, las cadenas de texto que utilizan la API de REST de HTTP o el envío directo de cadenas de Gremlin a través de los controladores.
**Go**
A continuación, se muestra un ejemplo parcial en Go que crea una única propiedad llamada “date” para el vértice con un ID de “3”. Establece el valor como una fecha generada mediante la función time.Now() de Go.
```
import ( "time" )
g.V('3').property('date', time.Now()).next();
```
Para ver un ejemplo completo de conexión a Neptune mediante Go, consulte [Uso de un cliente Go para conectarse a una instancia de base de datos de Neptune](https://docs.aws.amazon.com//neptune/latest/userguide/access-graph-gremlin-go.html).
**Java**
A continuación se muestra un ejemplo parcial en Java que crea una única propiedad llamada "`date`" para el vértice con un ID de "`3`". Define el valor que será una fecha generada utilizando el constructor `Date()` de Java.
```
import java.util.date
g.V('3').property('date', new Date()).next();
```
Para ver un ejemplo completo de cómo conectarse a Neptune mediante Java, consulte [Uso de un cliente Java para conectarse a una instancia de base de datos de Neptune](access-graph-gremlin-java.md).
**Node.js () JavaScript**
El siguiente es un ejemplo parcial en el JavaScript que se crea una propiedad única llamada '`date`' para el vértice con un identificador de '`3`'. Define el valor que será una fecha generada utilizando el constructor `Date()` de Node.js.
```
g.V('3').property('date', new Date()).next()
```
Para ver un ejemplo completo de cómo conectarse a Neptune mediante Node.js, consulte [Uso de Node.js para conectarse a una instancia de base de datos de Neptune](access-graph-gremlin-node-js.md).
**.NET (C\$1)**
A continuación se muestra un ejemplo parcial en C\$1 que crea una única propiedad llamada "`date`" para el vértice con un ID de "`3`". Define el valor que será una fecha generada utilizando la propiedad `DateTime.UtcNow` de .NET.
```
Using System;
g.V('3').property('date', DateTime.UtcNow).next()
```
Para ver un ejemplo completo de cómo conectarse a Neptune mediante C\$1, consulte [Uso de .NET para conectarse a una instancia de base de datos de Neptune](access-graph-gremlin-dotnet.md).
**Python**
A continuación se muestra un ejemplo parcial en Python que crea una única propiedad llamada "`date`" para el vértice con un ID de "`3`". Define el valor que será una fecha generada utilizando el método `datetime.now()` de Python.
```
import datetime
g.V('3').property('date',datetime.datetime.now()).next()
```
Para ver un ejemplo completo de cómo conectarse a Neptune mediante Python, consulte [Uso de Python para conectarse a una instancia de base de datos de Neptune](access-graph-gremlin-python.md).
# Prácticas recomendadas del uso del cliente Java de Gremlin con Neptune
Siga estas recomendaciones cuando utilice el cliente Java Gremlin con Neptune. Estas prácticas recomendadas le ayudan a optimizar el rendimiento, gestionar las conexiones de forma eficaz y evitar los errores habituales al trabajar con el controlador de Java.
Para obtener información sobre la configuración de los intervalos de latidos para Neptune Serverless, consulte. [Configuración de Heartbeat para Neptune Serverless](best-practices-gremlin-heartbeat-serverless.md)
**Topics**
+ [Vuelva a utilizar el objeto del cliente en varios subprocesos](best-practices-gremlin-java-reuse.md)
+ [Cree objetos de cliente Java de Gremlin independientes para puntos de conexión de lectura y escritura](best-practices-gremlin-java-separate.md)
+ [Añada varios puntos de conexión de réplica de lectura a un grupo de conexiones Java de Gremlin](best-practices-gremlin-java-multiple.md)
+ [Cierre el cliente para evitar el límite de conexiones](best-practices-gremlin-java-close-connections.md)
+ [Cree una nueva conexión después de una conmutación por error](best-practices-gremlin-java-new-connection.md)
+ [Establezca `maxInProcessPerConnection` y `maxSimultaneousUsagePerConnection` con el mismo valor.](best-practices-gremlin-java-maxes.md)
+ [Envíe consultas al servidor como bytecode en lugar de como cadenas](best-practices-gremlin-java-bytecode.md)
+ [Consume siempre por completo el iterador ResultSet or devuelto por una consulta](best-practices-gremlin-java-resultset.md)
+ [Añada vértices y bordes de forma masiva por lotes](best-practices-gremlin-java-batch-add.md)
+ [Deshabilitar el almacenamiento en caché de DNS en la máquina virtual de Java](best-practices-gremlin-java-disable-dns-caching.md)
+ [Opcionalmente, establezca tiempos de espera al nivel de consulta](best-practices-gremlin-java-per-query-timeout.md)
+ [Solución de problemas de `java.util.concurrent.TimeoutException`](best-practices-gremlin-java-exceptions-TimeoutException.md)
# Vuelva a utilizar el objeto del cliente en varios subprocesos
Volver a utilizar el mismo objeto de cliente (o `GraphTraversalSource`) en varios subprocesos. Es decir, cree una instancia compartida de una clase `org.apache.tinkerpop.gremlin.driver.Client` en su aplicación, en lugar de hacerlo en cada subproceso. El objeto `Client` es seguro para subprocesos y la sobrecarga para inicializar es considerable.
Esto también se aplica a `GraphTraversalSource`, que crea un objeto `Client` internamente. Por ejemplo, el siguiente código hace que se cree una instancia para un nuevo objeto `Client`:
```
import static org.apache.tinkerpop.gremlin.process.traversal.AnonymousTraversalSource.traversal;
/////
GraphTraversalSource traversal = traversal()
.withRemote(DriverRemoteConnection.using(cluster));
```
# Cree objetos de cliente Java de Gremlin independientes para puntos de conexión de lectura y escritura
Puede aumentar el rendimiento si solo escribe en el punto de enlace del escritor y lee desde uno o más puntos de enlace de solo lectura.
```
Client readerClient = Cluster.build("https://reader-endpoint")
...
.connect()
Client writerClient = Cluster.build("https://writer-endpoint")
...
.connect()
```
# Añada varios puntos de conexión de réplica de lectura a un grupo de conexiones Java de Gremlin
Al crear un objeto `Cluster` de Java de Gremlin, puede utilizar el método `.addContactPoint()` para agregar varias instancias de réplicas de lectura a los puntos de contacto del grupo de conexiones.
```
Cluster.Builder readerBuilder = Cluster.build()
.port(8182)
.minConnectionPoolSize(…)
.maxConnectionPoolSize(…)
………
.addContactPoint("reader-endpoint-1")
.addContactPoint("reader-endpoint-2")
```
# Cierre el cliente para evitar el límite de conexiones
Es importante cerrar el cliente cuando haya terminado con él para garantizar que el servidor cierre las WebSocket conexiones y que se liberen todos los recursos asociados a las conexiones. Esto ocurre automáticamente si cierra el clúster mediante `Cluster.close( )`, ya que `client.close( )` se llama internamente.
Si el cliente no está cerrado correctamente, Neptune finaliza todas las WebSocket conexiones inactivas después de 20 a 25 minutos. Sin embargo, si no cierras WebSocket las conexiones de forma explícita cuando terminas de usarlas y el número de conexiones activas alcanza el [límite de conexiones WebSocket simultáneas](limits.md#limits-websockets), se rechazarán las conexiones adicionales con un código de error HTTP`429`. En ese momento, deberá reiniciar la instancia de Neptune para cerrar las conexiones.
La recomendación de llamar a `cluster.close()` no se aplica a las funciones AWS Lambda de Java. Para obtener más información, consulte [Administración de las conexiones WebSocket de Gremlin en las funciones de AWS Lambda](lambda-functions-websocket-connections.md).
# Cree una nueva conexión después de una conmutación por error
En caso de una conmutación por error, el controlador de Gremlin podría continuar conectándose al escritor antiguo porque el nombre DNS del clúster está resuelto a una dirección IP. Si esto sucede, puede crear un nuevo objeto `Client` después de la conmutación por error.
# Establezca `maxInProcessPerConnection` y `maxSimultaneousUsagePerConnection` con el mismo valor.
`maxInProcessPerConnection`Tanto el parámetro como el `maxSimultaneousUsagePerConnection` parámetro están relacionados con el número máximo de consultas simultáneas que se pueden enviar en una sola WebSocket conexión. Internamente, estos parámetros están correlacionados y la modificación de uno sin el otra podría dar lugar a que un cliente reciba un tiempo de espera al intentar recuperar una conexión desde el grupo de conexión del cliente.
Le recomendamos que mantenga los valores predeterminados mínimo en proceso y de uso simultáneo, y defina `maxInProcessPerConnection` y `maxSimultaneousUsagePerConnection` con el mismo valor.
El valor con el que establecer estos parámetros es una función de complejidad de consulta y el modelo de datos. Un caso de uso en el que la consulta devuelve una gran cantidad de datos requeriría más ancho de banda de conexión por consulta y, por tanto, debería tener unos valores más bajos para los parámetros y un valor más alto para `maxConnectionPoolSize`.
En cambio, en los casos en los que la consulta devuelve una menor cantidad de datos, `maxInProcessPerConnection` y `maxSimultaneousUsagePerConnection` deben establecerse en un valor más alto que `maxConnectionPoolSize`.
# Envíe consultas al servidor como bytecode en lugar de como cadenas
Existen ventajas con el uso Bytecode en lugar de una cadena al enviar consultas:
+ **Detección temprana de sintaxis de consultas no válida:** el uso de la variante Bytecode permite detectar la sintaxis de consultas no válidas en la fase de compilación. Si utiliza la variación basada en cadena, no detectará la sintaxis no válida hasta que la consulta se envíe al servidor y se devuelva un error.
+ **Evite las penalizaciones de rendimiento basadas en cadenas:** [cualquier consulta basada en cadenas, ya sea que utilice HTTP WebSockets o HTTP, da como resultado un vértice separado, lo que implica que el objeto Vertex está formado por el identificador, la etiqueta y todas las propiedades asociadas al vértice (consulte Propiedades de los elementos).](http://tinkerpop.apache.org/docs/current/reference/#_properties_of_elements)
Esto puede dar lugar a cálculos innecesarios en el servidor en casos en que las propiedades no son obligatorias. Por ejemplo, si el cliente está interesado en obtener el vértice con el ID "hakuna\$11" utilizando la consulta `g.V("hakuna#1")`. Si la consulta se envía como envío basado en cadena, el servidor gastaría tiempo en recuperar el ID, la etiqueta y todas las propiedades de este vértice. Si la consulta se envía como un envío de Bytecode, el servidor solo dedica tiempo en recuperar el ID y la etiqueta del vértice.
En otras palabras, en lugar de enviar una consulta de esta manera:
```
final Cluster cluster = Cluster.build("localhost")
.port(8182)
.maxInProcessPerConnection(32)
.maxSimultaneousUsagePerConnection(32)
.serializer(Serializers.GRAPHBINARY_V1D0)
.create();
try {
final Client client = cluster.connect();
List results = client.submit("g.V().has('name','pumba').out('friendOf').id()").all().get();
System.out.println(verticesWithNamePumba);
} finally {
cluster.close();
}
```
Envíe la consulta mediante Bytecode, tal y como se muestra a continuación:
```
final Cluster cluster = Cluster.build("localhost")
.port(8182)
.maxInProcessPerConnection(32)
.maxSimultaneousUsagePerConnection(32)
.serializer(Serializers.GRAPHBINARY_V1D0)
.create();
try {
final GraphTraversalSource g = traversal().withRemote(DriverRemoteConnection.using(cluster));
List