Directrices operativas básicas de Amazon Neptune - Amazon Neptune
Evite distintos tamaños de instanciasEvite reinicios durante la carga masivaSi tiene muchos predicadosEvite las transacciones de larga duraciónAjuste de consultasEquilibrio de cargaUtilice una instancia temporalRedimensionamiento de una instanciaError de interrupción de la tarea

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.

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.

  • Supervisa tu uso CPU y el de la memoria. Esto le ayuda a saber cuándo debe migrar a una clase de instancia de base de datos con mayor CPU capacidad de memoria para lograr el rendimiento de consulta 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 y Monitorización de Neptune para obtener más información.

    Como Neptune tiene su propio administrador de memoria, es normal ver un uso de memoria relativamente bajo incluso cuando el CPU uso es alto. Encontrar out-of-memory excepciones al ejecutar consultas es el mejor indicador de que se 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ónVPC, ya que las conexiones entre regiones con interconexión pueden provocar retrasos en VPC los tiempos de respuesta a las consultas. Para las respuestas a consultas de 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.

Temas

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 OSGP índice 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 este es el caso, puede mejorar el rendimiento activando el OSGPíndice. 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 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 SPARQL las consultas, consulteSPARQLsugerencias de consulta.

Equilibrio de carga entre réplicas de lectura

El enrutamiento por turnos de los terminales del lector funciona cambiando el host al que apunta la DNS entrada. El cliente debe crear una nueva conexión y resolver el DNS registro 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 solicitudes sucesivas, asegúrese de que el cliente resuelva la DNS entrada 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 bulk loader, “parallelism” : “OVERSUBSCRIBE” inclúyalo para decirle a Neptune que utilice todos los CPU recursos disponibles para cargar (consulteParámetros de solicitudes del programa de carga de Neptune). La operación de carga se realizará entonces tan rápido como lo permita la E/S, lo que generalmente requiere entre un 60 y un 70% de los recursos. 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 administración de Neptune API que se utiliza para conmutar por error la instancia de escritura actual a una instancia de réplica de lectura es deliberadamente. FailoverDBCluster 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.