Estrategias de performance en RDS

Estrategias de performance en RDS

• Monitoreo: Lectura y escritura, CPU, DD y Memoria (AWS CloudWatch). Conexiones.
• Réplicas de lectura: Mejorar el desempeño de la BD. No disponibles para Oracle y SQL Server. Por cada réplica, se genera un endpoint totalmente diferente, y hay que modificar el código para que utilice la réplica o la BD master cuando sea necesario.
• Provisioned: Diseñado para transacciones OLTP. 1.000 a 40.000 IOPS.
• Alternativas: BD en memoria (ElastiCache). Dividir la BD en otras BDs más pequeñas.
• Performance insights: Monitoreo de performance. Cuándo y qué acciones tomar para mejorar el rendimiento de la BD.
• Adicionales: Estrategias dependen del motor. AWS recomienda Aurora.

Existen otras alternativas como las bases de datos en memoria (ElastiCache, por ejemplo). Estas opciones resultan muy útiles para guardar la información más consultada en cache, así aliviamos un poco la carga de nuestra base de datos principal. Si estamos muy saturados y agotamos todas las opciones para mejorar el performance, la recomendación es dividir nuestra base de datos en otras más pequeñas.

y … ¿cómo se hace una réplica de lectura?

Cuando utilizamos MySQL para sacar replicas de replicas de otras replicas, debemos tener en cuenta que podemos tener problemas con la latencia, la ultima replica puede tardar un poco en actualizarse y vamos a tener información diferente a la base de datos principal 👍.

¿**Performance Insights **está solo disponible para RDS o también se puede usar con un motor instalado en una instancia EC2?

eso de la RR de la RR de la RR sonó como a la herencia prototipal de javascript! 😱🤪

Hola. ¿Como averigua hasta cuantas conexiones puede soportar la BD en una determinada instancia? ¿Si deseo mejorar el numero de conexiones debo elegir una instancia con mayor RAM o mayor CPU?
Esta muy bueno el curso, saludos…

También deberíamos tener en cuenta la consistencia eventual, cuando se hacen estas replicaciones asíncronas podemos por algún instante de tiempo ver la réplica desactualizada.

La primer estrategia para mejorar el performance son las replicas de lectura, copias asíncronas de nuestra base de datos principal con un nuevo endpoint que vamos a utilizar solo en tareas de lectura, así obtenemos mucha más disponibilidad para tareas de escritura en nuestra base de datos principal. Recuerda que este servicio no esta disponible para los motores de Oracle y SQL Server.

También podemos mejorar el storage de nuestra base de datos utilizando provisioned iops para soportar altas operaciones de entrada y salida sobre la base de datos, principalmente para transacciones OLTP (OnLine Transaction Processing).

A nivel de monitoreo, AWS nos provee un servicio llamado CloudWatch que nos permite visualizar los niveles de lectura, escritura, CPU, disco y memoria de la instancia dónde corre nuestra base de datos, también podemos analizar las métricas de conexiones para determinar la carga y la concurrencia de nuestras instancias.

En conclusión va a depender mucho del propósito de la capa de persistencia, teniendo esta claridad puede elegirse la estrategia más adecuada.

no soportable en Oracle Y Mysql ,pero si estas son los motores de bases de datos mas importantes y usados en el mercado. cada cuanto se refrescaria la READ REPLICA PARA QUE EL USUARIO Tenga la informacion mas actualizada. si es para applications de Fintech. se desea tener la informacion mas fresca

Hola, RDS SQLSever si soporta read replicas pero solo para la versión Enterprise 2016-2019.

Performances inside es una herramienta en AWS para ver el desepeño de nuestro RDS

RE replica se coloca cuando tengo mucha carga de lectura y queremos aliviar la carga a la base de datos

super claro… es conveniente tener claro que estrategia se seguirá para realizar nuestros replicas y no afectar el performance de nuestra RDS 😃

Cual es la diferencia de crear una replica de replica en lugar de una replica del maestro, no seria mejor?

Monitoreo: A traves de Cloudwatch como una perspectiva general,
Replica: Clonar la BD de forma asincrona para hacer lectura ( generaria un nuevo endpoint).
Provisioned: Alta transaccionalidad.

Lo mejor es hacer un buen diseño de la arquitectura de datos de la aplicación, con el fin de poder separar algunas tablas paramétricas y meterlas en un cache como memcache, ó ver la posibilidad de separar la información en varias BD y poder generar replicación en algunas de ellas, sobre todo ne aquellas donde se generan reportes.

Es clave entender que nuestra app tiende a leer o a escribir mayoritoriamente. motores modernos como postgres y mariadb consideran esto