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.

Pilar de optimización de costos

El pilar de optimización de costes del AWS Well-Architected Framework se centra en evitar costes innecesarios. Las siguientes recomendaciones pueden ser de utilidad para aplicar correctamente los principios de diseño para optimizar los costos y las prácticas recomendadas en materia de arquitectura de Amazon Neptune.

El pilar de optimización de costos se centra en las siguientes áreas clave:

Descripción de patrones de uso y servicios necesarios

Neptune es una buena opción para su carga de trabajo si su modelo de datos tiene una estructura gráfica discernible y sus consultas tienen que explorar relaciones y recorrer varios niveles. Una base de datos de gráficos no es una buena opción para los siguientes patrones:

Piense en si usar un conjunto de varias bases de datos personalizadas para patrones de acceso específicos podría satisfacer todas sus necesidades. Por ejemplo:

Comprenda los costos asociados a los servicios que interactúan con Neptune y lo complementan, como los siguientes:

Selección de recursos en función de los costos

Los precios de Neptune se basan en el costo por hora de la instancia (o las unidades de computación de Neptune que se consumen si no hay servidor), las operaciones de E/S de datos y el uso del almacenamiento. Las instancias representan, de media, el 85 % del costo total, por lo que un dimensionamiento correcto puede tener importantes implicaciones en los costos. La mejor manera de ajustar el tamaño de las instancias es probar el rendimiento de las aplicaciones en varias instancias y comparar los siguientes factores:

Los costos de las instancias se escalan de forma lineal en función del tamaño dentro de la misma familia de instancias. El costo por hora de la instancia db.r6i.2xlarge es el doble que el de la instancia db.r6i.xlarge y también tiene el doble de asignación de recursos. El costo de la instancia db.r6i.24xlarge es 24 veces mayor que el costo por hora de la instancia db.r6i.xlarge.

Calcule la cantidad de consultas simultáneas que debe admitir. Puede tener entre 0 y 15 réplicas de lectura para procesar las consultas de solo lectura. Si sus requisitos varían según la hora del día, la semana o el mes, puede usar varias instancias más pequeñas para escalar según un cronograma. Cada vCPU de una instancia proporciona dos subprocesos para gestionar consultas simultáneas. Tres réplicas de lectura de db.r6i.xlarge, con 4 vCPU cada una, pueden gestionar 24 consultas simultáneas.

Si, por el contrario, el volumen de tráfico se mide en consultas por segundo (QPS), debe experimentar para determinar la latencia media de las consultas. El número de consultas por segundo que admite un clúster de Neptune equivale a vCPU × 2 × (1 second/average query latency). Por ejemplo, si tiene 4 vCPU y una latencia de consulta de 100 milisegundos (0,1 segundos), QPS = 4 × 2 × (1s/0.1s) = 80 queries per second.

Las instancias aprovisionadas son más baratas que las instancias sin servidor para cargas de trabajo continuas, estables y predecibles. La tecnología sin servidor ofrece oportunidades para optimizar los costos cuando se tiene una carga de trabajo que requiere un uso muy elevado durante unas pocas horas al día (por ejemplo, db.r6i.4xlarge), pero después no tenga prácticamente tráfico durante el resto del día (por ejemplo, 1 unidad de computación de Neptune). Una instancia sin servidor que se escale verticalmente durante unas horas y luego se vuelva a reducir será más económica que usar una instancia db.r6i.4xlarge aprovisionada todo el día.

Considere la posibilidad de actualizar a Neptune 1.4.5.0 o una versión posterior y utilizar r8g instancias para lograr un mejor rendimiento de lectura y escritura a un costo menor que las instancias de generaciones anteriores, como o. r7g r6g Para obtener más información, consulte Relación precio-rendimiento de consultas de escritura 4,7 veces mejor con instancias AWS Graviton4 R8g que utilizan Amazon Neptune v1.4.5 (entrada del blog).AWS

Los clústeres de Neptune se crean de forma predeterminada con almacenamiento estándar (si los crea con la consola, se seleccionará de forma predeterminada almacenamiento I/O-optimized storage). With I/O-optimized storage, you pay a slightly higher cost for storage and instances, but there are no I/O costs. This leads to more predictable recurring costs, but if your I/O usage is generally low, it may be more cost efficient to utilize standard storage. If you intend to load a lot of data initially, you can optimize cost by choosing I/O optimizado, se realizará la carga de datos inicial y, a continuación, se cambiará al almacenamiento estándar). El tipo de almacenamiento afecta únicamente al modelo de facturación y no presenta ninguna diferencia técnica en la configuración de instancias o clústeres de base de datos de Neptune. Puede cambiar el tipo de almacenamiento una vez cada 30 días. Transcurridos 30 días, comprueba tus costes detallados de Neptuno y utiliza la página de precios de Neptune para calcular si tus costes habrían sido más altos con -optimized. I/O-optimized storage. If they would have been, continue to use standard storage, otherwise switch back to I/O

Elección de la mejor configuración de instancias de Neptune para su carga de trabajo

Si creaste la tuya Cuenta de AWS antes del 15 de julio de 2025, puedes usar la capa AWS gratuita para experimentar con Neptuno de nivel básico. Las 750 horas gratuitas de uso de las instancias db.t3.medium y db.t4g.medium son suficientes para familiarizarse con el funcionamiento de Neptune a baja escala. El clúster se conservará una vez finalizado el periodo de prueba gratuito, aunque a partir de ese momento se le cobrará por su uso.

Las db.t4g.medium instancias db.t3.medium y son ideales para entornos de desarrollo de bajo coste en los que no utilices OpenCypher, Graph Explorer o varias integraciones generativas de IA. Estas instancias tienen una RAM-to-vCPU proporción menor (2:1) que las instancias familiares (8:1) o las instancias R familiares (16:1). X Esta proporción reducida impide el uso de las estadísticas del motor DFE, que permiten el rendimiento de OpenCypher, las integraciones de GenAI (para informar al LLM del esquema gráfico) y el explorador de gráficos. Los perfiles de rendimiento pueden diferir considerablemente cuando se utilizan instancias T familiares, especialmente en el caso de las cargas de trabajo mencionadas anteriormente. Estos casos también pueden aumentar la incidencia de OutOfMemoryExceptions consultas que recorren una parte importante del gráfico. Para determinar si esta última condición podría verse afectada, compruebe la BufferCacheHitRatio CloudWatch métrica.

Recomendamos encarecidamente no realizar ninguna prueba de rendimiento o carga con instancias T familiares, ya que es posible que se obtengan resultados inconsistentes que no sean indicativos de un entorno de producción.

Las instancias aprovisionadas ofrecen la mejor relación costo-rendimiento cuando la carga de trabajo es bastante estable y predecible. Elija el tamaño de la instancia en función de la simultaneidad de solicitudes requerida y de la complejidad de la consulta. Una mayor simultaneidad requiere más vCPUs. Una mayor complejidad de consulta requiere más RAM. Utilice la MainRequestQueuePendingRequests CloudWatch métrica para determinar el impacto de la primera (un valor superior a cero representa más solicitudes simultáneas de las que se pueden gestionar). Usa la BufferCacheHitRatio CloudWatch métrica para determinar el impacto de la segunda. Una proporción que suela caer por debajo del 99,9 % indica que no hay suficiente RAM para respaldar la parte funcional del gráfico que se está evaluando, lo que se traduce en un intercambio de caché más frecuente. Si la familia de instancias R proporciona suficiente simultaneidad pero no suficiente RAM, considere la posibilidad de probar la X familia de instancias.

Los casos de uso ideales de las instancias sin servidor se describen en la documentación de Neptune. Si no estás seguro de si es lo mejor para ti con aprovisionamiento o sin servidor, y el coste es tu principal preocupación, prueba tu carga de trabajo en el modo sin servidor para determinar el número de unidades NCUs utilizadas y compara el coste de las provisionadas (N hours × hourly provisioned cost) con las aplicaciones sin servidor (). sum of NCUs × hourly cost per NCU Si no sabe cuál es la instancia de aprovisionamiento de tamaño equivalente, una NCU equivale aproximadamente a 2 GB de RAM y la vCPU y las redes asociadas. Si la instancia aprovisionada es de la r6i familia, la proporción es de 1 vCPU por cada 8 GB de RAM, o NCUs 4, junto con la red asociada. La calculadora de precios de Amazon Neptune también proporciona una comparación para ayudarle a decidir la configuración de costes óptima.

Cuando utilice una instancia sin servidor para las instancias principales y de réplica, recuerde que las réplicas de lectura de los niveles de promoción 0 y 1 se escalarán NCUs en función de la instancia de grabación, de modo que se escalarán correctamente en caso de que se produzca una conmutación por error. Establezca los límites de NCU para estas instancias en función de las instancias (de escritura o lectura) que reciban más tráfico.

En entornos en los que no se necesite el clúster las 24 horas del día, los 7 días de la semana, considere la posibilidad de crear scripts que desactiven las instancias de Neptune cuando no estén en uso y las vuelvan a iniciar antes de utilizarlas. Las instancias de Neptune se reiniciarán automáticamente cada 7 días para garantizar que se apliquen las actualizaciones de mantenimiento necesarias. Si tiene la intención de dejar las instancias desactivadas durante periodos prolongados, utilice un script semanal para volver a desactivarlas.

Dimensionamiento adecuado del almacenamiento de datos y transferencia

Las consultas más eficientes (por ejemplo, las consultas que deben tocar menos nodos, bordes y propiedades del gráfico) requieren menos I/O transferencia y, potencialmente, pueden utilizar instancias más pequeñas porque se requiere menos memoria caché de búfer. Utilice el perfil o explique los puntos de conexión del lenguaje de consulta para optimizar la consulta y considere la posibilidad de optimizar el modelo de gráficos para mejorar el rendimiento de la consulta.

Neptune usa la codificación de diccionarios en cadenas grandes, y ese diccionario está optimizado para el rendimiento, no para la eficiencia. Si sus propiedades tienen cadenas JSON grandes BLOBs o que cambian con frecuencia, considere la posibilidad de guardarlas fuera de Neptuno en Amazon S3, Amazon DynamoDB o Amazon DocumentDB, y almacenar solo una referencia dentro del nodo Neptune.

En algunos casos, elegir un tamaño de instancia más grande puede resultar más económico. Si sus I/O costos son muy altos debido a un bajo nivelBufferCacheHitRatio, es posible que un búfer de caché más grande reduzca significativamente ese costo. Esto se debe a que todos los datos cabrían en la memoria caché en lugar de ser intercambiados frecuentemente del almacenamiento e incurrir en la velocidad de I/O transferencia.

Neptune utiliza copy-on-write la clonación. Al clonar para dividir un gráfico en varios fragmentos, puede ser más eficaz no eliminar los datos no deseados del clúster clonado, ya que esto implica la creación de nuevas páginas de datos, lo que aumentará los costos de almacenamiento. Los datos que no hayan cambiado desde antes del evento de clonación existirán en una sola página de datos compartida entre los dos clústeres y solo se cobrará por esa única copia.

No active el índice OSGP ni utilice instancias R5d a menos que haya realizado pruebas para confirmar que suponen una diferencia sustancial en su carga de trabajo. Ambas opciones están diseñadas para situaciones poco frecuentes y pueden aumentar los costos, con unos beneficios mínimos o nulos.