PERF04-BP02 Evaluar las opciones disponibles
Comprenda las opciones de bases de datos disponibles y cómo puede optimizar el rendimiento antes de seleccionar su solución de administración de datos. Utilice las pruebas de carga para identificar las métricas de la base de datos que son importantes para su carga de trabajo. Mientras explora las opciones de la base de datos, tenga en cuenta varios aspectos como los grupos de parámetros, las opciones de almacenamiento, la memoria, la computación, la réplica de lectura, la coherencia posterior, la agrupación de conexiones y las opciones de almacenamiento en caché. Experimente con estas diversas opciones de configuración para mejorar las métricas.
Resultado esperado: una carga de trabajo podría tener una o más soluciones de bases de datos utilizadas en función de los tipos de datos. La funcionalidad y las prestaciones de la base de datos se ajustan de forma óptima a las características de los datos, los patrones de acceso y los requisitos de la carga de trabajo. Para optimizar el rendimiento y el coste de su base de datos, debe evaluar los patrones de acceso a los datos para determinar las opciones adecuadas de la base de datos. Evalúe los tiempos de consulta aceptables para asegurarse de que las opciones de base de datos seleccionadas pueden cumplir los requisitos.
Patrones de uso no recomendados comunes:
-
No identificar los patrones de acceso a los datos.
-
No conocer las opciones de configuración de la solución elegida para la administración de datos.
-
Confiar únicamente en el aumento del tamaño de la instancia sin considerar otras opciones de configuración disponibles.
-
No comprobar las características de escalado de la solución elegida.
Beneficios de establecer esta práctica recomendada: si explora y experimenta con las opciones de bases de datos, podrá reducir el coste de la infraestructura, mejorar el rendimiento y la escalabilidad y reducir el esfuerzo necesario para mantener sus cargas de trabajo.
Nivel de riesgo expuesto si no se establece esta práctica recomendada: Alto
-
Tener que optimizar para una base de datos que sirve para todo significa hacer compromisos innecesarios.
-
Mayores costes por no haber configurado la solución de base de datos para que se ajuste a los patrones de tráfico.
-
Los problemas operativos pueden surgir de los problemas de escala.
-
Los datos pueden no estar protegidos al nivel requerido.
Guía para la implementación
Comprenda las características de los datos de su carga de trabajo para poder configurar las opciones de su base de datos. Realice pruebas de carga para identificar sus métricas de rendimiento clave y los cuellos de botella. Utilice estas características y métricas para evaluar las opciones de la base de datos y experimentar con diferentes configuraciones.
Servicios de AWS | Amazon RDS, Amazon Aurora | Amazon DynamoDB | Amazon DocumentDB | Amazon ElastiCache | Amazon Neptune | Amazon Timestream | Amazon Keyspaces | Amazon QLDB |
---|---|---|---|---|---|---|---|---|
Escalado de computación | Aumentar el tamaño de la instancia, escalado automático de instancias sin servidor de Aurora en respuesta a los cambios en la carga | Escalado automático de lectura/escritura con el modo de capacidad bajo demanda o escalado automático de capacidad de lectura/escritura aprovisionada en el modo de capacidad aprovisionada | Aumentar el tamaño de la instancia | Aumentar el tamaño de la instancia, añadir nodos al clúster | Aumentar el tamaño de la instancia | Se escala automáticamente para ajustar la capacidad | Escalado automático de lectura/escritura con el modo de capacidad bajo demanda o escalado automático de capacidad de lectura/escritura aprovisionada en el modo de capacidad aprovisionada | Se escala automáticamente para ajustar la capacidad |
Escalado horizontal de lecturas | Todos los motores admiten réplicas de lectura. Aurora admite el escalado automático de las instancias de réplica de lectura | Aumentar las unidades de capacidad de lectura aprovisionadas | Réplicas de lectura | Réplicas de lectura | Réplicas de lectura. Admite el escalado automático de las instancias de réplicas de lectura | Escalado automático | Aumentar las unidades de capacidad de lectura aprovisionadas | Escala automáticamente verticalmente hasta los límites de concurrencia documentados |
Escalado horizontal de escrituras | Aumentando el tamaño de la instancia, agrupando en lotes las escrituras en la aplicación o añadiendo una cola delante de la base de datos. Escalado horizontal mediante particiones en el nivel de la aplicación en múltiples instancias | Aumente las unidades de capacidad de escritura aprovisionadas. Garantizar una clave de partición óptima para evitar la limitación de escritura en el nivel de la partición | Aumentar el tamaño de la instancia principal | Uso de Redis en modo clúster para distribuir las escrituras entre las particiones | Aumentar el tamaño de la instancia | Las solicitudes de escritura pueden limitarse durante el escalado. Si encuentra excepciones de limitación, continúe enviando datos con el mismo rendimiento (o superior) para escalar automáticamente. Escrituras por lotes para reducir las solicitudes de escritura concurrentes | Aumente las unidades de capacidad de escritura aprovisionadas. Garantizar una clave de partición óptima para evitar la limitación de escritura en el nivel de la partición | Escala automáticamente verticalmente hasta los límites de concurrencia documentados |
Configuración del motor | Grupos de parámetros | No corresponde | Grupos de parámetros | Grupos de parámetros | Grupos de parámetros | No corresponde | No corresponde | No corresponde |
Almacenamiento en caché | Caché en memoria, configurable mediante grupos de parámetros. Combinar con una caché dedicada, como ElastiCache para Redis, para descargar las solicitudes de los elementos a los que se accede con frecuencia | Caché totalmente administrada de DAX (DAX) disponible | Almacenamiento en caché en memoria. Opcionalmente combinar con una caché dedicada, como ElastiCache para Redis, para descargar las solicitudes de los elementos a los que se accede con frecuencia | La función principal es el almacenamiento en caché | Utilizar la caché de resultados de consulta para almacenar en caché el resultado de una consulta de solo lectura | Timestream tiene dos niveles de almacenamiento; uno de ellos es un nivel de alto rendimiento en memoria | Despliegue una caché separada dedicada como ElastiCache para Redis, para descargar las solicitudes de los elementos a los que se accede con frecuencia | No corresponde |
Alta disponibilidad / recuperación de desastres | La configuración recomendada para las cargas de trabajo de producción es ejecutar una instancia en espera en una segunda zona de disponibilidad para proporcionar resiliencia dentro de una región. Para la resiliencia entre regiones, se puede utilizar la base de datos global de Aurora | Alta disponibilidad en una región. Las tablas se pueden replicar en todas las regiones utilizando las tablas globales de DynanoDB | Cree varias instancias en las zonas de disponibilidad para que estén disponibles. Las instantáneas pueden compartirse entre regiones y los clústeres pueden replicarse utilizando DMS para proporcionar replicación entre regiones y recuperación de desastres | La configuración recomendada para los clústeres de producción es crear al menos un nodo en una zona de disponibilidad secundaria. El almacén de datos global de ElastiCache se puede usar para replicar clústeres en regiones. | Las réplicas de lectura en otras zonas de disponibilidad sirven como objetivos de conmutación por error. Las instantáneas pueden compartirse entre regiones y los clústeres pueden replicarse usando flujos de Neptune para replicar datos entre dos clústeres en dos regiones diferentes. | Alta disponibilidad dentro de una región. La replicación entre regiones requiere el desarrollo de aplicaciones personalizadas utilizando el SDK de Timestream | Alta disponibilidad en una región. La replicación entre regiones requiere una lógica de aplicación personalizada o herramientas de terceros | Alta disponibilidad en una región. Para replicar entre regiones, exporte el contenido del diario de Amazon QLDB a un bucket de S3 y configure el bucket para la replicación entre regiones. |
Pasos para la aplicación
-
¿Qué opciones de configuración están disponibles para las bases de datos seleccionadas?
-
Los grupos de parámetros para Amazon RDS y Aurora permiten ajustar los parámetros comunes a nivel del motor de la base de datos, como la memoria asignada para la caché o el ajuste de la zona horaria de la base de datos
-
En el caso de los servicios de bases de datos aprovisionados como Amazon RDS, Aurora, Neptune, Amazon DocumentDB y los desplegados en Amazon EC2, puede cambiar el tipo de instancia, el almacenamiento aprovisionado y añadir réplicas de lectura.
-
DynamoDB permite especificar dos modos de capacidad: bajo demanda y aprovisionada. Para tener en cuenta las diferentes cargas de trabajo, puede cambiar entre estos modos y aumentar la capacidad asignada en el modo aprovisionado en cualquier momento.
-
-
¿La lectura o escritura de la carga de trabajo es pesada?
-
¿Qué soluciones hay para descargar las lecturas (réplicas de lectura, caché, etc.)?
-
Para tablas de DynamoDB, puede descargar las lecturas utilizando DAX para el almacenamiento en caché.
-
Para bases de datos relacionales, puede crear un clúster de ElastiCache para Redis y configurar su aplicación para que lea primero de la caché, retrocediendo a la base de datos si el elemento solicitado no está presente.
-
Las bases de datos relacionales, como Amazon RDS y Aurora, y las bases de datos NoSQL aprovisionadas, como Neptune y Amazon DocumentDB, admiten la adición de réplicas de lectura para descargar las partes de lectura de la carga de trabajo.
-
Las bases de datos sin servidor como DynamoDB escalarán automáticamente. Asegúrese de que tiene suficientes unidades de capacidad de lectura (RCU) aprovisionadas para manejar la carga de trabajo.
-
-
¿Qué soluciones hay para escalar las escrituras (fragmentación de claves de partición, introducción de una cola, etc.)?
-
En el caso de las bases de datos relacionales, se puede aumentar el tamaño de la instancia para acomodar una mayor carga de trabajo o aumentar las IOP aprovisionadas para permitir un mayor rendimiento del almacenamiento subyacente.
-
También puede introducir una cola delante de su base de datos en lugar de escribir directamente en la base de datos. Este patrón permite desacoplar la ingesta de la base de datos y controlar el caudal para que la base de datos no se vea desbordada.
-
Agrupar las solicitudes de escritura en lugar de crear muchas transacciones de corta duración puede ayudar a mejorar el rendimiento en las bases de datos relacionales de gran volumen de escritura.
-
-
Las bases de datos sin servidor como DynamoDB pueden escalar el rendimiento de escritura automáticamente o ajustando las unidades de capacidad de escritura (WCU) aprovisionadas en función del modo de capacidad.
-
Sin embargo, todavía puede tener problemas con particiones activas, cuando se alcanzan los límites de rendimiento para una clave de partición determinada. Esto se puede mitigar eligiendo una clave de partición más uniformemente distribuida o compartiendo la escritura de la clave de partición.
-
-
-
-
¿Cuáles son los picos de transacciones por segundo (TPS) actuales o previstos? Pruebe utilizando este volumen de tráfico y este volumen +X % para entender las características de escalado.
-
Se pueden utilizar herramientas nativas como pg_bench para PostgreSQL para realizar pruebas de estrés de la base de datos y comprender los cuellos de botella y las características de escalado.
-
El tráfico de producción debe capturarse para que pueda reproducirse para simular las condiciones del mundo real, además de las cargas de trabajo sintéticas.
-
-
Si se utiliza la computación sin servidor o escalable de forma elástica, pruebe el impacto del escalado en la base de datos. Si procede, introduzca la administración de conexiones o la agrupación para reducir el impacto en la base de datos.
-
RDS Proxy se puede utilizar con Amazon RDS y Aurora para administrar conexiones a la base de datos.
-
Las bases de datos sin servidor como DynamoDB no tienen conexiones asociadas, pero consideran la capacidad aprovisionada y las políticas de escalado automático para hacer frente a los picos de carga.
-
-
¿Es la carga predecible, hay picos de carga y periodos de inactividad?
-
Si hay periodos de inactividad, considere la posibilidad de reducir la capacidad aprovisionada o el tamaño de la instancia durante estos periodos. Aurora sin servidor V2 escalará y desescalará verticalmente en función de la carga.
-
Para las instancias que no son de producción, considere la posibilidad de pausarlas o detenerlas durante las horas no laborables.
-
-
¿Necesita segmentar y separar sus modelos de datos en función de los patrones de acceso y las características de los datos?
-
Considere la posibilidad de utilizar AWS DMS o AWS SCT para trasladar sus datos a otros servicios.
-
Nivel de esfuerzo para el plan de implementación:
Para establecer esta práctica recomendada, debe conocer sus características y métricas de datos actuales. Reunir esas métricas, establecer una línea de referencia y luego usar esas métricas para identificar las opciones ideales de configuración de la base de datos es un nivel de esfuerzo de bajo a moderado . La mejor forma de validarlo es mediante pruebas de carga y experimentación.
Recursos
Documentos relacionados:
Vídeos relacionados:
Ejemplos relacionados: