Cosmos DB domina este bloque del AZ-305: elegir la API correcta, diseñar la partition key, escoger el nivel de consistencia que balancea latencia y corrección, y decidir la topología multi-región. Más las alternativas: Table Storage, Redis y AI Search.
Contenido
🗄️Árbol de decisión — Cosmos DB API y NoSQL
NoSQL · MongoDB · Cassandra · Gremlin · Table · Azure Table
Pregunta 1
¿Es un proyecto nuevo o estás migrando una app existente?
💡 Para migraciones el driver es la compatibilidad de wire-protocol — no reescribir nada. Para proyectos nuevos, elige la API que mejor modela tus datos.
| API | Modelo | Cuándo |
|---|---|---|
| NoSQL (Core) | Documentos JSON, query SQL-like | Default para apps nuevas — la API nativa con todas las features primero |
| MongoDB | Documentos BSON, wire protocol Mongo | Migrar apps MongoDB existentes sin reescribir drivers |
| Cassandra | Wide-column, CQL | Migrar workloads Cassandra |
| Gremlin | Grafos (vértices/aristas) | Relaciones complejas: redes sociales, recomendaciones, fraude |
| Table | Key-value | Upgrade de Azure Table Storage: latencia garantizada, distribución global, índices en todo |
| PostgreSQL (Citus) | Postgres distribuido | Relacional con sharding horizontal nativo |
Request Units (RU/s) son la moneda de capacidad de Cosmos: 1 RU ≈ leer un item de 1 KB por id. Toda operación cuesta RUs. El throughput se aprovisiona (manual o autoscale) o se paga por uso (serverless). Las RUs se reparten uniformemente entre particiones físicas — por eso la partition key es LA decisión de diseño.
Partition key — criterios
Modos de throughput
| Nivel | Garantía | Escenario |
|---|---|---|
| Strong | Lecturas siempre ven la última escritura confirmada (linealizable) | Saldos bancarios, inventario crítico. Mayor latencia; escrituras multi-región limitadas |
| Bounded Staleness | Lag acotado: máximo K versiones o T segundos de retraso | Marcadores deportivos, precios de bolsa con retraso tolerado y acotado |
| Session (default) | Dentro de una sesión: lees tus propias escrituras | El default correcto para la mayoría de apps — perfil de usuario, carritos |
| Consistent Prefix | Nunca ves escrituras fuera de orden (pero puedes ver versiones viejas) | Feeds donde el orden importa más que la frescura |
| Eventual | Convergencia eventual, sin garantía de orden | Contadores de likes, retweets — máxima velocidad y disponibilidad |
Cómo memorizarlo
De Strong a Eventual: menos consistencia = menos latencia + más disponibilidad + menor costo de RU en lecturas. "Leer mis propias escrituras" → Session. "Retraso máximo de 5 segundos" → Bounded Staleness. "Nunca datos desordenados pero tolera antigüedad" → Consistent Prefix.
Single-region write + read replicas
Multi-region writes
Extras de diseño
| Servicio | Cuándo elegirlo sobre Cosmos |
|---|---|
| Azure Table Storage | Key-value simple, MUY barato, sin requisitos de latencia garantizada ni distribución global. Logs, metadata, configuraciones |
| Azure Cache for Redis | Cache in-memory sub-milisegundo DELANTE de otra DB (cache-aside), session store, pub/sub volátil. No es la base de datos primaria. Tiers: Basic (dev), Standard (HA), Premium (persistencia, clustering, geo-replication), Enterprise (módulos Redis Stack, activo-activo global) |
| Azure AI Search | Búsqueda full-text, facetas, vectores/semántica sobre datos de otros stores (indexers desde Cosmos/SQL/Blob) |
| Blob Storage | El objeto ES el dato (imágenes, vídeos, backups) — no necesita queries sobre su contenido |
| Requisito | Diseño |
|---|---|
| Usuarios globales escriben con latencia local | Cosmos multi-region writes (+ resolución de conflictos) |
| El usuario debe ver inmediatamente lo que él mismo escribió | Consistencia Session |
| Datos financieros: toda lectura ve la última escritura | Consistencia Strong (single region o regiones cercanas) |
| Multi-tenant SaaS, queries siempre filtran por tenant | Partition key = tenantId (o jerárquica tenantId/entityId) |
| Tráfico con picos x10 impredecibles | Throughput autoscale |
| Reaccionar a cada cambio de datos con una Function | Change feed + Azure Functions trigger |
| Migrar app MongoDB sin reescribir | Cosmos DB API for MongoDB |
| Key-value barato sin SLAs estrictos | Azure Table Storage |
| Cache de sesiones con latencia sub-ms | Azure Cache for Redis (Standard/Premium para HA) |
| Cache Redis con geo-replication o persistencia RDB/AOF | Azure Cache for Redis Premium |
| Analítica sobre datos operacionales sin consumir RUs | Analytical store + Synapse Link |
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una app global de e-commerce usa Cosmos DB (API NoSQL). Requisitos: los usuarios de Europa, Asia y América deben escribir con baja latencia en su propia región; un usuario debe ver siempre sus propias acciones recientes (su carrito actualizado); se toleran milisegundos de lag entre regiones. ¿Qué configuración eliges?
Inicia sesión para llevar tu progreso.