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:

• Confirmar los requisitos empresariales

• Medir el rendimiento de la carga de trabajo

• Identificar los componentes de bajo rendimiento

• Ajustar los componentes para que se adapten a las necesidades de su empresa

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

El pilar de la eficiencia del desempeño se centra en las siguientes áreas clave:

• Modelado gráfico

• Optimización de las consultas

• Dimensionamiento correcto de clústeres

• Optimización de escritura

Comprenda el modelado de gráficos

Comprenda la diferencia entre los modelos Labeled Property Graph (LPG) y Resource Description Framework (RDF). En la mayoría de los casos, es una cuestión de preferencia. 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 varios inquilinos, 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 añadir 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.

El rendimiento de las consultas depende de la cantidad de objetos gráficos (nodos, bordes, propiedades) que deban evaluarse al procesar la consulta. Por lo tanto, el modelo gráfico puede tener un impacto significativo en el rendimiento de la aplicación. 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, como crear nodos de resumen o bordes más directos 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 un número de aristas de decenas). El resultado es una complejidad informática 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. Puedes usar registros de consultas lentas para ayudar a identificar las consultas que navegan por estos nodos. Es probable que observes métricas de latencia y acceso a los datos mucho más altas que los patrones de consulta habituales, especialmente si utilizas 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 se ejecuta en el DFE, pero las consultas de Gremlin y SPARQL se pueden configurar opcionalmente para que se ejecuten en el DFE mediante anotaciones de consulta. Considere la posibilidad de probar las consultas con el DFE activado y comparar el rendimiento del patrón de consulta cuando no utilice el 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, considere la posibilidad de utilizar el SDK de AWS 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 el perfil de Gremlin, la explicación de OpenCypher y la explicación de SPARQL.

Comprenda sus patrones de consulta. Si el número de bordes distintos de un gráfico aumenta, la estrategia de acceso a Neptune predeterminada puede resultar ineficiente. Las siguientes consultas pueden resultar bastante ineficientes:

• Consultas que se desplazan hacia atrás a través de los bordes cuando no se proporciona ninguna etiqueta de borde.

• Cláusulas que utilizan este mismo patrón internamente, como .both() en Gremlin, o cláusulas que eliminan nodos en cualquier idioma (lo que requiere eliminar los bordes entrantes sin conocer las etiquetas).

• Consultas que acceden a los valores de las propiedades sin especificar las etiquetas de las propiedades. Estas consultas pueden resultar bastante ineficientes. Si esto coincide con su patrón de uso, considere habilitar el índice OSGP (objeto, sujeto, gráfico, predicado).

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 de E/S. Los puntos finales explicativos y perfilados de Neptune para Gremlin, SPARQL u OpenCypher pueden ayudarle a entender por qué estas consultas son lentas. Entre las causas se pueden incluir las siguientes:

• Los nodos con un número de aristas anormalmente alto en comparación con el nodo promedio del gráfico (por ejemplo, miles en lugar de decenas) pueden añadir complejidad computacional y, por lo tanto, una latencia más prolongada y un mayor consumo de recursos. Determine si estos nodos están modelados correctamente o si se pueden mejorar los patrones de acceso para reducir la cantidad de bordes que deben atravesarse.

• Las consultas no optimizadas contendrán una advertencia de que algunos pasos específicos no están optimizados. Reescribir estas consultas para usar pasos optimizados podría mejorar el rendimiento.

• Los filtros redundantes pueden provocar búsquedas de índices innecesarias. Del mismo modo, los patrones redundantes pueden provocar búsquedas de índices duplicadas que pueden optimizarse mejorando la consulta (consulte Index Operations - Duplication ratio el resultado del perfil).

• Algunos lenguajes, como Gremlin, no tienen valores numéricos bien escritos y, en su lugar, utilizan la promoción tipográfica. Por ejemplo, si el valor es 55, Neptune busca valores enteros, largos, flotantes y otros tipos numéricos equivalentes a 55. Esto da como resultado operaciones adicionales. Si sabe de antemano que sus tipos coinciden, puede evitarlo utilizando una sugerencia de consulta.

• Su modelo gráfico puede tener un gran impacto en el rendimiento. Considere la posibilidad de reducir la cantidad de objetos que deben evaluarse utilizando etiquetas más granulares o calculando previamente los atajos para las rutas lineales de saltos múltiples.

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

Clústeres del tamaño correcto

Ajuste el tamaño del clúster a sus requisitos de simultaneidad y rendimiento. El número de consultas simultáneas que puede gestionar cada instancia del clúster es igual a dos veces el número de consultas virtuales CPUs (vCPUs) de esa instancia. Las consultas adicionales que llegan mientras todos los subprocesos de trabajo están ocupados se colocan en una cola del lado del servidor. Estas consultas se gestionan mediante FIFO cuando los subprocesos de trabajo están disponibles. first-in-first-out 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 por ciento de la RAM de cada instancia se reserva para la memoria caché del búfer. La memoria caché del búfer contiene el 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 caché del búfer en lugar del almacenamiento, supervise la CloudWatch métrica. 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 los costes de E/S.

Las réplicas de lectura no tienen que tener el mismo tamaño que la instancia de grabación. 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 mayores que la instancia de grabación.

Cuando utilices el autoescalado para tus réplicas de lectura, recuerda que poner una nueva réplica de lectura en línea puede tardar hasta 15 minutos. Cuando el tráfico de clientes aumente de forma rápida pero predecible, considere la posibilidad de utilizar el escalado programado para establecer un número mínimo de réplicas de lectura más alto para tener en cuenta 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:

• Su carga de trabajo fluctúa con frecuencia a lo largo del día.

• Ha creado una nueva aplicación y no está seguro del tamaño de la carga de trabajo.

• Está realizando el desarrollo y las pruebas.

Es importante tener en cuenta que las instancias sin servidor son más caras que las instancias aprovisionadas equivalentes en términos de dólar por GB de RAM. Cada instancia sin servidor consta de 2 GB de RAM junto con la vCPU y la red asociadas. Realice un análisis de costos entre sus opciones para evitar facturas inesperadas. En general, solo podrá ahorrar costes con la tecnología sin servidor si su carga de trabajo es muy intensa durante unas pocas horas al día y prácticamente nula durante el resto del día o si su carga de trabajo fluctúa considerablemente a lo largo del día.

Optimice las escrituras

Para optimizar las escrituras, ten en cuenta lo siguiente:

• El cargador masivo Neptune es la forma óptima de cargar inicialmente la base de datos o añadirla a los datos existentes. El cargador Neptune no es transaccional y no puede eliminar datos, así que no lo utilice si estos son sus requisitos.

• Las actualizaciones transaccionales se pueden realizar mediante los lenguajes de consulta compatibles. Para optimizar las operaciones de E/S de escritura, escriba los datos en lotes de 50 a 100 objetos por confirmación. Un objeto es un nodo, una arista o una propiedad en un nodo o una arista en LPG, o un almacén triple o un cuadrilátero en RDF.

• Todas las operaciones de escritura de Neptune son de un solo hilo para cada conexión. Al enviar una gran cantidad de datos a Neptune, considere la posibilidad de tener varias conexiones paralelas, cada una de las cuales escriba datos. Cuando eliges una instancia aprovisionada por Neptune, el tamaño de la instancia se asocia a un número de v. CPUs Neptune crea dos subprocesos de base de datos para cada vCPU de la instancia, así que comience con el doble de v CPUs cuando pruebe la paralelización óptima.  Las instancias sin servidor escalan el número de v CPUs a una tasa de aproximadamente uno por cada 4. NCUs

• Planifique y ConcurrentModificationExceptionsgestione de manera eficiente todos los procesos de escritura, incluso si solo una conexión escribe datos en cualquier momento. Diseñe sus clientes para que sean fiables cuando ConcurrentModificationExceptions se produzcan.

• Si desea eliminar todos sus datos, considere la posibilidad de utilizar la API de restablecimiento rápido en lugar de emitir consultas de eliminación simultáneas. Esta última llevará mucho más tiempo e incurrirá en un costo de E/S sustancial en comparación con la primera.

• Si desea eliminar la mayoría de los datos, considere la posibilidad de exportar los datos que desee conservar mediante neptune-export para cargar los datos en un nuevo clúster. A continuación, elimine el clúster original.