Microsoft AZ-204: Azure Cosmos DB — Guía de estudio

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Forma parte de la Microsoft Azure Developer Associate AZ-204 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Información general

Azure Cosmos DB es una base de datos multimodelo, totalmente administrada y distribuida globalmente, diseñada para aplicaciones de baja latencia y elásticamente escalables. Expone múltiples API sobre un motor común de almacenamiento y replicación particionado, proporciona cinco niveles de coherencia ajustables y ofrece SLA integrales de disponibilidad, latencia, rendimiento y coherencia. Los datos se organizan en cuentas, bases de datos y contenedores (o colecciones/tablas/grafos según la API). Los contenedores se particionan y escalan horizontalmente mediante una clave de partición, y todas las operaciones se miden en Unidades de Solicitud (RU), una moneda normalizada que abstrae la CPU, las IOPS y la memoria.

API y programabilidad

Cosmos DB admite varias API compatibles a nivel de protocolo (wire-compatible) para que pueda usar los SDK y controladores nativos sin reescribir su modelo de datos:

API de SQL (Core): La opción predeterminada recomendada para nuevas cargas de trabajo. Almacena documentos JSON con consultas enriquecidas de tipo SQL (SELECT, WHERE, ORDER BY, JOIN dentro de un documento, agregados) y UDF deterministas para predicados/proyecciones calculados. La lógica de negocio del lado del servidor se ejecuta como procedimientos almacenados de JavaScript y desencadenadores (triggers) pre/post dentro de una única partición lógica, lo que permite transacciones ACID sobre múltiples elementos que comparten la clave de partición. TransactionalBatch proporciona operaciones de múltiples elementos en una partición. Las lecturas de punto (id + clave de partición) son las más eficientes en cuanto a RU. Cree un cliente .NET con código como:

undefined

API de MongoDB: Compatible a nivel de protocolo con MongoDB, lo que permite el uso de controladores y herramientas estándar de MongoDB (por ejemplo, mongodump/mongorestore para migraciones). Puede usar las características de MongoDB respaldadas por la distribución, el autoescalado y los SLA de Cosmos DB. Se admiten transacciones de múltiples documentos dentro de la misma partición lógica; para una atomicidad estricta por usuario, use una colección no fragmentada (unsharded) o fragmente por una propiedad como username para que los documentos relacionados compartan una partición.
API de Cassandra: Compatible con los controladores de Apache Cassandra y CQL. Ideal para patrones de acceso de columna ancha y de series temporales. Obtiene distribución global automática y escalado basado en RU en lugar de la administración de nodos.
API de Gremlin: Modelo de grafo de propiedades con consultas y recorridos (traversals) de TinkerPop Gremlin. La partición es esencial para distribuir vértices y aristas para recorridos escalables.
API de Table: Clave-valor con SDK y semántica compatibles con Azure Table Storage, pero respaldada por la distribución global, el rendimiento de RU y los índices de menor latencia de Cosmos DB.

Las operaciones comunes del SDK en todas las API incluyen CRUD, concurrencia optimista con ETags, upserts, scripts del lado del servidor (procedimientos almacenados, desencadenadores) y UDF (API de SQL). Las consultas se parametrizan para reducir las RU y mejorar la seguridad. Las operaciones masivas (bulk) y las API de streaming minimizan la sobrecarga del cliente y los costos de RU para la ingesta de alto rendimiento.

Coherencia, indexación y semántica de consulta

Cosmos DB ofrece cinco niveles de coherencia bien definidos por cuenta (que se pueden anular por solicitud en muchos SDK):

Fuerte (Strong): Linealizabilidad: las lecturas ven la escritura confirmada más reciente a nivel global. Maximiza la corrección, limita la latencia de escritura y la flexibilidad regional, y no está disponible con las escrituras multirregión habilitadas.
Obsolescencia Acotada (Bounded Staleness): Las lecturas se retrasan con respecto a las escrituras como máximo K versiones o un tiempo T. Garantiza un orden de lectura y escritura monotónico; es una buena compensación para lecturas distribuidas globalmente que toleran un retraso acotado.
Sesión (Session) (predeterminado): Por sesión, garantiza lectura de sus propias escrituras (read-your-writes), que la escritura siga a la lectura (write-follows-reads) y lecturas monotónicas. Cada cliente mantiene un token de sesión; compartirlo entre nodos (por ejemplo, a través de las opciones de solicitud en el SDK) preserva la lectura de sus propias escrituras en esos nodos.
Prefijo Coherente (Consistent Prefix): Las lecturas nunca observan escrituras fuera de orden, pero pueden ver un prefijo del registro.
Eventual (Eventual): La más alta disponibilidad y la latencia más baja sin garantías de orden.

La indexación es automática y coherente de forma predeterminada para la API de SQL. Cada elemento y propiedad se indexa sin gestión de esquemas, por lo que las escrituras actualizan el índice inmediatamente (modo de indexación Consistent). Puede refinar la directiva de indexación para:

Excluir rutas grandes o con mucha carga de escritura para reducir los costos de escritura de RU.
Agregar índices compuestos para admitir ORDER BY eficientes en múltiples propiedades y consultas que combinan filtros y ordenación en diferentes propiedades.
Agregar índices espaciales para tipos GeoJSON (Point, LineString, Polygon, MultiPolygon) y consultar con funciones espaciales como ST_DISTANCE, ST_WITHIN y ST_INTERSECTS.

El modo de indexación también se puede establecer en None para contenedores optimizados para escritura que solo se leen por id/clave de partición. Las diferentes API exponen la indexación a través de sus paradigmas nativos (p. ej., construcciones de los controladores de MongoDB y Cassandra), pero todas aprovechan el motor de indexación subyacente de Cosmos.

Tenga en cuenta el tamaño del elemento y la forma de la consulta. La API de SQL impone un límite de tamaño de elemento (por ejemplo, 2 MB), y las consultas entre particiones, las proyecciones grandes y los predicados complejos aumentan el consumo de RU. Use proyecciones selectivas, filtros apropiados y consultas que tengan en cuenta la partición para minimizar el costo de RU.

Particionamiento y rendimiento (RUs)

Cosmos DB separa las particiones lógicas de las físicas:

Las particiones lógicas agrupan elementos por el valor de una clave de partición. Todos los elementos que comparten la misma clave participan juntos en lotes transaccionales y scripts del lado del servidor.
Las particiones físicas son gestionadas por el servicio y alojan muchas particiones lógicas. El rendimiento (RUs) y el almacenamiento se distribuyen entre las particiones físicas; las particiones lógicas “calientes” pueden crear un cuello de botella en el rendimiento de una partición física.

Elija una clave de partición eficaz con alta cardinalidad y una distribución de acceso uniforme a lo largo del tiempo. Las buenas claves se correlacionan con su ruta de acceso principal (por ejemplo, userId, deviceId, tenantId u orderId). Evite las claves de baja cardinalidad o agrupadas por tiempo que causan desequilibrio (por ejemplo, país, estado o día). Cuando ninguna propiedad individual es adecuada:

Use una clave sintética que concatene múltiples propiedades.
Añada un sufijo aleatorio o con hash para distribuir la carga entre las particiones, preservando al mismo tiempo la capacidad de consulta por prefijo o manteniendo una tabla de búsqueda.
Considere las claves de partición jerárquicas para combinar múltiples propiedades, lo que permite una mejor distribución y consultas de prefijo eficientes.

Modelos de rendimiento:

Rendimiento aprovisionado: Reserve RU/s en un contenedor o una base de datos (compartido por los contenedores secundarios). Rendimiento predecible con estabilidad de costos. Escale manualmente o a través de API/CLI.
Escalado automático (Autoscale): Establezca un máximo de RU/s; Cosmos DB escala elásticamente entre el 10 % y el 100 % de ese máximo según la carga. Se factura según el uso de RU por hora más alto; excelente para cargas de trabajo variables y picos desconocidos.
Sin servidor (Serverless): Sin RU/s aprovisionadas; pague por el consumo de RU de cada operación. Ideal para desarrollo, cargas de trabajo con picos o de bajo rendimiento sin una línea base predecible.

Las técnicas de optimización de RU incluyen lecturas de punto por id+clave de partición, consultas parametrizadas, proyecciones selectivas, desnormalización para reducir patrones similares a JOIN y el uso de la fuente de cambios (change feed) para vistas derivadas en lugar de consultas complejas entre contenedores. Use ETags con If-Match para el control de concurrencia y así evitar reintentos costosos en RUs. Monitoree las métricas de RU y la limitación de velocidad (throttling, HTTP 429) e implemente políticas de reintento con fluctuación (jitter) en los SDK.

Distribución global y fuente de cambios (Change Feed)

La distribución multirregional llave en mano de Cosmos DB te permite agregar o quitar regiones en cualquier momento. Todas las regiones son de lectura; habilitar las escrituras multirregionales permite escrituras concurrentes en todas partes con una latencia de lectura inferior a 10 ms en el percentil 99 en las regiones próximas. Los SDK de cliente deben configurarse con regiones preferidas para enrutar el tráfico localmente y realizar la conmutación por error (failover) de manera controlada. En .NET, proporciona las regiones preferidas a través de CosmosClientOptions ApplicationPreferredRegions (o el equivalente en otros SDK). Las escrituras multirregionales requieren una política de resolución de conflictos:

Última escritura gana (Last Write Wins): Usa una ruta de resolución de conflictos (por ejemplo, una marca de tiempo o una propiedad de versión). Si no se especifica, se puede usar la marca de tiempo del sistema.
Resolución personalizada: Usa un procedimiento almacenado de fusión (merge) para reconciliar conflictos de forma determinista.
Manual: Inspecciona la fuente de conflictos y resuélvelos explícitamente.

La fuente de cambios (change feed) proporciona un registro ordenado y de solo anexión (append-only) de los cambios por cada clave de partición lógica. Es ideal para:

Arquitecturas orientadas a eventos y CQRS (proyectando documentos en vistas optimizadas para lectura).
Canalizaciones de datos posteriores (ingesta en data lakes, indexación de búsqueda, invalidación de caché).
Analíticas y auditorías casi en tiempo real. Existen dos patrones principales de consumo:
Biblioteca del procesador de la fuente de cambios (Change Feed Processor): Procesamiento distribuido y tolerante a fallos que utiliza un contenedor de concesiones (leases) para equilibrar las particiones entre los trabajadores y escalar horizontalmente de forma segura.
Modelo de extracción (pull) con FeedIterator: Itera explícitamente sobre los cambios con una lógica de puntos de control (checkpointing) que tú controlas; segmenta el trabajo a través de FeedRange para paralelizar. Azure Functions ofrece un desencadenador (trigger) de Cosmos DB que encapsula el patrón del procesador para un procesamiento sin servidor (serverless). Puedes empezar desde el principio o desde «ahora», y la fuente de cambios de fidelidad total (full-fidelity) captura actualizaciones intermedias y eliminaciones para tener pistas de auditoría completas. Diseña tu contenedor de concesiones (leases) con un rendimiento (throughput) suficiente y elige manejadores (handlers) idempotentes para admitir reintentos y una entrega de al menos una vez (at-least-once).

Escenario de problema práctico

Spotify necesita ofrecer un servicio de personalización disponible globalmente que ingiera las interacciones de los usuarios en tiempo real, actualice las recomendaciones por usuario y sirva lecturas de baja latencia desde la región más cercana. Las escrituras pueden ocurrir desde clientes móviles en todo el mundo, y las actualizaciones de recomendaciones deben distribuirse (fan out) a los sistemas posteriores.

Elegir la API de Cosmos DB SQL (Core) con escrituras multirregionales

Por qué: La API Core ofrece capacidades de consulta enriquecidas y programabilidad del lado del servidor. Las escrituras multirregionales minimizan la latencia de escritura a nivel global y toleran la conmutación por error regional sin tiempo de inactividad para las escrituras.

Definir una clave de partición de alta cardinalidad y claves jerárquicas

Enfoque: Particionar por userId; para usuarios extremadamente activos, usar claves jerárquicas como [“userId”, “bucket”] donde bucket es un sufijo de hash.
Por qué: Distribuye uniformemente la carga de escritura y lectura, permite actualizaciones transaccionales por usuario y evita particiones calientes (hot partitions).

Configurar el rendimiento (throughput) de autoescalado en los contenedores principales

Por qué: El tráfico es diurno e impulsado por campañas; el autoescalado maneja picos de hasta el máximo de RU/s configurado, manteniendo el costo proporcional a la carga real.

Establecer la consistencia en Sesión (Session) a nivel de cuenta

Por qué: Los clientes móviles requieren leer sus propias escrituras (read-your-writes) para la experiencia del usuario sin las restricciones de latencia de la consistencia Fuerte (Strong). Los tokens de sesión son transportados por los clientes y la capa de puerta de enlace (gateway) para preservar la semántica de la sesión entre nodos.

Implementar el procesamiento de la fuente de cambios con Azure Functions y el Change Feed Processor

Enfoque: Crear una aplicación de Functions con un desencadenador (trigger) de Cosmos DB vinculado al contenedor de interacciones. Usar un contenedor de concesiones (leases) dedicado y habilitar múltiples instancias para paralelismo.
Por qué: Esto proporciona un procesamiento resiliente, escalable y de baja sobrecarga operativa (low-ops) para actualizar vistas materializadas (p. ej., un contenedor de recomendaciones) y para publicar eventos en Event Hubs para análisis de streaming.

Crear un contenedor de recomendaciones derivado con una política de indexación personalizada

Enfoque: Excluir de la indexación propiedades grandes y con muchas escrituras; agregar índices compuestos para (userId, score DESC) para soportar consultas TOP-K.
Por qué: Reduce los costos de RU de escritura al tiempo que permite búsquedas ordenadas eficientes para los feeds personalizados.

Habilitar la distribución global con regiones preferidas en los SDK

Enfoque: Agregar regiones en Norteamérica, Europa y APAC. Configurar CosmosClientOptions con ApplicationPreferredRegions según la región de despliegue de la aplicación.
Por qué: Asegura que las lecturas se sirvan localmente para una latencia inferior a 10 ms y que la conmutación por error (failover) sea transparente.

Configurar la resolución de conflictos y la observabilidad

Enfoque: Usar Última escritura gana (Last Write Wins) con un reloj lógico generado por el servidor (propiedad de versión) para actualizaciones idempotentes, y enrutar los conflictos a una cola de monitoreo para casos excepcionales.
Por qué: Garantiza una convergencia determinista bajo escrituras multirregionales concurrentes y proporciona visibilidad operativa.

Esta arquitectura ofrece lecturas y escrituras de baja latencia a nivel global, procesamiento de eventos resiliente a través de la fuente de cambios (change feed), autoescalado rentable y una semántica de consistencia robusta adecuada para cargas de trabajo de personalización.

← Azure Storage y Blob Storage · Todos los dominios · Soluciones de contenedores de Azure →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →