Blog · The Guild ITAporte de la comunidad

¿Cuándo hablamos de bases de datos, qué opción es mejor? ¿RDS tradicional, Aurora con Reader/Writer o Aurora Serverless?

Una app de ventas en pleno evento: órdenes que no paran, un dashboard en tiempo real y un reporte al cierre. Diana nos lleva por tres arquitecturas en AWS y por qué la respuesta no está en la tecnología más moderna, sino en cómo se comporta tu aplicación.

Diana Karen Méndez RosasSolution Architect · Guardian · México

Lectura de 6 min

Hablar de bases de datos es entrar a un universo muy grande de donde elegir se tienen desde Relacionales (SQL), Documentales (NoSQL), Clave-valor, Columnares, Grafos, Series de tiempo y Vectoriales, ante todas estas opciones la primera pregunta es ¿Cuál es la mejor opción?

• 01Relacionales (SQL)
• 02Documentales (NoSQL)
• 03Clave-valor
• 04Columnares
• 05Grafos
• 06Series de tiempo
• 07Vectoriales

//Antes de elegir

Aquí te recomiendo siempre hacerte estas preguntas primero para elegir acertadamente.

1. 01¿Cuál es la necesidad de la aplicación que se requiere resolver?
2. 02¿Cuál será la volumetría de las transacciones?
3. 03¿Cuál es el comportamiento esperado para la carga de trabajo?
4. 04¿Qué disponibilidad se espera tener de la aplicación?
5. 05¿Se contará con diferentes tipos de carga de trabajo (Transaccional, consulta de información, reportes, dashboards, integración con otros sistemas, procesos de análisis)?

//El escenario

En el siguiente escenario podríamos poner en práctica estas recomendaciones anexando estas dos preguntas:

1. A¿Qué base de datos elegir?
2. B¿Qué arquitectura es la más adecuada?

Se cuenta con una aplicación de ventas utilizada durante un evento, el evento en la aplicación debe registrar de forma constante nuevas órdenes de venta y procesar las transacciones realizadas por los usuarios. Cada venta genera nueva información que debe almacenarse correctamente y estar disponible para continuar con la operación, al mismo tiempo, los usuarios requieren consultar en tiempo real un dashboard que muestre el comportamiento de las ventas durante el evento. Entre la información que necesitan visualizar se encuentra:

Finalmente, cuando el evento finalice el cliente necesita generar un reporte consolidado con toda la información de las ventas realizadas.

La aplicación se encuentra desarrollada en un entorno de AWS, al diseñar el esquema de datos se tomará la decisión entre una base de datos relacional tradicional en Amazon RDS, implementar un clúster de Amazon Aurora con instancias especializadas para escritura y lectura o utilizar Aurora Serverless para adaptar automáticamente la capacidad a la demanda.

01Opción RDS tradicional

Para una base de datos relacional en Amazon RDS, por ejemplo, MySQL o PostgreSQL. Este modelo puede ser suficiente si conocemos razonablemente bien la capacidad que requiere la aplicación y la carga del evento es estable o predecible.

En la arquitectura donde la aplicación se conecta a una instancia RDS con alta disponibilidad, por ejemplo, utilizando Multi-AZ, y donde las operaciones de ventas, dashboard y reportes utilizan la misma base de datos.

El flujo sería conceptualmente:

Esta alternativa es la más sencilla de implementar y administrar, sin embargo, tiene un punto importante que debemos considerar: las operaciones de lectura y escritura compiten por los mismos recursos.

Durante el evento podríamos tener

• WEscrituras constantes de nuevas ventas.
• WActualizaciones de inventario.
• WRegistro de métodos de pago.
• RConsultas constantes del dashboard.
• RConsultas más pesadas para generar reportes.

02Opción Amazon Aurora Writer/Reader

Una base de datos relacional basada en Amazon Aurora, utilizando un clúster con una instancia Writer y una o más instancias Reader es una opción muy aceptable dado que podemos tener diferentes roles dentro del clúster cuando la aplicación comienza a requerir mayor disponibilidad, rendimiento, etc.

Esta opción nos ayuda a separar las cargas de trabajo.

La aplicación de ventas utilizaría el Writer Endpoint para las operaciones que modifican información, mientras que el dashboard utilizaría el Reader Endpoint para las consultas de lectura.

La arquitectura principal sería:

Esto permite separar las cargas y evitar que las consultas del dashboard y los reportes compitan directamente por los recursos, aquí también debemos de considerar que los Readers utilizan replicación, por lo que debemos analizar el retraso de replicación y determinar si el dashboard requiere información estrictamente inmediata.

03Opción Amazon Aurora Serverless

Una base de datos relacional basada en Aurora, pero utilizando una arquitectura Serverless está diseñada para adaptar la capacidad de la base de datos de acuerdo con la demanda.

En este caso, la ventaja principal sería que la capacidad puede adaptarse al comportamiento de la carga.

Esta opción puede funcionar si contamos con un comportamiento de una carga variable y posiblemente impredecible, durante las primeras horas podemos tener pocos usuarios, pero cuando inicia el evento podríamos tener cientos o miles de operaciones simultáneas y después del evento, la demanda puede disminuir considerablemente.

En este escenario, Serverless puede ser atractivo porque evita tener que dimensionar permanentemente la infraestructura para el máximo pico de demanda.

Para elegir una arquitectura correcta no siempre se elige por la tecnología más moderna, sino por el patrón de comportamiento de la aplicación.

— Diana Karen Méndez Rosas

Diana Karen Méndez Rosas

Solution Architect · Guardian · Profesional verificado · México

Profesional especializada en arquitectura de soluciones en la nube, migración y modernización de infraestructuras, así como optimización de costos en AWS. Con experiencia en administración de sistemas, despliegue de aplicaciones y automatización de infraestructura.

Contenido aportado por la comunidad de The Guild IT. Las opiniones son de su autora. TGIT no está afiliado a Amazon Web Services; las marcas mencionadas pertenecen a sus respectivos dueños.