Lección 7 de 12 · Lectura y práctica
Bases de Datos: RDS y DynamoDB
Compara RDS y DynamoDB a partir de las consultas de una tienda: relaciones, claves, consistencia y un ejercicio con pedidos, sin crear recursos de pago.
Del concepto a la práctica
Taller de esta lección
La elección entre RDS y DynamoDB comienza con las consultas. Una tienda necesita listar pedidos de un cliente y sumar sus líneas; las relaciones explícitas y SQL favorecen un modelo relacional. Una tabla de sesiones que se consulta siempre por session_id puede organizarse alrededor de una clave directa. La decisión no depende solo de “SQL contra NoSQL”, sino de relaciones, patrones de acceso, consistencia y operación.
Ejemplo resuelto
Registros: pedido 10, cliente 4, total 18; pedido 11, cliente 4, total 25; pedido 12, cliente 7, total 9. Para el cliente 4, la suma es 43. En RDS se obtiene filtrando por cliente_id; en DynamoDB se podría usar PK=CLIENTE#4 y claves de ordenación SK=PEDIDO#10 y SK=PEDIDO#11, consultar esa partición y sumar sus dos totales en la aplicación. La clave debe diseñarse antes de cargar los registros; no basta con cambiar el nombre de una columna SQL.
Pruébalo
Escribe dos consultas reales.
Lista entidades y relaciones.
Elige el modelo que las expresa con menos complejidad.
Señala qué prueba de carga faltaría.
Error frecuente: elegir DynamoDB esperando joins automáticos. Corrección: modela cada acceso y acepta duplicación controlada cuando sea necesaria.
Ejercicio: añade el pedido 13 del cliente 7 por 16.
Comprueba tu resultado
cliente 4 suma 43 y cliente 7 suma 25; explica qué clave o relación permite cada consulta.
Mapa de prácticaEl proveedor opera la infraestructura física y el equipo administra sus datos y accesos. La responsabilidad del sistema y la aplicación cambia según el servicio elegido. Revisa la configuración y el contrato del servicio antes de asumir que una capa está cubierta.
Ver la infografía en tamaño completo ↗RDS y DynamoDB: elige a partir de las consultas
Una base de datos no se elige solo por su nombre o por una promesa de velocidad. Escribe primero qué necesita leer y cambiar tu aplicación. En esta práctica usarás una tienda ficticia para comparar dos modelos, sin crear recursos de pago en AWS.
Qué ofrece cada servicio
Amazon RDS administra bases de datos relacionales, con motores como PostgreSQL y MySQL. AWS se ocupa de tareas como copias de seguridad y parches; el diseño del esquema y la optimización de consultas siguen siendo responsabilidades de la aplicación. Consulta la introducción oficial de RDS.
DynamoDB es una base NoSQL administrada y sin servidores que admite modelos de clave-valor y documentos. No ofrece el operador JOIN de una base relacional; el modelo se diseña alrededor de las consultas que necesitas. Eso no significa que carezca de transacciones: las admite. Consulta la introducción oficial de DynamoDB.
| Pregunta | RDS | DynamoDB |
|---|---|---|
| ¿Cómo relaciono clientes y pedidos? | Tablas, claves y consultas SQL. | Claves y datos organizados para los accesos previstos. |
| ¿Necesito joins y consultas variadas? | Revisa un modelo relacional. | Replantea cada patrón; no hay un JOIN equivalente. |
| ¿Qué debo decidir? | Motor, esquema, índices y consultas. | Clave de partición, posible clave de ordenación y patrones de acceso. |
La tabla orienta el ejercicio; no demuestra que un servicio sea siempre más barato o rápido. Esa comparación requiere una carga y una configuración concretas.
Ejemplo: pedidos de una tienda
La tienda necesita responder tres preguntas:
- ¿Cuáles son los pedidos de un cliente?
- ¿Qué productos contiene un pedido?
- ¿Cuánto vendimos de cada categoría en un periodo?
Con un esquema relacional podrías empezar con clientes, pedidos, lineas_pedido y productos. Un pedido tiene un cliente y varias líneas. Una consulta de informes puede unir esas tablas para agrupar importes por categoría.
Para DynamoDB, dibuja primero los elementos que responden a cada consulta. Como ejercicio, una clave de partición CLIENTE#42 y claves de ordenación PEDIDO#1001 y PEDIDO#1002 permiten razonar sobre pedidos agrupados por cliente. Todavía debes resolver cómo recuperar las líneas de un pedido y cómo producir el informe por categoría. No des por resuelto ese tercer acceso con el mismo diseño.
Consistencia: la lectura también tiene condiciones
DynamoDB ofrece lecturas eventualmente consistentes y, en ciertos accesos, fuertemente consistentes. Las tablas y los índices secundarios locales pueden admitir las segundas; los índices secundarios globales solo admiten lecturas eventualmente consistentes. Revisa la guía oficial de consistencia antes de decidir si una lectura necesita reflejar una escritura reciente.
Tu ejercicio de salida
Usa papel o un documento para completar estas comprobaciones:
- Dibuja las cuatro tablas relacionales y sus relaciones.
- Escribe un ejemplo de cliente, pedido y dos líneas con cantidades válidas.
- Propón las claves del diseño DynamoDB y anota qué consulta satisface cada una.
- Identifica una consulta que el primer diseño no resuelve todavía.
- Explica cuándo una lectura desactualizada sería un problema para esta tienda.
- Anota una decisión que exige una prueba de carga o una estimación de costos.
La práctica está terminada cuando puedes justificar tu elección con las consultas del negocio y reconocer sus límites. No necesitas abrir una cuenta de AWS ni desplegar una base para resolverla.
Sigue con AWS Cloud Practitioner: Fundamentos de la Nube
Esta lección forma parte de un curso de Cursalo. Revisa su programa y elige entre la compra individual o el acceso a toda la escuela.
Si ya tenías acceso a este curso, entra con tu cuenta: tus derechos y tu progreso se conservan. No necesitas comprarlo de nuevo.