Desarrollo de soluciones con Azure Cosmos DB

Resumen de operaciones del SDK de Cosmos DB, los 5 niveles de consistencia, la fuente de cambios y el diseño de claves de partición.

Azure Cosmos DB es una base de datos NoSQL distribuida globalmente que permite leer y escribir datos rapidamente desde cualquier lugar del mundo. Para el examen AZ-204, los temas clave son las operaciones SDK, el diseno de clave de particion, los 5 niveles de coherencia, el feed de cambios y la programacion del lado del servidor.

 

SDK: Acceso a Datos a Traves de una Jerarquia

Al encontrarse por primera vez con el SDK de Cosmos DB, la cantidad de nombres de clases puede resultar confusa. Piense en el organigrama de una empresa para entenderlo mejor. Bajo la sede central (CosmosClient) hay departamentos (Database), bajo los departamentos hay equipos (Container), y cada miembro individual del equipo es un elemento (Item).

| Clase | Rol | Analogia | |-------|-----|---------| | CosmosClient | Se conecta a toda la cuenta de Cosmos DB | Central telefonica principal | | DatabaseProxy | Referencia a una base de datos especifica | Departamento especifico | | ContainerProxy | Referencia a un contenedor especifico | Equipo especifico | | ItemProxy | Documento individual (datos JSON) | Miembro individual del equipo |

Con el SDK, se usa una sola cadena de conexion y se navega por esta jerarquia para trabajar con los datos.

Patron Basico de Operaciones CRUD

Conectar: CosmosClient(endpoint, credential) Referencia de base de datos: client.get_database_client("mydb") Referencia de contenedor: db.get_container_client("mycontainer") Crear elemento: container.create_item(body={"id": "1", "pk": "user1", ...}) Leer elemento: container.read_item(item="1", partition_key="user1") Actualizar elemento: container.upsert_item(body={...}) Eliminar elemento: container.delete_item(item="1", partition_key="user1") Consulta: container.query_items(query="SELECT * FROM c WHERE c.type = 'order'", ...)

Cada operacion de lectura/escritura consume costo en RU (Request Unit). Leer un elemento de 1KB cuesta aproximadamente 1 RU; las escrituras consumen mas RUs.

 

Clave de Particion: El Criterio para Dividir los Datos

La clave de particion es la base que usa Cosmos DB para distribuir datos entre multiples servidores. Piense en una biblioteca. Si organiza los libros alfabeticamente, los libros que comienzan con ciertas letras se acumulan en un estante. Si los organiza por genero, se distribuyen uniformemente. Cosmos DB funciona de la misma manera.

Debe recordar las condiciones para una buena clave de particion.

| Condicion | Descripcion | Ejemplos | |-----------|-------------|---------| | Alta cardinalidad | Cuantos mas valores unicos, mejor | ID de usuario, ID de pedido | | Distribucion uniforme | Los datos no deben agruparse en valores especificos | Ciudad, Categoria | | Coincide con consultas | Debe coincidir con los campos que filtra frecuentemente | Campos usados en clausulas WHERE |

Tambien debe conocer ejemplos de malas claves de particion.

Fecha: Los datos se agrupan en fechas especificas (problema de particion caliente) Booleano: Solo verdadero/falso significa solo 2 particiones Categorias fijas: Muy pocos valores distintos concentran la carga en particiones especificas

Las claves de particion no pueden cambiarse despues de crear el elemento, asi que elija cuidadosamente durante el diseno inicial.

 

5 Niveles de Coherencia: Equilibrio Entre Velocidad y Precision

En una base de datos distribuida, los datos se replican en servidores de todo el mundo. Si escribe datos en Seoul, los mismos datos deben llegar a servidores en Tokio o Nueva York. El problema es que esta transferencia lleva tiempo. Los niveles de coherencia controlan el equilibrio entre "que tan actualizados estan los datos garantizados" y "que tan rapido responde".

Piense en las noticias de ultima hora. Cuando ocurre un evento, algunos medios informan despues de verificar para mayor precision, mientras que otros informan rapidamente pero corrigen despues.

| Nivel de Coherencia | Garantia | Rendimiento | Caso de Uso | |--------------------|---------|-------------|-------------| | Strong | Siempre garantiza datos mas recientes. Bloquea lecturas hasta que todas las replicas reflejen la escritura | Mas lento | Transacciones financieras, inventario | | Bounded Staleness | Garantiza datos dentro de K versiones o T segundos | Lento | Clasificaciones, sistemas de reserva | | Session | Dentro de la misma sesion, siempre lee sus propias escrituras (predeterminado) | Medio | Carrito de compras, perfil de usuario | | Consistent Prefix | Garantiza el orden pero no la actualidad | Rapido | Feeds sociales, comentarios | | Eventual | Eventualmente convergera, sin garantia inmediata | Mas rapido | Contadores de me gusta, contadores de vistas |

Los temas mas frecuentemente evaluados son que Session es el predeterminado y las caracteristicas de cada nivel.

!Los 5 niveles de consistencia de Cosmos DB

Feed de Cambios: Procesamiento de Eventos en Tiempo Real

El Feed de Cambios es una funcion que transmite en tiempo real los cambios que ocurren en un contenedor de Cosmos DB. Piense en el CCTV de una tienda de conveniencia. El momento en que alguien recoge un producto o paga se registra en tiempo real, y otros sistemas (gestion de inventario, seguridad) pueden procesarlo de inmediato.

Caracteristicas clave del feed de cambios que debe recordar.

Operaciones admitidas: Solo detecta inserciones (INSERT) y actualizaciones (UPDATE) Operaciones no admitidas: Las eliminaciones (DELETE) no se detectan de forma predeterminada (use TTL) Metodos de procesamiento: Desencadenador de Azure Functions, biblioteca Change Feed Processor Casos de uso: Notificaciones en tiempo real, aprovisionamiento de eventos, invalidacion de cache, canalizaciones de analisis

Integracion con Azure Functions

Usando un desencadenador de Cosmos DB, una funcion se ejecuta automaticamente cada vez que se agrega un nuevo elemento o se cambia uno existente en un contenedor. Por ejemplo, puede configurar un flujo de trabajo que decremente automaticamente el inventario en el momento en que llega un pedido.

 

Programacion del Lado del Servidor: Logica Ejecutandose Dentro de la Base de Datos

Cosmos DB admite tres mecanismos para ejecutar codigo directamente dentro del servidor de la base de datos. Como una linea de ensamblaje de fabrica, procesar datos donde viven elimina la necesidad de enviarlos por la red.

Procedimiento Almacenado

Agrupa multiples operaciones en una sola transaccion. Usando la transferencia bancaria como ejemplo, debitar la cuenta A y acreditar la cuenta B deben tener exito juntos o fallar juntos. Los procedimientos almacenados garantizan este comportamiento atomico.

Escritos en JavaScript La garantia de transaccion solo aplica dentro de la misma clave de particion Reversion completa en caso de fallo

Desencadenador (Trigger)

Codigo que se ejecuta automaticamente antes o despues de la creacion, modificacion o eliminacion de elementos.

Pre-desencadenador: Se ejecuta antes de que se guarde un elemento (validacion, normalizacion) Post-desencadenador: Se ejecuta despues de que se guarda un elemento (registro, envio de notificaciones)

UDF (Funcion Definida por el Usuario)

Una funcion personalizada que puede llamar dentro de consultas SQL. Por ejemplo, puede escribir una logica de calculo de impuestos como UDF y llamarla directamente desde consultas. No admite transacciones y es de solo lectura.

| Tipo | Transaccion | Momento de Ejecucion | Proposito | |------|-------------|----------------------|----------| | Procedimiento Almacenado | Admitida | Llamada explicita | Operacion atomica multiple | | Pre-desencadenador | No admitida | Antes de la operacion de escritura | Validacion, normalizacion | | Post-desencadenador | No admitida | Despues de la operacion de escritura | Registro, notificaciones | | UDF | No admitida | Llamada dentro de la consulta | Logica de calculo personalizada |

 

Puntos clave del examen

"CosmosClient -> Database -> Container -> Item" -- Jerarquia SDK (memorizar el orden)

"Usar fecha o booleano como clave de particion" -- Malos ejemplos (causa particion caliente)

"Alta cardinalidad + distribucion uniforme" -- Condiciones para buena clave de particion

"Nivel de coherencia predeterminado" -- Session

"Siempre garantiza datos mas recientes, mas lento" -- Strong

"Eventualmente coherente, mas rapido" -- Eventual

"Que detecta el feed de cambios" -- Solo inserciones y actualizaciones (eliminaciones no admitidas por defecto)

"Operacion atomica multiple, garantia de transaccion" -- Procedimiento almacenado

"Validacion antes de escritura" -- Pre-desencadenador

"Calculo personalizado dentro de consultas" -- UDF (sin soporte de transacciones)

Volver a la lista del blog