La elección entre Amazon Aurora, Amazon Relational Database Service (Amazon RDS), Amazon DynamoDB, Amazon ElastiCache y Amazon Redshift comienza con una decisión fundamental. Debemos definir cómo la carga de trabajo lee y escribe datos, así como qué garantías debe ofrecer en términos de consistencia, latencia, disponibilidad y recuperación. En este curso, desarrollaremos un marco de trabajo replicable que permita transformar dichos requisitos en una elección de base de datos justificada y verificable.
Este curso se centra en cinco servicios de datos gestionados de AWS y en las cargas de trabajo para las que son adecuados. Amazon Aurora y Amazon RDS están diseñados para el procesamiento de transacciones en línea (OLTP) mediante motores relacionales. Amazon DynamoDB está orientado a patrones de acceso clave-valor, ofreciendo un rendimiento predecible de baja latencia (en el orden de milisegundos de un solo dígito) a gran escala. Amazon ElastiCache es una caché en memoria que almacena copias de datos, en lugar de actuar como el sistema de registro principal. Amazon Redshift está destinado a cargas de trabajo de análisis que requieren escanear y agregar grandes conjuntos de datos.
Asimismo, tenemos presentes los límites definidos por AWS. Una Región es un área geográfica donde AWS opera múltiples centros de datos aislados entre sí. Una Zona de disponibilidad es una ubicación aislada dentro de una Región. Muchas de las características de durabilidad y disponibilidad dependen de cómo un servicio utiliza varias Zonas de disponibilidad dentro de una misma Región.
Analicemos cómo se sitúan estos cinco servicios en el espectro de transacciones, caché y análisis.
Utilizaremos el mismo ciclo de decisión en cada lección. Primero, definimos los patrones de acceso y el modelo de datos. Luego, asociamos esas necesidades con un mecanismo de servicio que las satisfaga. A continuación, identificamos las compensaciones (trade-offs) en términos de costes, responsabilidad operativa y comportamiento ante fallos. Finalmente, confirmamos la elección basándonos en evidencia observable, no en suposiciones.
La evidencia debe corresponderse con el límite del sistema que estamos evaluando. Las métricas y los registros muestran lo que ocurrió durante la ejecución real. El análisis estático y la revisión de la configuración solo muestran lo que podría suceder dada una configuración concreta. Una buena decisión incorpora al menos un indicador de tiempo de ejecución capaz de refutar nuestras suposiciones.
Visualicemos la secuencia —requisitos, mecanismo y evidencia— que practicaremos de forma recurrente.