AZ-104
Deep Dive
La base de datos NoSQL multi-modelo y globalmente distribuida de Azure. El AZ-104 evalúa los conceptos de consistencia, particionado, RU/s, distribución global y las APIs disponibles.
Contenido
Azure Cosmos DB es un servicio de base de datos NoSQL multimodelo, totalmente gestionado y diseñado para escalar a nivel global con latencias de un solo dígito en milisegundos. Garantiza SLAs integrales que cubren disponibilidad, throughput, consistencia y latencia.
A diferencia de las BDs relacionales, Cosmos DB es schemaless — los documentos o entidades no necesitan seguir un esquema fijo.
SLA de latencia
<10ms lectura, <10ms escritura (P99) en la región local
SLA de disponibilidad
99.999% para escritura multi-región. 99.99% single-region
Escalabilidad
Desde kB hasta PB. Millones de requests/segundo sin rediseñar
Global distribution
Replicar a cualquier región Azure con un click
Jerarquía de recursos en Cosmos DB
Cosmos Account
Unidad de tope. Define la API, configuración de consistencia y regiones.
Database
Contenedor lógico de containers. Puede tener throughput compartido.
Container
Unidad de escalabilidad. Define partition key, throughput, TTL, índices.
Item
Documento JSON (API NoSQL), fila (Cassandra), nodo/edge (Gremlin), etc.
Cosmos DB usa un motor unificado con múltiples "frentes" de API. La API define el modelo de datos y el protocolo de wire. No se puede cambiar después de crear la cuenta.
| API | Modelo de datos | Protocolo | Migrar desde | Mejor para |
|---|---|---|---|---|
| NoSQL (nativo) | Documentos JSON | HTTP/HTTPS REST | MongoDB, DynamoDB (con cambios) | Nuevas apps, JSON, cambios frecuentes de esquema |
| MongoDB | Documentos BSON | MongoDB wire protocol | MongoDB on-prem/Atlas | Lift-and-shift de apps MongoDB sin cambiar código de driver |
| Cassandra | Filas columnar (wide-column) | CQL (Cassandra Query Language) | Apache Cassandra on-prem | Apps Cassandra existentes, series de tiempo, IoT |
| Gremlin (Graph) | Grafos (vértices y aristas) | Gremlin over WebSocket | Neo4j, TinkerPop | Redes sociales, grafos de conocimiento, detección de fraude |
| Table | Key-value (tabla) | OData / REST | Azure Table Storage | Migrar de Azure Table Storage con mayor rendimiento |
| PostgreSQL (distributed) | Relacional distribuido | PostgreSQL wire | PostgreSQL on-prem | Apps relacionales que necesitan escala horizontal (Citus) |
Para el examen AZ-104
El AZ-104 no profundiza en todas las APIs. Enfócate en: API NoSQL (la nativa, todas las features de Cosmos), API MongoDB (compatibilidad de driver, lift-and-shift). La API de Table es la ruta de migración desde Azure Table Storage con mayor escala.
El modelo de consistencia de Cosmos DB es uno de los temas más evaluados. Define el balance entre consistencia de datos y latencia/disponibilidad. Se configura a nivel de cuenta y se puede relajar en cada operación de lectura.
Strong (Fuerte)
Garantiza leer siempre la versión más reciente (linearizabilidad)
No disponible en cuentas con escrituras multi-región. La más costosa.
Latencia
Mayor latencia — debe leer de la mayoría de réplicas
Bounded Staleness
Las lecturas pueden estar desfasadas en K versiones O T segundos (tú defines los límites)
Buena para apps que toleran cierto desfase pero necesitan orden global. Orden de escrituras garantizado.
Latencia
Alta latencia de lectura fuera de región, similar a Strong en región de escritura
Session (por defecto)
Consistencia garantizada para el cliente (sesión) que escribe. Otros clientes pueden ver versión anterior.
El default y recomendado para la mayoría de apps. "Read-your-writes" para el cliente que escribe.
Latencia
Baja — el nivel más usado
Consistent Prefix
Nunca se ven lecturas desordenadas. Si se escriben A, B, C — jamás verás C sin B.
No garantiza leer lo más reciente, pero el orden es consistente.
Latencia
Baja
Eventual (Eventual)
No hay garantía de orden ni de leer lo más reciente. Solo "en algún momento convergirá".
Para casos donde el orden no importa: contadores aproximados, like counts, etc.
Latencia
Mínima latencia, máxima disponibilidad
Regla mnemotécnica
De más fuerte a más eventual: Strong → Bounded Staleness → Session → Consistent Prefix → Eventual. A mayor consistencia: mayor latencia de lectura y menor disponibilidad. El default (Session) es el balance óptimo para 90% de los casos.
Cómo funciona el particionado
Cosmos DB divide los datos en logical partitions basadas en el valor de la partition key. Múltiples logical partitions se mapean a physical partitions que Cosmos gestiona automáticamente.
Límites por partición lógica
Máx. 20 GB de datos
Máx. 10.000 RU/s de throughput
Cada physical partition tiene ~10.000 RU/s máx y ~50 GB. Cosmos redistribuye automáticamente (reparticionado) a medida que crecen los datos.
Buena Partition Key
Mala Partition Key
Sintethic partition key
Si ningún campo natural es buen PK, crea uno combinando varios campos. Ej: UserId + DateTime → "user123_2024-01"
Una Request Unit (RU) es la moneda de rendimiento de Cosmos DB. 1 RU = leer un ítem de 1 KB con consistencia de sesión. Las escrituras, queries complejas y cross-partition queries consumen más RUs. El costo depende del tamaño del ítem, la consistencia y el tipo de operación.
Provisioned throughput (manual)
Defines un número fijo de RU/s (mín 400 RU/s por container). Pagas siempre ese throughput esté o no en uso.
Cuándo usar
Carga predecible, SLA de latencia estricto.
Autoscale (throughput automático)
Defines un máximo de RU/s. Cosmos escala entre el 10% y el 100% de ese máximo según demanda. Cobras por el máximo alcanzado por hora.
Cuándo usar
Cargas variables o impredecibles. Ideal para dev/test y producción con spikes.
Serverless
No aprovisión — pagas solo por las RUs consumidas. Sin costo cuando no hay actividad. Sin garantía de SLA de latencia en picos.
Cuándo usar
Workloads intermitentes, bajo tráfico, desarrollo inicial.
Costo aproximado de operaciones comunes (1 KB items)
| Operación | RU aprox. | Notas |
|---|---|---|
| Point read (id + partition key) | 1 RU | La operación más barata. Siempre usar point read cuando sea posible. |
| Write (insert/replace) | 5 RU | Más caro que lectura porque actualiza todos los índices. |
| Query con partition key | 2-3+ RU | Varía según complejidad, número de resultados, índices. |
| Cross-partition query | Mucho más alto | Fan-out a todas las particiones — evitar cuando sea posible. |
Cosmos DB puede replicar datos a cualquier región Azure con un solo click. La distribución global permite leer localmente (baja latencia) y es clave para la disponibilidad global.
Modos de escritura multi-región
Single-write region
Solo una región acepta escrituras. Las demás son réplicas de lectura. Failover automático o manual si la región de escritura falla.
Multi-region writes (Multi-master)
Todas las regiones configuradas aceptan escrituras. Latencia de escritura mínima en cualquier región. Requiere gestionar conflictos de escritura.
Resolución de conflictos (multi-write)
Last-Write-Wins (LWW)
El ítem con el _ts (timestamp) más alto gana. Por defecto. Puede usar cualquier campo numérico del documento.
Custom (Stored Procedure)
Un stored procedure de Cosmos decide qué versión prevalece. Máxima flexibilidad para lógica de negocio.
Manual (Conflict Feed)
Los conflictos se escriben en el "conflict feed" para que la app los resuelva manualmente.
Time-to-Live (TTL)
Permite que los ítems expiren automáticamente después de N segundos. Cosmos los elimina en background sin consumir RUs de escritura del usuario.
→ TTL en container: aplica a todos los ítems que no tengan TTL propio
→ TTL = -1: inmortal (no expira aunque el container tenga TTL)
→ TTL = 0 o null: hereda el TTL del container
→ TTL en ítem: sobreescribe el del container para ese ítem específico
Ideal para: sesiones de usuario, caché de datos temporales, mensajes que expiran.
Change Feed
Flujo ordenado (por partition key) de todos los inserts y updates de un container. Permite construir pipelines de procesamiento de eventos sin polling.
Casos: materializar vistas, sincronizar cachés, audit logs, replicación a otros sistemas.
Plano de control vs Plano de datos
Plano de control (ARM)
Crear/eliminar cuentas, bases de datos, containers. Gestionar configuración. Autorizado con Azure RBAC estándar (Owner, Contributor, Cosmos DB Account Reader).
Plano de datos
Leer/escribir documentos. Dos métodos: 1) RBAC de Cosmos DB (built-in roles: Cosmos DB Built-in Data Reader, Data Contributor) — recomendado. 2) Master Keys / Resource Tokens — legacy.
Cifrado y networking
• Cifrado en reposo: AES-256 automático, no configurable por usuario
• Customer-managed keys (CMK): en Azure Key Vault. Si la clave se revoca, los datos quedan inaccessibles
• Cifrado en tránsito: TLS obligatorio
• Private Endpoints: igual que Storage y SQL — IP privada en VNet
• IP Firewall: lista de IPs o rangos CIDRs permitidos
• Virtual Network ACLs: restringir acceso a subredes específicas
Resource Tokens — acceso granular
Para acceso de lectura/escritura temporal y granular (por container o ítem): la app genera un resource token con permisos específicos y lo entrega al cliente. Expira en máx 5 horas. No expone las master keys al cliente.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una aplicación global necesita que los usuarios de Europa lean datos con la menor latencia posible. La consistencia exacta de los datos entre regiones puede tolerarse con un desfase de hasta 30 segundos. ¿Qué configuración de Cosmos DB deberías usar?