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.

• 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. Puede configurar Amazon CloudWatch para notificar cuándo cambian los patrones de uso o cuándo se está llegando al límite de capacidad de la implementación. Si lo hace, le podrá servir para mantener el rendimiento y la disponibilidad del sistema. Consulte Monitorización de instancias y Monitorización de Neptune 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. Encontrarse con excepciones de memoria insuficiente al ejecutar las consultas es el mejor indicador de que necesita aumentar la memoria que se puede liberar.

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

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

Prácticas recomendadas de seguridad de Amazon Neptune

Utilice cuentas de 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 cuentas de AWS 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 Seguridad en Amazon Neptune. Para obtener información general sobre cómo trabajar con IAM, consulte AWS Identity and Access Management y Prácticas recomendadas de seguridad en IAM 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 retardo entre la instancia de escritor (la principal) y los lectores de su clúster de base de datos mediante la métrica ClusterReplicaLag 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. Consulte El índice OSGP.

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, también puede definir alarmas de Amazon CloudWatch para recibir alertas cuando se alcancen umbrales de métricas concretos.

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 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: porcentaje de solicitudes que se responden desde 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ía plantearse la actualización de la clase de instancia a una con más RAM es si las consultas suelen lanzar con frecuencia excepciones de memoria insuficiente.

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 y Ajuste de las consultas de Gremlin. Para obtener información sobre cómo ajustar las consultas SPARQL, consulte Sugerencias de consulta SPARQL.

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 nueva conexión y resolver el registro DNS para obtener una conexión a una nueva réplica de lectura, ya que las conexiones WebSocket a menudo se mantienen activas durante largos períodos.

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.

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

3. 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). En ese caso, la operación de carga se realizará tan rápido como lo permita la E/S, lo que generalmente requiere entre un 60 y un 70 % de los recursos de la CPU.

4. Cargue sus datos mediante el programa de carga de Neptune. El trabajo de carga se ejecuta en la instancia de base de datos principal.

5. 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).

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

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://some-source-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.