El SAP-C02 evalúa la selección correcta de base de datos para cada workload, así como las características avanzadas de Aurora, DynamoDB y ElastiCache para diseñar sistemas altamente disponibles y de alto rendimiento.
Contenido
| Workload | Servicio recomendado | Por qué |
|---|---|---|
| OLTP relacional (web apps) | RDS MySQL/PostgreSQL o Aurora | Transacciones ACID, relaciones complejas, SQL estándar |
| OLTP de alto rendimiento y HA global | Aurora Global Database | Replicación < 1s entre regiones, failover rápido |
| Key-value / documentos a escala masiva | DynamoDB | Latencia de ms, escala infinita, serverless |
| Grafos (relaciones entre entidades) | Amazon Neptune | Traversal de grafos con Gremlin o SPARQL |
| Analítico (OLAP) | Redshift | Columnar, joins complejos, petabyte scale |
| Caché de resultados de queries | ElastiCache (Redis/Memcached) | Sub-ms latency, reduce carga en DB primaria |
| Series temporales (métricas, IoT) | Amazon Timestream | Optimizado para time-series, consultas temporales |
| Ledger inmutable y verificable | Amazon QLDB | Historial completo e inmutable de transacciones |
| Documentos MongoDB-compatible | Amazon DocumentDB | Compatible con drivers MongoDB, gestión AWS |
| SQL transaccional distribuido global | Amazon Aurora Serverless v2 | Auto-scaling, multi-region via Global DB |
Aurora es el motor de base de datos propietario de AWS, compatible con MySQL y PostgreSQL. 5× más rápido que MySQL y 3× más rápido que PostgreSQL estándar. Storage auto-scaling hasta 128 TB.
Aurora Global Database
Aurora Serverless v2
Aurora Read Replicas vs Multi-AZ
Read Replicas (hasta 15)
Multi-AZ (Aurora native)
Índices
GSI (Global Secondary Index)
LSI (Local Secondary Index)
Funciones avanzadas
DynamoDB Streams
Captura cambios (INSERT, MODIFY, DELETE) en tiempo real como un stream ordenado. Trigger Lambda para event-driven patterns. Retención 24h.
Global Tables
Replicación multi-región activo-activo. Cada región puede leer y escribir. Conflict resolution: "last write wins" por timestamp.
DAX
DynamoDB Accelerator: caché in-memory totalmente compatible con DynamoDB API. Reduce latencia de ms a microsegundos. No requiere cambios en el código de la app.
Transactions
TransactWriteItems / TransactGetItems: operaciones ACID en múltiples items/tablas atomicamente. 2× el costo de RCU/WCU.
TTL
Time-to-Live: elimina automáticamente items expirados sin costo de WCU. Para sessiones, caché, datos temporales.
| Característica | Redis | Memcached |
|---|---|---|
| Estructuras de datos | Strings, Lists, Sets, Sorted Sets, Hashes, Bitmaps, HyperLogLog | Solo strings simples |
| Persistencia | Sí (RDB + AOF) — datos sobreviven reinicios | No — datos en memoria solo |
| Replicación | Primary + hasta 5 replicas de lectura | No — sin replicación |
| Multi-AZ / Failover | Sí — failover automático a replica | No |
| Pub/Sub | Sí — canales de mensajería | No |
| Lua scripting | Sí — operaciones atómicas complejas | No |
| Sharding horizontal | Redis Cluster: automático hasta 500 shards | Sí — múltiples nodos en pool |
| Mejor para | Leaderboards, sessions, pub/sub, caché compleja | Caché simple de objetos, multithreaded simples |
Regla del examen: cuando necesitas persistencia o replicación → Redis
Si el escenario menciona "session state que debe sobrevivir a reinicios", "leaderboard", "pub/sub", "failover automático", o "datos estructurados complejos" → Redis. Si dice "caché simple de objetos sin estado" o "multithreaded" → Memcached.
Amazon Neptune
Base de datos de grafos gestionada. Soporta Property Graph (Gremlin, openCypher) y RDF (SPARQL). Para redes sociales, detección de fraude, motores de recomendación donde las relaciones entre entidades son tan importantes como los datos.
Amazon QLDB
Ledger database: registro de transacciones inmutable, criptográficamente verificable. Historial completo de todos los cambios. Para auditoría financiera, supply chain, registros de cumplimiento donde debes demostrar que los datos no han sido alterados.
Amazon Timestream
Base de datos de series temporales serverless. Optimizada para datos con timestamps: métricas de IoT, logs de aplicaciones, datos de sensores. Lifecycle automático: datos recientes en memoria, datos históricos en SSD.
Amazon DocumentDB
Base de datos de documentos compatible con MongoDB. Gestión completamente por AWS. Para apps que ya usan MongoDB y quieren un servicio gestionado sin modificar el código de la aplicación.
Read Replica Offloading
Dirige las queries de lectura (reporting, analytics) a Read Replicas para reducir carga en la instancia primaria. En Aurora hasta 15 replicas; RDS hasta 5.
Caching Strategy (Cache-Aside)
App primero consulta ElastiCache. Si no hay hit (cache miss), consulta la DB y guarda el resultado en caché. Reduce latencia y carga en DB.
Write-Through Cache
Cada escritura en la DB también actualiza el caché simultáneamente. Mayor consistencia pero más lento que cache-aside.
Cross-Region Replication
Aurora Global DB o DynamoDB Global Tables para DR entre regiones. RTO < 1 minuto para Aurora Global.
Blue/Green Deployments (RDS)
RDS Blue/Green: crea un ambiente idéntico (green) con los cambios de schema, sincroniza, y permite switchover sin downtime.
Trampa: "DynamoDB Global Tables usa replicación activo-pasivo"
Realidad: FALSO. Global Tables es activo-activo: todas las regiones aceptan lecturas Y escrituras. En caso de conflicto de escritura simultánea, gana el último timestamp (last writer wins).
Trampa: "Aurora Multi-AZ es igual que RDS Multi-AZ"
Realidad: Son diferentes. RDS Multi-AZ tiene una instancia standby que no sirve tráfico. Aurora replica el storage en 6 copias entre 3 AZs y tiene hasta 15 read replicas que SÍ sirven tráfico.
Trampa: "ElastiCache Redis y DAX son intercambiables"
Realidad: No. DAX es caché específicamente para DynamoDB con la misma API. ElastiCache Redis es una caché de propósito general que requiere lógica de caché en el código de la app.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una aplicación de e-commerce global tiene la base de datos primaria en us-east-1. Los usuarios de Asia y Europa reportan alta latencia en lecturas. La empresa necesita baja latencia de lectura en todas las regiones y capacidad de escritura en la región principal. ¿Cuál es la solución más apropiada?
Inicia sesión para llevar tu progreso.