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.

Mejores prácticas operativas para ISVs

Muchas de las pautas de esta sección son prácticas recomendadas para todos los clientes, pero también tienen una importancia adicional para ellos. ISVs

Actualiza tu cúmulo de Neptune con las versiones más recientes

En las notas de la versión de Amazon Neptune, puede ver que cada versión incluye una serie de correcciones de errores, mejoras de rendimiento y nuevas funciones. Mantenga sus cúmulos de Neptune en la última versión tanto como sea posible.

Si encuentra un error no descubierto anteriormente en su carga de trabajo y su clúster tiene la última versión, los ingenieros de Neptune pueden crear un parche privado para su clúster (si lo desea y lo justifica). El parche puede funcionar hasta la próxima versión, cuando la corrección esté disponible para el público en general. Para ayudarte a actualizar tus clústeres a la versión más reciente, usa la solución Neptune Azul/Green.

Use deltas en lugar de eliminar y reemplazar para la ingesta de datos

Puede utilizar varias técnicas para ingerir o escribir datos en Neptune. Muchos clientes intentan simplificar la ingesta de datos borrando y volviendo a insertar su gráfico cada vez que reciben un cambio en el feed. Pueden añadir una last-modified propiedad a cada nodo y buscar periódicamente los nodos que no se hayan modificado desde una fecha específica y eliminarlos. Si bien estas técnicas simplifican el proceso de ingesta de datos, tienen implicaciones de escalabilidad y salud a largo plazo para su clúster de Neptune.

En primer lugar, Neptune usa la codificación de cadenas en un diccionario. A menos que especifique explícitamente IDs los nodos y los bordes, Neptune genera un GUID representado como una cadena para el ID y almacena esa cadena en el diccionario. Si borras y añades objetos constantemente, los que se generen automáticamente IDs provocarán una sobrecarga en el diccionario.

En segundo lugar, Neptune escala hasta ingerir unos 120 K de objetos por segundo como máximo. Si eliminas y añades objetos de forma continua, consumirás gran parte de ese ancho de banda en objetos que, en esencia, no cambian. Esto limita el número de inquilinos que puede alojar en un clúster, requiere instancias de escritura más grandes en los clústeres y requiere más I/O operaciones. Todos estos factores aumentan sus costos.

Le recomendamos encarecidamente que desarrolle una forma de calcular el delta real de lo que ha cambiado en lugar de utilizar los métodos de eliminar y añadir. Sin embargo, algunas fuentes de datos no lo permiten (por ejemplo, las llamadas a la API que devuelven el estado actual o los eventos que no registran exactamente lo que ha cambiado). Si la fuente de datos sin procesar no permite identificar los cambios, utilice los procesos de extracción, transformación y carga (ETL) para calcular el delta. Por ejemplo, puede mantener las instantáneas de cada captura de datos anterior en formato Parquet, utilizarlas AWS Glue para calcular las diferencias entre esas instantáneas y enviar solo las diferencias a Neptune.

Demuestre cómo evolucionarán los costos de Neptune con sus inquilinos

Ya sea que utilice un silo, una piscina o un modelo híbrido, los costes de la nube se ampliarán en función del tamaño de sus inquilinos. Los inquilinos que requieren más conexiones simultáneas necesitan instancias más grandes o más réplicas de lectura que aquellos con menos conexiones simultáneas. Lo mismo se aplica a los inquilinos que requieren una ingesta de datos más rápida.

Los tres componentes del costo del clúster de Neptune son el tamaño (y el número) de la instancia, el tamaño de los datos (GB-mes) y I/O las operaciones (por millón). Si bien estos costos suelen ser específicos de la carga de trabajo, aumentan según el tamaño y el volumen de datos, y se pueden medir mediante el uso de herramientas. AWS Realice un seguimiento y comprenda las economías de escala comparándolas con los indicadores clave del tamaño de sus inquilinos, incluida la forma en que varían sus tamaños a lo largo del tiempo. Si la imprevisibilidad de sus I/O cargos afecta sus márgenes, considere la posibilidad de elegir el almacenamiento optimizado para E/S de Neptune por un costo más predecible.

Amplíe sus clústeres según la demanda de los clientes

No existe una fórmula probada o verdadera para ajustar el tamaño de la instancia de Neptune. La documentación de Neptune proporciona orientación, pero hay demasiadas variables como para recomendar un mapeo directo. Estas variables incluyen, entre otras, las siguientes:

Planifique las pruebas para determinar el tamaño óptimo para sus cargas de trabajo y perfiles de inquilinos. En general, recomendamos usar instancias aprovisionadas para lograr una mayor rentabilidad y previsibilidad. Si sus objetivos de experiencia de cliente dan prioridad a un escalado óptimo por encima de los costes, considere la posibilidad de utilizar instancias Neptune Serverless para garantizar una experiencia más coherente, independientemente de las fluctuaciones de la carga de trabajo.

Si las cargas de trabajo de lectura de su inquilino tienen una variabilidad significativa en sus picos y mínimos, combine las instancias Neptune Serverless con el autoscaling de Neptune.  Por lo general, una nueva réplica de lectura tarda entre 10 y 15 minutos en ponerse en línea una vez inicializada. Esto significa que el autoscalamiento por sí solo puede gestionar cambios prolongados en el tráfico, pero no es suficiente para los picos de actividad que cambian rápidamente. Al combinar Neptune Serverless y el autoscalado de Neptune, puede escalar las instancias hacia arriba o hacia abajo y escalar el número de réplicas de lectura entrantes y salientes.

Si sus inquilinos tienen perfiles de carga de trabajo o acuerdos de nivel de servicio muy diferentes (SLAs), considere la posibilidad de utilizar terminales personalizados y réplicas de lectura dedicadas para dirigir el tráfico a las instancias que estén optimizadas para ese tráfico. La optimización puede incluir un tamaño diferente de la instancia, patrones de consulta específicos o precalentar la caché del búfer.