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 eficiencia de rendimiento

El pilar de eficiencia del rendimiento del AWS Well-Architected Framework se centra en cómo optimizar el rendimiento al ingerir o consultar datos. La optimización del rendimiento es un proceso gradual y continuo que consiste en lo siguiente:

El pilar de eficiencia del rendimiento proporciona pautas específicas para cada caso de uso que pueden ayudar a identificar el modelo de datos de gráficos y los lenguajes de consulta correctos que se deben utilizar. También incluye las prácticas recomendadas que se deben seguir al incorporar datos a Amazon Neptune, así como también al consumirlos.

El pilar de eficiencia del rendimiento se centra en las siguientes áreas clave:

Explicación del modelado de gráficos

Comprenda la diferencia entre los modelos Gráficos de propiedades etiquetadas (LPG) y Marco de descripción de recursos (RDF). En la mayoría de los casos, es una cuestión de preferencias. Sin embargo, hay varios casos de uso en los que un modelo es más adecuado que el otro. Si necesita conocer la ruta que conecta dos nodos de su gráfico, elija LPG. Si desea federar datos entre clústeres de Neptune u otros almacenes triples de gráficos, elija RDF.

Si está creando una aplicación de software como servicio (SaaS) o una aplicación que requiere tenencia múltiple, considere la posibilidad de incorporar la separación lógica de los inquilinos en su modelo de datos en lugar de tener un inquilino para cada clúster. Para lograr ese tipo de diseño, puede utilizar gráficos con nombres y estrategias de etiquetado de SPARQL, como anteponer los identificadores de los clientes a las etiquetas o agregar pares clave-valor de la propiedad que representen los identificadores de los inquilinos. Asegúrese de que su capa de clientes incorpore estos valores para mantener esa separación lógica. Para obtener más información sobre las recomendaciones de tenencia múltiple, consulte la guía de tenencia múltiple para ejecutar bases de datos de Amazon ISVs Neptune.

El rendimiento de las consultas depende de la cantidad de objetos del gráfico (nodos, aristas y propiedades) que deben evaluarse al procesar la consulta. Por lo tanto, el modelo de gráficos puede repercutir en el rendimiento de la aplicación de manera significativa. Utilice etiquetas granulares siempre que sea posible y almacene solo las propiedades que necesite para determinar la ruta o filtrar. Para lograr un mayor rendimiento, considere la posibilidad de calcular previamente partes del gráfico (por ejemplo, cree nodos de resumen o aristas más directas que conecten rutas comunes).

Intente evitar navegar por nodos que tengan un número anormalmente alto de aristas con la misma etiqueta. Estos nodos suelen tener miles de aristas (mientras que la mayoría de los nodos tienen decenas). El resultado es una complejidad computacional y de datos mucho mayor. Es posible que estos nodos no sean problemáticos en algunos patrones de consulta, pero recomendamos modelar los datos de forma diferente para evitarlos, especialmente si va a navegar por el nodo como paso intermedio. Puede usar registros de consultas lentas para identificar las consultas que navegan por estos nodos. Es probable que observe métricas de latencia y acceso a los datos mucho más altas que los patrones de consulta habituales, especialmente si utiliza el modo de depuración.

Utilice un nodo determinista IDs para los nodos y las aristas si su caso de uso lo admite en lugar de utilizar Neptune para asignar valores GUID aleatorios. IDs Acceder a los nodos por ID es el método más eficaz.

Optimización de consultas

Los lenguajes openCypher y Gremlin se pueden usar indistintamente en los modelos GLP. Si el rendimiento es una de las principales preocupaciones, considere la posibilidad de utilizar los dos lenguajes indistintamente, ya que uno podría funcionar mejor que el otro para patrones de consulta específicos.

Neptune está en proceso de conversión a su motor de consultas alternativo (DFE). OpenCypher solo funciona en DFE, pero las consultas de Gremlin y SPARQL se pueden configurar opcionalmente para que funcionen en DFE mediante anotaciones de consulta. Considere la posibilidad de probar las consultas con DFE activado y comparar el rendimiento del patrón de consulta cuando no utilice DFE.

Neptune está optimizado para consultas de tipo transaccional que comienzan en un solo nodo o conjunto de nodos y se despliegan desde allí, en lugar de consultas analíticas que evalúan todo el gráfico. Para sus cargas de trabajo de consultas analíticas, utilice Neptune Analytics. Neptune Analytics es una opción ideal para cargas de trabajo de investigación, exploración o ciencia de datos que requieren una iteración rápida para el procesamiento de datos, analítico y algorítmico. También puede realizar una búsqueda vectorial en datos de gráficos y cargar datos directamente desde la instancia de base de datos de Neptune. Si Neptune Analytics no satisface sus necesidades, también puede considerar el uso de AWS SDK para Pandas o utilizar neptune-export en combinación con Amazon EMR. AWS Glue

Para identificar las ineficiencias y los cuellos de botella en sus modelos y consultas, utilice el y explain APIs para cada lenguaje de consulta a fin de obtener profile explicaciones detalladas del plan de consulta y las métricas de consulta. Para obtener más información, consulte Gremlin profile, openCypher explain y SPARQL explain.

Comprenda los patrones de consulta. La estrategia de acceso predeterminada de Neptune puede ser ineficiente si el número de aristas diferentes de un gráfico se vuelve grande. Las siguientes consultas pueden resultar bastante ineficientes:

Utilice el registro de consultas lentas para identificar las consultas lentas. La lentitud de las consultas puede deberse a planes de consultas no optimizados o a un número innecesariamente elevado de búsquedas en los índices, lo que puede aumentar los costes. I/O Los puntos de conexión de Neptune explain y profile para Gremlin, SPARQL u openCypher pueden ser útiles para comprender por qué estas consultas son lentas. Algunas causas pueden ser las siguientes:

Si la optimización de consultas por sí sola no le permite alcanzar sus requisitos de rendimiento, puede utilizar diversas técnicas de almacenamiento en caché con Neptune para cumplir esos requisitos.

El rendimiento de Neptune mejora continuamente con cada versión. Revisa las notas de la versión para ver los detalles de las mejoras de cada versión. Considere la posibilidad de planificar actualizaciones periódicas de su clúster de base de datos Neptune para lograr un rendimiento óptimo. Las versiones más recientes también admiten instancias más recientes. Considere la posibilidad de actualizar a la versión 1.4.5.0 o una versión posterior para poder utilizar las r8g instancias. Para obtener más información sobre cómo esto puede mejorar el rendimiento de la carga de trabajo, consulte una relación precio-rendimiento de consultas de escritura 4,7 veces mejor con las instancias AWS Graviton4 R8g que utilizan Amazon Neptune v1.4.5.

Dimensionamiento correcto de clústeres

Ajuste el tamaño del clúster a sus requisitos de simultaneidad y rendimiento. La cantidad de consultas simultáneas que puede gestionar cada instancia del clúster es igual a dos veces la cantidad de consultas virtuales (v) de esa instancia. CPUs CPUs Las consultas adicionales que llegan mientras todos los subprocesos de trabajo están ocupados se colocan en una fila del servidor. Esas consultas se gestionan de forma first-in-first-out FIFO cuando los subprocesos de trabajo están disponibles. La CloudWatch métrica de MainRequestQueuePendingRequests Amazon muestra la profundidad de cola actual de cada instancia. Si este valor suele estar por encima de cero, considera la posibilidad de elegir una instancia con más vCPUs. Si la profundidad de la cola supera los 8.192, Neptune devolverá un error. ThrottlingException

Aproximadamente el 65 % de la RAM de cada instancia se reserva para la memoria caché de búfer. La memoria caché de búfer dispone del conjunto de datos de trabajo (no todo el gráfico, solo los datos que se están consultando). Para determinar qué porcentaje de datos se obtiene de la memoria caché del búfer en lugar del almacenamiento, supervise la métrica. CloudWatch BufferCacheHitRatio Si esta métrica suele caer por debajo del 99,9 por ciento, considere la posibilidad de probar una instancia con más memoria para determinar si reduce la latencia y I/O los costes.

Las réplicas de lectura no tienen que tener el mismo tamaño que la instancia de escritura. Sin embargo, las cargas de trabajo de escritura pesadas pueden provocar que las réplicas más pequeñas se retrasen y se reinicien porque no pueden seguir el ritmo de la replicación. Por lo tanto, recomendamos hacer réplicas iguales o más grandes que la instancia de escritura.

Cuando utilice el escalado automático para sus réplicas de lectura, recuerde que conectar una nueva réplica de lectura a Internet puede tardar hasta 15 minutos. Cuando el tráfico de clientes aumente de forma rápida pero predecible, puede utilizar el escalado programado para establecer un número mínimo de réplicas de lectura más alto y así compensar ese tiempo de inicialización.

Las instancias sin servidor admiten varios casos de uso y cargas de trabajo diferentes. Considere la posibilidad de utilizar instancias sin servidor en lugar de aprovisionadas en los siguientes escenarios:

Es importante tener en cuenta que las instancias sin servidor son más caras que las instancias aprovisionadas equivalentes en términos de dólares por GB de RAM. Cada instancia sin servidor consta de 2 GB de RAM junto con la vCPU y las redes asociadas. Analice los costos de las distintas opciones para evitar facturas inesperadas. En general, solo podrá ahorrar costos con la tecnología sin servidor si su carga de trabajo hace un esfuerzo intenso durante unas pocas horas al día, pero prácticamente nulo durante el resto del día, o si su carga de trabajo fluctúa considerablemente a lo largo del día.

Utilice la calculadora de precios de Amazon Neptune para evaluar la configuración correcta de su clúster en función de factores como los requisitos queries-per-second (QPS).

Optimización de las escrituras

Para optimizar las escrituras, tenga en cuenta las siguientes soluciones: