El Dominio 3 del temario oficial de DP-900 incluye "Identificar casos de uso de Azure Cosmos DB" y "Describir las API de Azure Cosmos DB". Las preguntas reales van un paso más allá y suelen preguntar cómo elegir una clave de partición, de qué dependen las unidades de solicitud (RU), si a una carga le conviene el modo sin servidor o el escalado automático y en qué se diferencian los cinco niveles de coherencia.
Este artículo es un complemento de Fundamentos de datos no relacionales de nuestra serie de estudio de DP-900. Toma las RU, las claves de partición, los niveles de coherencia y la lista de API que se presentaron allí y las amplía hasta el nivel que necesitas para las preguntas del examen, en este orden: estructura de recursos, diseño de particiones, modos de rendimiento, distribución global y coherencia, y cómo elegir una API.
---
¿Qué tipo de base de datos es Cosmos DB?
Imagina una cadena de tiendas de conveniencia con sucursales en todo el mundo. La lista de productos que fija la central se replica en todas las sucursales, así que los clientes compran en la más cercana. Azure Cosmos DB es una base de datos NoSQL totalmente administrada (PaaS) construida de la misma manera: los datos se replican en las regiones de Azure que elijas, y los usuarios leen y escriben en la réplica más cercana.
Cosmos DB no depende de un esquema. Los elementos de un mismo contenedor pueden tener distinto número de propiedades y distinta estructura, y de forma predeterminada todas las propiedades se indexan automáticamente, así que no tienes que definir de antemano un esquema ni índices. Los datos se organizan en una estructura de cuatro niveles.
| Nivel | Función | |------|------| | Cuenta | El recurso de Azure de nivel superior; fija la API, las regiones y la coherencia predeterminada | | Base de datos | Un espacio de nombres lógico que agrupa contenedores relacionados | | Contenedor | La unidad básica de almacenamiento y escalado; aquí se configuran la clave de partición, el rendimiento, la directiva de indexación y el TTL | | Elemento | Un dato individual; según la API se llama documento, fila, nodo o arista |
Cosmos DB encaja con aplicaciones que necesitan un esquema flexible, usuarios en todo el mundo y una latencia baja y constante. Ejemplos típicos son la ingesta de IoT y telemetría, los perfiles de jugadores y las clasificaciones en los juegos, los catálogos de productos y carritos de las tiendas en línea, y la personalización en aplicaciones web y móviles. En cambio, si necesitas JOIN complejos entre muchas tablas, encaja mejor Azure SQL Database, y para análisis a gran escala, Microsoft Fabric.
Consejo para el examen: "Respuestas de milisegundos de un solo dígito para usuarios de todo el mundo, datos JSON cuyo esquema cambia a menudo" → Cosmos DB. "Un sistema de pedidos con muchos JOIN entre tablas" → Azure SQL Database, no Cosmos DB.
---
Claves de partición: donde empieza el escalado
Los datos de un contenedor se dividen en particiones lógicas según el valor de la clave de partición. Los elementos con el mismo valor de clave forman una partición lógica, y Cosmos DB reparte las particiones lógicas entre particiones físicas internas para ampliar el almacenamiento y el rendimiento.
Una partición lógica puede guardar hasta 20 GB. Una partición física admite hasta 10 000 RU por segundo, así que una partición lógica tampoco puede superar ese límite. El rendimiento aprovisionado se reparte por igual entre las particiones físicas. Si las solicitudes se concentran en unas pocas particiones, estas se convierten en particiones calientes, y las solicitudes pueden limitarse (rate limiting) aunque sobre rendimiento en otras. Una vez elegida la clave de partición, no se puede cambiar sobre la marcha. Para cambiarla hay que crear un contenedor nuevo y mover los datos.
| Buena clave de partición | Mala clave de partición | |------|------| | Muchos valores distintos (ID de usuario, ID de dispositivo, ID de pedido) | Solo unos pocos valores (estado, tipo, país) | | El almacenamiento y las solicitudes se reparten por igual entre los valores | Los datos y las solicitudes se concentran en ciertos valores | | Aparece en los filtros de las consultas frecuentes | Cada consulta tiene que recorrer todas las particiones |
Si los datos de un solo valor de clave pueden superar los 20 GB, las claves de partición jerárquicas permiten apilar hasta tres niveles de claves (por ejemplo, ID de inquilino → ID de usuario) para repartir los datos de forma más uniforme.
Consejo para el examen: "La mejor propiedad para usar como clave de partición" → una con muchos valores distintos y bien repartidos. "Se rechazan solicitudes aunque sobre rendimiento, porque se concentran en unas pocas particiones" → partición caliente.
---
Unidades de solicitud (RU) y modos de rendimiento
Qué influye en el consumo de RU
Una unidad de solicitud (RU) es la moneda de rendimiento de Cosmos DB, que reúne CPU, IOPS y memoria en un solo número. Una lectura puntual de un elemento de 1 KB aproximadamente por su ID y su clave de partición cuesta 1 RU, y todas las operaciones, incluidas escrituras, consultas y eliminaciones, se miden en RU.
| Factor | Efecto en las RU | |------|------| | Tamaño del elemento | Los elementos más grandes cuestan más RU al leer y escribir | | Indexación | Todas las propiedades se indexan por defecto; excluir algunas reduce las RU de escritura | | Número de propiedades | Más propiedades cuestan más RU al escribir | | Nivel de coherencia | Strong y Bounded staleness usan aproximadamente el doble de RU en las lecturas | | Complejidad de la consulta | Más resultados, predicados y funciones cuestan más |
Modos de rendimiento
| Modo | Cómo funciona | Mejor encaje | |------|------|------| | Rendimiento aprovisionado (manual) | Reservas RU/s de antemano, dedicadas a un contenedor o compartidas a nivel de base de datos (hasta 25 contenedores) | Tráfico estable y predecible | | Escalado automático (autoscale) | Fijas un máximo de RU/s y se ajusta al instante entre el 10 % y el 100 % de ese valor | Tráfico con picos al que puedes poner un límite superior | | Sin servidor | No se aprovisiona nada; pagas las RU que consumes; solo cuentas de una región | Tráfico intermitente, impredecible y escaso, desarrollo y pruebas |
Por ejemplo, si fijas el máximo del escalado automático en 20 000 RU/s, el rendimiento se mueve entre 2000 y 20 000 RU/s. Las cuentas sin servidor no se pueden distribuir entre regiones, así que si necesitas distribución global debes usar rendimiento aprovisionado.
Consejo para el examen: "Una aplicación de desarrollo que se usa de vez en cuando, pagando solo por lo que se usa" → sin servidor. "Tráfico tranquilo casi siempre pero que se dispara en eventos, con un máximo de RU/s definido" → escalado automático. "Replicar en varias regiones" → no es posible con el modo sin servidor.
---
Distribución global y los cinco niveles de coherencia
Escrituras en varias regiones
Puedes añadir regiones de Azure a una cuenta en cualquier momento; los datos se replican automáticamente y los usuarios leen de la réplica regional más cercana. Si activas las escrituras en varias regiones, también las escrituras se atienden en la región más cercana. Las cuentas con escrituras en varias regiones tienen un SLA de disponibilidad del 99,999 %, y tanto las lecturas como las escrituras se garantizan por debajo de 10 milisegundos en el percentil 99.
Niveles de coherencia
Cuando las réplicas viven en varias regiones, hay que decidir cuándo se ve en las demás regiones un valor recién escrito. Cosmos DB ofrece este equilibrio en cinco niveles.
!Los cinco niveles de coherencia de Azure Cosmos DB
| Nivel | Qué garantiza | Analogía | |------|------|------| | Strong | Cada lectura refleja la escritura más reciente | Una emisión en directo | | Bounded staleness | Las lecturas van por detrás como mucho un tiempo o un número de versiones fijado | Una emisión con un retraso máximo de cinco minutos | | Session | Dentro de una sesión de cliente, lees al instante lo que escribiste | El comentario que publicas aparece enseguida en tu pantalla | | Consistent prefix | Las escrituras nunca llegan desordenadas, pero pueden no ser las últimas | Una reposición que llega capítulo a capítulo en orden | | Eventual | Todas las réplicas convergen con el tiempo; la máxima disponibilidad | Una postal que acaba llegando |
La coherencia predeterminada se fija por cuenta, y cada solicitud puede relajarla a un nivel más débil cuando haga falta. Session es el nivel más usado tanto en aplicaciones de una región como en las distribuidas globalmente.
Consejo para el examen: "Un usuario debe ver al instante el perfil que acaba de editar" → Session. "Las lecturas siempre deben devolver el valor más reciente" → Strong. "Máxima disponibilidad y mínima latencia, no importa leer valores algo atrasados" → Eventual. "Se acepta retraso, pero el orden nunca debe cambiar" → Consistent prefix.
---
Cómo elegir una API
La API se elige al crear la cuenta y determina el formato de datos, el lenguaje de consulta y las bibliotecas cliente que usa la aplicación. El almacenamiento interno es el mismo; la API funciona como una capa de abstracción encima.
| API | Modelo de datos | Lenguaje de consulta | Elígela cuando | |------|------|------|------| | NoSQL | Documentos JSON | Sintaxis similar a SQL | Es la opción predeterminada para aplicaciones nuevas; la API nativa (antes llamada SQL API) | | MongoDB | Documentos BSON | MongoDB Query Language (MQL) | Quieres seguir usando los controladores y la experiencia de MongoDB | | Table | Clave-valor | Búsquedas por clave al estilo OData | Migras una aplicación de Azure Table Storage que necesita más rendimiento y distribución global | | Apache Cassandra | Familia de columnas | CQL | Llevas una carga de trabajo existente de Cassandra a un servicio administrado | | Apache Gremlin | Grafo (vértices y aristas) | Gre