Azure Cosmos DB para tus aplicaciones con NoSQL

Azure Cosmos DB para tus aplicaciones con NoSQL Software Craftsman
Solution Architect @ AVANADE GitKraken Ambassador Azure & Development Versión 1.0.0, Febrero de 2025

2 2 Motivo de la elaboración de este documento (1/2)
En el mundo actual, donde la gestión y almacenamiento de datos juegan un papel crucial en el éxito de cualquier aplicación, contar con herramientas eficientes y escalables es fundamental. Azure Cosmos DB surge como una solución potente para manejar bases de datos NoSQL con alta disponibilidad, baja latencia y escalabilidad global. Sin embargo, su adopción y correcta implementación pueden resultar complejas sin una guía clara que ayude a comprender sus principios fundamentales y mejores prácticas. Este documento ha sido creado con el propósito de brindar una guía estructurada y accesible sobre Azure Cosmos DB, permitiendo a los profesionales comprender su funcionamiento, ventajas y casos de uso. A lo largo del documento, se explican conceptos clave, estrategias de diseño y optimización, así como ejemplos prácticos que faciliten su adopción en proyectos reales.

3 3 ¿A quién va dirigido este documento? Este documento
está dirigido a desarrolladores, arquitectos de software, administradores de bases de datos y profesionales de TI que buscan mejorar su conocimiento sobre bases de datos NoSQL y explorar cómo Azure Cosmos DB puede ser una herramienta valiosa en sus proyectos. Tanto aquellos que recién comienzan con bases de datos distribuidas como quienes desean optimizar sus implementaciones existentes encontrarán información útil y aplicable. Además, es ideal para equipos que trabajan en aplicaciones escalables, sistemas de alta disponibilidad o soluciones en la nube que requieren manejar grandes volúmenes de datos de manera eficiente. Con un enfoque práctico y detallado, este documento proporciona los conocimientos esenciales para que los profesionales puedan diseñar, implementar y administrar soluciones basadas en Azure Cosmos DB con confianza.

4 4 ¿Cómo está organizado este documento? • Introducción •
NoSQL ▪ Características. ▪ ¿Por qué NoSQL?. ▪ Mitos. ▪ Cuando usar una NoSQL. ▪ Bases de datos mixtas. ▪ La desnormalización. • Azure Cosmos DB ▪ Aspectos básicos. ▪ Multimodelo. ▪ Un vistazo rápido a Azure CosmosDB. ▪ API de NoSQL. ▪ Unidades de Solicitud (RU). ▪ Indexado. ▪ Particionado. ▪ Algunas características más. ▪ Casos de Uso. ▪ Mejores Prácticas de Rendimiento.

5 5 ¿Cómo está organizado este documento? • API MongoDB
▪ Introducción. ▪ Operaciones CRUD Básicas. ▪ Aspectos Avanzados. ▪ Administración y Seguridad. • Gremlin API ▪ Aspectos básicos. ▪ Aspectos Avanzados. • Cassandra API ▪ Aspectos básicos. ▪ Aspectos Avanzados. • Table API ▪ Aspectos básicos. ▪ Buenas Prácticas. • IA y Azure CosmosDB • Otras Integraciones • Anexos

6 6 Introducción (1/13) Desde distintos puntos de vistas Desarrollo
Azure Cosmos DB se presenta como una solución para desarrolladores que buscan construir aplicaciones modernas y escalables. Su capacidad para manejar grandes volúmenes de datos distribuidos globalmente sin comprometer el rendimiento es crucial en un mundo donde las aplicaciones deben estar siempre disponibles y ser altamente receptivas. La versatilidad de Cosmos DB, que admite múltiples modelos de datos como documentos, grafos y columnas, nos permite elegir el enfoque más adecuado a nuestras necesidades. Además, su integración con diversas APIs, como MongoDB y SQL, facilita la migración de aplicaciones existentes y la adopción de nuevas tecnologías sin una curva de aprendizaje pronunciada. Arquitectura Azure Cosmos DB ofrece una infraestructura robusta que simplifica el diseño de sistemas distribuidos. Su capacidad de distribución global automática y su escalabilidad elástica permite construir sistemas que no solo satisfacen las demandas actuales, sino que también pueden crecer y adaptarse a medida que cambian las necesidades del negocio. La gestión de consistencia personalizada en Cosmos DB permite equilibrar la latencia y la coherencia de los datos, lo que es fundamental para diseñar arquitecturas resilientes que puedan operar eficientemente incluso bajo alta carga y en múltiples ubicaciones geográficas.

7 7 Introducción (2/13) Negocio Desde una perspectiva empresarial, Azure
Cosmos DB representa una oportunidad para innovar y responder rápidamente a las demandas del mercado. Su modelo de precios basado en el consumo permite a las empresas optimizar costos al escalar solo cuando es necesario, lo que puede resultar en ahorros significativos. La capacidad de Cosmos DB para ofrecer alta disponibilidad y tiempos de respuesta rápidos en cualquier parte del mundo mejora la experiencia del cliente y, por ende, la satisfacción. Además, su integración con el ecosistema de Azure facilita la implementación de soluciones de analítica avanzada y aprendizaje automático, permitiendo a las empresas obtener valiosos insights y mantenerse competitivas. Operación y Mantenimiento Azure Cosmos DB simplifica la gestión y el mantenimiento de bases de datos distribuidas. Su administración totalmente gestionada reduce la carga de trabajo del personal de TI, al encargarse automáticamente de las actualizaciones, el monitoreo y las copias de seguridad, permitiendo al equipo enfocarse en tareas más estratégicas. La capacidad de ajustar el rendimiento y la capacidad de almacenamiento de manera dinámica también ayuda a las operaciones a ser más eficientes, respondiendo rápidamente a las fluctuaciones en la carga de trabajo sin necesidad de intervención manual. Además, las herramientas de monitoreo y diagnóstico proporcionadas por Azure permiten una visibilidad completa del rendimiento del sistema, facilitando la identificación y resolución de problemas antes de que afecten a los usuarios finales.

8 8 Introducción (3/13) ¿Por qué Azure Cosmos DB? Ofrece
varias ventajas competitivas frente a otras soluciones de bases de datos NoSQL, como Amazon DynamoDB y Apache Cassandra: Modelo Multi-API Azure Cosmos DB admite múltiples modelos de datos a través de diferentes APIs (SQL, MongoDB, Gremlin, Cassandra, Table) que veremos más adelante. Esto permite a las organizaciones elegir el modelo que mejor se adapte a sus necesidades sin tener que cambiar de plataforma. Esta flexibilidad no es común en todas las soluciones NoSQL. Distribución Global Integrada La capacidad de distribuir datos globalmente con solo unos pocos clics y la replicación automática en múltiples regiones de Azure permiten a las aplicaciones ofrecer tiempos de respuesta bajos y alta disponibilidad a escala global. Esta facilidad de configuración y gestión de la distribución global es un diferenciador clave frente a otras soluciones que requieren una configuración más manual.

9 9 Introducción (4/13) Consistencia Configurable Azure Cosmos DB ofrece
cinco niveles de consistencia predefinidos, desde fuerte hasta eventual, lo que permite a las aplicaciones optimizar entre latencia y consistencia de acuerdo con sus necesidades específicas. Esta granularidad en la consistencia no está disponible en todas las plataformas. Latencia Bajísima Garantizada Cosmos DB ofrece latencias de lectura y escritura inferiores a 10 milisegundos, con un SLA que garantiza este rendimiento. Esta garantía de baja latencia es particularmente atractiva para aplicaciones que requieren alta velocidad de acceso a datos. Nota del autor SLA de latencia de Azure Cosmos DB: • Azure Cosmos DB garantiza una latencia de menos de 10 ms para lecturas y menos de 15 ms para escrituras en el 99% de los casos (para cargas de trabajo de menos de 1 KB de tamaño). • Esto se aplica cuando los datos están en la misma región que la aplicación. • Cosmos DB ofrece latencia de un solo dígito en milisegundos para operaciones puntuales (lecturas/escrituras) en regiones distribuidas globalmente. SLA de Amazon DynamoDB: • DynamoDB no tiene un SLA explícito de latencia en milisegundos, pero está diseñado para ofrecer latencia de un solo dígito en milisegundos para la mayoría de las operaciones. • El rendimiento depende de la configuración de la capacidad (modo bajo demanda o provisionado) y de la proximidad de la región. • DynamoDB se enfoca en alta disponibilidad y escalabilidad, pero no garantiza un número específico de milisegundos en su SLA.

10 10 Introducción (5/13) Modelo de Precios Basado en Consumo
El modelo de precios basado en unidades de solicitud por segundo (RU/s) permite una gestión de costos más precisa y predecible, especialmente para aplicaciones con patrones de carga variables. Esto puede ser más económico y flexible en comparación con modelos de precios basados en capacidad fija. Integración Nativa con Azure La integración profunda con el ecosistema de Azure facilita a las empresas que ya usan servicios de Azure la incorporación de Cosmos DB en sus soluciones existentes, aprovechando características como Azure Functions, Azure Machine Learning y más. Nota del autor Calcular las Unidades de Solicitud por Segundo (RU/s) en Azure Cosmos DB es un paso esencial para dimensionar adecuadamente una base de datos y garantizar el rendimiento deseado. No obstante, es crucial reconocer que estas estimaciones suelen ser aproximadas y pueden no reflejar con precisión la realidad una vez que la aplicación se encuentra en producción. ¿Por Qué las Estimaciones de RU/s Pueden Ser Inexactas? Un ejemplo típico ilustra esta situación: inicialmente, puedes estimar que una operación de escritura consume 5 RU y que necesitas realizar 1000 escrituras por segundo. Basándote en esto, calculas que requerirás 5000 RU/s para manejar la carga. Sin embargo, al poner la aplicación en producción, podrías descubrir que: • Las operaciones de escritura resultan ser más complejas de lo previsto, consumiendo 10 RU cada una. • Además, los usuarios realizan consultas adicionales no contempladas inicialmente, lo que incrementa la carga total. En este escenario, el consumo real de RU/s sería considerablemente mayor al estimado, lo que podría derivar en un rendimiento inferior al esperado o en la necesidad de incrementar rápidamente el aprovisionamiento de RU/s, lo que a su vez generaría costos adicionales.

11 11 Introducción (6/13) Comparación con sus rivales más directos
Característica Azure Cosmos DB Amazon DynamoDB Apache Cassandra Modelo de Datos Multi-modelo (documentos, grafos, columnas, KV) Clave-valor/Documentos Columnar Distribución Global Integrada, con replicación automática Manual, mediante réplicas globales Manual, mediante configuraciones de clúster Escalabilidad Escalabilidad horizontal automática Escalabilidad horizontal automática Escalabilidad horizontal manual Consistencia Varios niveles (fuerte, eventual, etc.) Eventual con consistencia fuerte opcional Configurable (Eventual por defecto) Modelo de Precios Basado en RU/s (Request Units per second) Basado en capacidad y solicitudes Basado en la infraestructura utilizada Gestión Totalmente gestionado Totalmente gestionado Autogestionado o servicios gestionados Integración con Ecosistema Profunda integración con servicios de Azure Integración con servicios de AWS Integración con herramientas de Apache APIs Soportadas SQL, MongoDB, Gremlin, Cassandra, Table API API nativo de DynamoDB CQL (Cassandra Query Language) Latencia <10 ms para operaciones de lectura y escritura <10 ms para lecturas y escrituras con SSDs Depende del diseño del clúster Seguridad Cifrado en reposo y en tránsito, RBAC Cifrado en reposo y en tránsito, IAM Cifrado en reposo (depende de la implementación)

12 12 Introducción (7/13) ¿Qué modelo escoger de bases de
datos? Aunque este diagrama de decisión no es infalible, si que ayuda a escoger entre distintos tipos de bases de datos:

13 13 Introducción (8/13) Otros Tipos de Bases de Datos
Además de las bases de datos relacionales, NoSQL y de grafos, existen otros tipos de bases de datos que podrías considerar según tus necesidades específicas: • Bases de Datos en Memoria: Como Redis, diseñadas para proporcionar acceso rápido a datos almacenados en la memoria RAM. • Bases de Datos Orientadas a Objetos: Almacenan datos en forma de objetos, similar a cómo se manejan en la programación orientada a objetos. • Bases de Datos de Series Temporales: Como InfluxDB, optimizadas para manejar datos que cambian con el tiempo, como lecturas de sensores. • Bases de Datos Multimodelo: Capaces de soportar múltiples modelos de datos, como ArangoDB, que pueden manejar documentos, grafos y datos clave-valor en una sola base de datos. Elegir una base de datos, es fundamental considerar no solo la estructura de los datos, sino también los requisitos específicos de tu aplicación, como la necesidad de transacciones ACID, escalabilidad, y el tipo de consultas que se realizarán.

14 14 Introducción (9/13) Conceptos Este documento no tiene como
objetivo aclarar conceptos como ACID, por ejemplo. Sin embargo, para evitar que esta definición se repita a lo largo del texto, quienes no estén familiarizados con el término deben continuar leyendo, mientras que aquellos que ya lo conocen pueden pasar a la siguiente sección. ACID Es un conjunto de propiedades que garantizan que las transacciones de bases de datos se procesen de manera fiable. Estas propiedades son: • Atomicidad: Una transacción es una unidad indivisible. Esto significa que todas las operaciones dentro de una transacción deben completarse con éxito; si alguna falla, ninguna de ellas se aplica. • Ejemplo: Al transferir dinero de una cuenta bancaria a otra, la deducción de una cuenta y el abono en otra deben ocurrir ambos o ninguno. • Consistencia: Una transacción debe llevar la base de datos de un estado válido a otro estado válido, manteniendo las reglas definidas (como restricciones, triggers, etc.). • Ejemplo: Si una regla de negocio dice que el saldo de una cuenta no puede ser negativo, cualquier transacción que intente dejar el saldo negativo será rechazada.

15 15 Introducción (10/13) • Aislamiento: Las transacciones concurrentes no
deben interferir entre sí. El resultado debe ser el mismo que si las transacciones se ejecutaran secuencialmente. • Ejemplo: Si dos personas intentan comprar la última entrada disponible para un concierto al mismo tiempo, solo una transacción debe completarse exitosamente. • Durabilidad: Una vez que una transacción ha sido confirmada, sus cambios son permanentes, incluso en caso de fallos del sistema. • Ejemplo: Si el sistema se apaga abruptamente después de completar una transacción, los cambios realizados por la transacción permanecen al reiniciar el sistema. MySQL, PostgreSQL, Microsoft SQL Server y Oracle cumplen estas características. BASE BASE es un enfoque más flexible, diseñado para sistemas distribuidos que requieren alta disponibilidad: • Básicamente Disponible: El sistema garantiza que siempre estará disponible para recibir solicitudes, incluso si no puede garantizar que todas las solicitudes sean consistentes. • Ejemplo: Imagina un sistema de compras en línea que utiliza una base de datos distribuida. Incluso si un nodo específico está caído, los usuarios aún pueden navegar por los productos y realizar compras, porque otros nodos están disponibles para manejar las solicitudes.

16 16 Introducción (11/13) • Estado Suave: El estado del
sistema puede cambiar con el tiempo, incluso sin nuevas entradas, debido a la naturaleza asincrónica de la replicación de datos entre nodos. • Ejemplo: Considera una red social donde las publicaciones de los usuarios se replican en varios servidores. Inicialmente, una publicación nueva puede no aparecer en todos los servidores, pero a medida que los datos se replican, el estado de cada servidor cambia hasta que todos tienen una copia actualizada de las publicaciones. • Consistencia Eventual: A lo largo del tiempo, y sin actualizaciones adicionales, los datos en todos los nodos se propagarán y alcanzarán un estado consistente. • Ejemplo: En un sistema de mensajería instantánea, un mensaje enviado por un usuario puede no aparecer inmediatamente en todos los dispositivos del destinatario. Sin embargo, el sistema asegura que, eventualmente, todos los dispositivos del destinatario recibirán el mensaje, alcanzando así la consistencia eventual. Azure Cosmos DB, Amazon DynamoDB, Apache Cassandra o Couchbase cumplen estas características.

17 17 Introducción (12/13) Teorema de CAP Nos sugiere que
todo sistema distribuido de almacenamiento de datos es vulnerable a fallos de conectividad de red, por lo que, frente al nivel de tolerancia de la partición de los nodos, tendrá que realizar algún tipo de concesión entre el acceso a la información o su versión más reciente. Presentado por Eric Brewer en el año 2000 y su nombre se base en los tres atributos: • C, consistency, se refiere a la lectura coherente del valor actual de l dato desde cualquier instancia, es decir, que los datos e encuentran sincronizados y replicados en todos los nodos a la vez • A, aviability, se refiere a obtener una respuesta validad y rápida para todas las solicitudes, aunque existan nodos inactivos, es decir el acceso ininterrumpidos a datos. • P, partition tolerance, se refiere a la capacidad del sistema para permanecer estable y continuar procesando solicitudes a pesar de ocurrir una interrupción (partición) entre comunicaciones de los nodos. El teorema de CAP nos da tres opciones de combinación de pares de atributos que pueden darse al mismo tiempo: CA, AP y CP, nunca los tres:

18 18 Introducción (13/13) • CA: Consistencia y Disponibilidad -
garantiza el acceso a la información y el valor del dato es consistente (igual) para todas las peticiones; de haber cambios, se mostrarán inmediatamente. Sin embargo, la partición de los nodos no es tolerada por el sistema de forma simultánea. • AP: Disponibilidad y Tolerancia a la partición - garantiza el acceso a los datos y el sistema es capaz de tolerar (gestionar) la partición de los nodos, pero dejando en segundo plano la consistencia de los datos, ya que no se conserva y el valor de dato no estará replicado en los diferentes nodos al instante. • CP: Consistencia y Tolerancia a la partición - garantiza la consistencia de los datos entre los diferentes nodos y la partición de los nodos se tolera, pero sacrificando la disponibilidad de los datos, con lo cual, el sistema puede fallar o tardar en ofrecer una respuesta a la petición del usuario. Aviability Hbase, MongoDB, Redis Partition Tolerance Consistency Cassandra, CouchDB RDBMSs, Greenplum

19 19 NoSQL (1/21) Características Modelo de Datos No Relacional
Una de las principales diferencias entre bases de datos relacionales y NoSQL es su modelo de datos. Mientras que las bases de datos relacionales (RDBMS) almacenan datos en tablas organizadas en filas y columnas, las bases de datos NoSQL ofrecen una variedad de modelos de datos que se ajustan mejor a diferentes tipos de aplicaciones y necesidades. Estas son algunas de las opciones comunes: • Modelo de Documentos: Utiliza documentos (a menudo en formato JSON, BSON o XML) como su almacenamiento de datos. Cada documento puede tener un esquema diferente, lo que proporciona una flexibilidad significativa. Ejemplos MongoDB y CouchDB. { "title": "El Señor de los Anillos", "author": "J.R.R. Tolkien", "published_year": 1954, "genres": ["Fantasía", "Aventura"], "inventory": { "warehouse1": 100, "warehouse2": 50 } }

20 20 NoSQL (2/21) • Modelo de Grafos: Diseñado para
manejar relaciones complejas entre datos. Utiliza nodos, aristas y propiedades para representar y almacenar información. Es ideal para aplicaciones que implican redes sociales, recomendaciones y análisis de relaciones. Ejemplos Neo4j y Azure Cosmos DB con Gremlin API. • Modelo de Columnas: Optimizado para operaciones de lectura y escritura frecuentes. Los datos se almacenan en columnas en lugar de filas, lo que permite un acceso eficiente a grandes volúmenes de datos. Es útil en aplicaciones de análisis de grandes datos y almacenamiento de datos. Ejemplos Apache Cassandra y Apache HBase. • Modelo de Clave-Valor: La forma más simple de base de datos NoSQL. Los datos se almacenan como pares clave-valor, donde la clave es un identificador único y el valor es el dato correspondiente. Es altamente eficiente y rápido para operaciones de lectura y escritura simple. Ejemplos incluyen Redis, Valkey o Microsoft Garnet. [User: Ana] – friend of –> [User: Juan] [User: Ana] – works for –> [Employee: Acme] [User: Juan] – interested in –> [Interest: Ciclismo] EmployeeID | 2025-01 | 2025-02 | ... -------------------------------------------- 001 | 8 | 6 | ... 002 | 5 | 7 | ... "user_101": {"theme": "dark", "language": "es", "notifications": "enabled"} "user_102": {"theme": "light", "language": "en", "notifications": "disabled"}

21 21 NoSQL (3/21) Escalabilidad Horizontal Una de las características
más atractivas de las bases de datos NoSQL es su capacidad para escalar horizontalmente, a diferencia de las bases de datos relacionales que generalmente escalan verticalmente (mejorando el hardware del servidor). La escalabilidad horizontal implica agregar más nodos (servidores) para distribuir la carga de trabajo y el almacenamiento de datos. Esto se logra mediante la fragmentación (sharding), donde los datos se dividen en diferentes nodos para balancear la carga y ofrecer alta disponibilidad. • Fragmentación (Sharding): Los datos se particionan horizontalmente en segmentos llamados shard. Cada shard contiene una parte de la base de datos y puede residir en un nodo diferente. Esto permite distribuir eficazmente la carga de trabajo e incrementar la capacidad total de almacenamiento y procesamiento. • Ejemplo: En una tienda en línea con clientes globales, podrías dividir (fragmentar) tus datos por región geográfica, donde el Nodo 1 es para Clientes de América, el Nodo 2 para Clientes de Europa, etc. • Replicación: Los datos se replican en múltiples nodos para asegurar la disponibilidad y durabilidad. En caso de falla de un nodo, otro nodo replicado puede asumir las operaciones sin pérdida de datos. • Ejemplo: En un blog donde la disponibilidad es crítica, cada artículo puede estar replicado en tres nodos diferentes, donde el Nodo 1 es el Nodo principal, el Nodo 2 es Nodo réplica 1 y Nodo 3 es Nodo réplica 2. Si el nodo principal falla, uno de los nodos réplica puede continuar sirviendo las solicitudes.

22 22 NoSQL (4/21) Flexibilidad de Esquema A diferencia de
las bases de datos relacionales que requieren un esquema predefinido y rígido (estructuras de tablas, tipos de datos, relaciones), las bases de datos NoSQL permiten mayor flexibilidad de esquema. Esta flexibilidad es crucial para aplicaciones que experimentan cambios frecuentes en sus requisitos de datos. • Esquema Flexible (o Sin Esquema): No se requiere definir un esquema fijo. Nuevos campos se pueden agregar sin afectar otras partes de la base de datos. Esto facilita agregar nuevas características y adaptarse a necesidades cambiantes sin necesidad de cambios estructurales complejos. • Ejemplo: En una aplicación de seguimiento de pedidos, diferentes tipos de productos pueden tener diferentes atributos (order_id 1 y 2). • Ajustes Dinámicos: Las aplicaciones pueden evolucionar rápidamente, y el modelo de NoSQL permite a los desarrolladores ajustar la estructura de los datos conforme se descubren nuevas necesidades o se experimentan con nuevas funcionalidades. • Ejemplo: Si necesitas agregar un nuevo atributo a los datos del producto, como 'fecha de lanzamiento', simplemente puedes agregarlo a los nuevos documentos sin afectar los existentes (order_id 3). { "order_id": 1, "product": { "type": "Electronics", "details": { "brand": "Sony", "model": “PS5", } } } { "order_id": 2, "product": { "type": "Book", "details": { "author": "J.K. Rowling", "title": "Harry Potter", } } } { "order_id": 3, "product": { "type": "Electronics", "details": { "brand": “Microsoft", "model": “XBOX S", "release_date": "2020-09-15" } } }

23 23 NoSQL (5/21) Alto Rendimiento y Disponibilidad Las bases
de datos NoSQL están diseñadas para ofrecer alto rendimiento y disponibilidad continua, especialmente en entornos de producción donde se requiere mantener las operaciones en marcha a pesar de fallas en el sistema. • Rendimiento Mejorado: Están optimizadas para operaciones de gran volumen de lectura y escritura. Muchas bases de datos NoSQL utilizan mecanismos de almacenamiento en memoria y estrategias de optimización personalizada para llevar a cabo operaciones rápidamente. • Ejemplo: En una aplicación de comercio electrónico, las operaciones de lectura y escritura de los carritos de compra deben ser rápidas y eficientes. Utilizando un modelo de clave-valor. • Alta Disponibilidad: Implementan técnicas de replicación y tolerancia a fallos para asegurar que la base de datos siga funcionando incluso en caso de fallos de hardware. La replicación asegura que varias copias de los datos se mantengan en diferentes nodos para prevenir la pérdida de datos y asegurar el continuo acceso. • Ejemplo: En un sistema de monitoreo en tiempo real para una red de sensores, la alta disponibilidad es crucial. Los datos pueden ser replicados en múltiples nodos para asegurar que siempre haya acceso a las últimas lecturas. "cart_101": {"items": ["product_1", "product_2"], "total": 150.00} "cart_102": {"items": ["product_3"], "total": 45.00} Nodo 1: [Sensor Data] Nodo 2: [Replica 1 de Sensor Data] Nodo 3: [Replica 2 de Sensor Data]

24 24 NoSQL (6/21) Capacidad par Manejar Datos No Estructurados
Las aplicaciones modernas generan una gran cantidad de datos no estructurados y semi-estructurados (datos que no siguen una estructura rígida de tabla). Las bases de datos NoSQL son especialmente eficaces en la gestión de estos tipos de datos. • Datos No Estructurados: Incluyen contenido multimedia, archivos de texto, logs, y datos de sensores entre otros. NoSQL proporciona almacenamiento y acceso eficiente a estos diferentes tipos de datos sin necesidad de conversión preliminar a un formato tabular. • Ejemplo: en una aplicación de almacenamiento de videos, cada video puede almacenarse junto con metadatos descriptivos en un modelo de documentos. • Datos Semi-Estructurados: Como los documentos JSON que contienen datos jerárquicos y anidados que pueden variar en estructura. Las bases de datos NoSQL manejan estos datos de forma natural, permitiendo consultas ricas y flexibles. • Ejemplo: Imagina un sistema de análisis de registros de servidores donde cada registro puede variar en estructura.

25 25 NoSQL (7/21) ¿Por qué NoSQL? A continuación, describo
algunas de las principales motivaciones para optar por NoSQL: • Alto Volumen de Datos: Las aplicaciones modernas generan grandes cantidades de datos a una velocidad vertiginosa. NoSQL puede manejar esta ingente cantidad de datos mediante la fragmentación (sharding) y escalabilidad horizontal. Esta capacidad permite administrar volúmenes de datos que una base de datos relacional tradicional podría tener dificultades para procesar eficientemente. • Aplicaciones Web y Móviles: Estas aplicaciones suelen tener patrones de tráfico impredecibles y requieren tiempos de respuesta rápidos. Las bases de datos NoSQL pueden distribuir eficientemente las cargas y proporcionar resultados rápidos. Además, muchas de estas bases de datos están diseñadas para ser fáciles de replicar, lo que mejora la disponibilidad y la tolerancia a fallos. • Cambio de Requisitos: Los proyectos de desarrollo de software a menudo requieren modificaciones rápidas y cambios en el esquema de datos. NoSQL ofrece la flexibilidad necesaria para ajustarse rápidamente. Las bases de datos NoSQL, al no estar restringidas por esquemas rígidos, permiten a los desarrolladores adaptarse a nuevos requisitos de manera ágil sin interrumpir las operaciones existentes.

26 26 NoSQL (8/21) • Desempeño: Algunas implementaciones de NoSQL
están optimizadas para brindar un rendimiento superior para operaciones específicas, tales como escrituras masivas o consultas de baja latencia. Por ejemplo, bases de datos orientadas a columnas y orientadas a documentos pueden ofrecer ventajas significativas en cuanto a velocidad y eficiencia en comparación con sus contrapartes relacionales. • Variedad de Datos: La capacidad de manejar datos semi-estructurados y no estructurados, como logs, datos de sensores, datos de redes sociales, y otros, hacen de las bases de datos NoSQL una solución adecuada para una vasta gama de aplicaciones. Esta flexibilidad en la gestión de datos permite a las organizaciones recopilar y analizar información significativa de diversas fuentes sin necesidad de convertir todos los datos a un formato estructurado específico. Caso de Uso de NoSQL Aplicación de Redes Sociales Una red social moderna como LinkedIn, X o Instagram maneja una cantidad masiva de datos de usuarios, contenido multimedia, interacciones y actividades en tiempo real. Las características de este tipo de aplicaciones incluyen: • Gran Escalabilidad y Alto Volumen de Datos: Las redes sociales deben soportar millones de usuarios activos cada día, generando gigabytes o terabytes de datos a través de publicaciones, comentarios, likes, shares, y otra actividad de usuario. • Datos Semi-Estructurados y No Estructurados: Una red social maneja una variedad de tipos de datos, desde texto en publicaciones hasta imágenes y vídeos, pasando por enlaces y metadatos. Los datos no siguen un esquema fijo y pueden cambiar con cada nueva característica introducida en la plataforma. • Requerimientos de Baja Latencia: Los usuarios esperan recibir notificaciones, actualizaciones de estado y contenido en tiempo real. La latencia debe ser mínima para proveer una experiencia de usuario fluida e inmediata. • Flexibilidad en el Esquema: Con actualizaciones frecuentes en las funcionalidades y características, la estructura de los datos puede cambiar rápidamente. NoSQL permite modificaciones en el esquema sin necesidad de una rigidez estructural que ralentice la innovación.

27 27 NoSQL (9/21) Por qué debemos usar una base
de datos NoSQL: • Escalabilidad Horizontal: Las bases de datos NoSQL pueden escalar fácilmente al añadir más servidores, lo cual es crucial para manejar el creciente volumen de datos y la cantidad de usuarios. • Flexibilidad de Esquema: La estructura flexible de NoSQL permite adaptarse rápidamente a nuevos tipos de datos y cambios en las funcionalidades de la aplicación. • Alto Rendimiento: Las bases de datos NoSQL están optimizadas para lectura y escritura rápidas, pudiendo manejar grandes volúmenes de transacciones por segundo. Caso Donde Usar una Base de Datos Relacional es Ineficiente Logging y Monitorización en Tiempo Real en Infraestructura de TI Las soluciones de logging y monitorización generan vastas cantidades de datos a partir de diversos servidores, aplicaciones y dispositivos de red. Estas herramientas deben capturar y analizar logs en tiempo real para identificar y solucionar problemas rápidamente. • Alto Volumen y Velocidad: Se generan cientos de millones de registros de logs cada día, capturando eventos de servidores, aplicaciones y dispositivos en tiempo real. • Estructura Variable: Los logs pueden variar en estructura y tamaño, dependiendo del tipo de sistema o aplicación que los genera. Pueden incluir diferentes campos, dependiendo del contexto. • Consultas y Análisis en Tiempo Real: La capacidad de realizar consultas rápidas y análisis en tiempo real sobre grandes volúmenes de datos es esencial para detectar anomalías y problemas de rendimiento. Por qué No debemos usar una base de datos Relacional: • Desempeño con Gran Volumen: Una base de datos relacional tendría dificultades para manejar la ingesta en tiempo real de millones de registros debido a la necesidad de estructurar y mantener un esquema riguroso. • Flexibilidad del Esquema: La estructura fija de una base de datos relacional no se adapta bien a la naturaleza variable de los datos de logs, requiriendo ajustes constantes al esquema y afectando el rendimiento. • Costes de Escalabilidad: Escalar verticalmente una base de datos relacional para manejar este tipo de carga es costoso y complicado, a medida que la cantidad de datos y la necesidad de procesamiento aumentan.

28 28 NoSQL (10/21) Mitos A pesar de las claras
ventajas de las bases de datos NoSQL, existen varios mitos y malentendidos comunes que pueden desalentar su adopción o distorsionar su percepción. A continuación, desglosamos y aclaramos algunos de estos mitos: "NoSQL No es Madura" • Mito: Existe la percepción de que las bases de datos NoSQL son una tecnología inmadura y no probada. • Realidad: Muchas soluciones NoSQL han sido probadas en producción y son utilizadas por gigantes tecnológicos como Google, Amazon, Facebook y X. Por ejemplo, Google Bigtable, el sistema de almacenamiento detrás de muchos servicios de Google ha estado en uso desde 2005. Amazon DynamoDB, otro ejemplo, es una solución NoSQL que Amazon ha estado utilizando internamente antes de ofrecerla como un servicio comercial. • Ejemplo: Google utiliza Bigtable para aplicaciones como Gmail y Google Earth, mientras que Amazon DynamoDB es fundamental para Amazon.com, manejando la carga de millones de transacciones por segundo durante eventos de alto tráfico como Prime Day.

29 29 NoSQL (11/21) "NoSQL Es Solo para Grandes Empresas"
• Mito: Existe la creencia de que NoSQL es adecuado únicamente para grandes empresas con necesidades de gran escala. • Realidad: NoSQL también es adecuado para startups y pequeñas empresas debido a su capacidad de escalar según sea necesario y su flexibilidad. Las bases de datos NoSQL pueden comenzar a una escala pequeña y crecer con la empresa. • Ejemplo: Startups como Airbnb y Uber comenzaron con bases de datos NoSQL para poder acomodar el rápido crecimiento y la variabilidad en los patrones de uso. MongoDB y Cassandra son ejemplos de bases de datos NoSQL que se pueden escalar fácilmente desde pequeños proyectos hasta grandes despliegues en producción. "NoSQL No Garantiza Consistencia" • Mito: Se cree que las bases de datos NoSQL no pueden ofrecer consistencia debido a su enfoque en la disponibilidad y la partición, basado en el Teorema CAP. • Realidad: Muchas bases de datos NoSQL ofrecen opciones de configuración para ajustar los niveles de consistencia según sea necesario. Por ejemplo, Cassandra permite escoger entre distintos niveles de consistencia, desde escritura/lectura consistentes hasta eventual consistency. Del mismo modo, MongoDB ofrece transacciones ACID multi-documento para satisfacer necesidades específicas de consistencia.

30 30 NoSQL (12/21) • Ejemplo: En Cassandra, los desarrolladores
pueden configurar operaciones de escritura para asegurar que los datos se repliquen en múltiples nodos antes de que se confirme una transacción. En MongoDB, las operaciones de transacción pueden ser configuradas para asegurar la consistencia de los datos a nivel de colección. "NoSQL Reemplaza a SQL" • Mito: Existe la impresión de que NoSQL está destinado a reemplazar completamente a las bases de datos relacionales. • Realidad: NoSQL no está diseñado para reemplazar a SQL, sino para complementar las bases de datos relacionales en escenarios donde estas últimas no son ideales. NoSQL es perfecto para ciertos tipos de datos y patrones de acceso que las bases de datos relacionales no manejan bien, como los datos de alta velocidad de lectura/escritura, y datos semiestructurados o no estructurados. • Ejemplo: Empresas como Netflix y Uber utilizan una combinación de bases de datos relacionales y NoSQL. Netflix usa MySQL para datos transaccionales y Cassandra para almacenar y gestionar grandes cantidades de datos de visualización de usuarios y logs de actividad debido a su necesidad de alta disponibilidad y escalabilidad horizontal.

31 31 NoSQL (13/21) Cuando Usar una Base de Datos
NoSQL Saber cuándo emplear una base de datos NoSQL es crucial para el éxito del proyecto. Ya hemos visto algunos de los mitos sobre NoSQL y ejemplos de su implementación con éxito. A continuación, se detallan más casos de uso y razones de peso para optar por NoSQL en diferentes escenarios: Grandes Volúmenes de Datos • Caso de Uso: Aplicaciones que requieren almacenar y procesar grandes cantidades de datos en tiempo real, como sistemas de análisis de logs y datos de sensores IoT. • Ejemplo: LinkedIn utilizaba en sus inicios la base de datos NoSQL Voldemort, una versión de Apache Cassandra, para almacenar grandes volúmenes de datos de usuario y logs de actividad, permitiendo la rápida recuperación y análisis para personalizar la experiencia del usuario.

32 32 NoSQL (14/21) Alta Disponibilidad y Tolerancia a Fallos
• Caso de Uso: Aplicaciones donde la disponibilidad continua y la tolerancia a fallos son críticas, como servicios financieros y de compras en línea. • Ejemplo: Netflix emplea Cassandra para proporcionar alta disponibilidad y asegurarse de que los datos del usuario estén siempre accesibles, incluso durante interrupciones de servicio o fallos del centro de datos. Datos No Estructurados y Semi-Estructurados • Caso de Uso: Manejo de datos que no siguen un esquema rígido, como documentos JSON, registros de eventos, y contenido multimedia. • Ejemplo: MongoDB es ampliamente utilizado en el manejo de documentos JSON, facilitando el almacenamiento y recuperación de datos de manera flexible. The Weather Channel usa MongoDB para almacenar y gestionar grandes volúmenes de datos meteorológicos no estructurados en tiempo real.

33 33 NoSQL (15/21) Aplicaciones con Requisitos de Rendimiento Variables
• Caso de Uso: Aplicaciones que experimentan variaciones significativas en el tráfico, como sitios de comercio electrónico durante temporadas de ventas o eventos especiales. • Ejemplo: eBay utiliza Redis, una base de datos NoSQL en memoria, para manejar picos de tráfico significativos durante eventos de alto perfil, asegurando un rendimiento rápido y fiable para los usuarios. Prototipos y Desarrollo Ágil • Caso de Uso: Desarrollo de prototipos o trabajo en entornos ágiles donde los requerimientos cambian frecuentemente. • Ejemplo: Startups como Gilt Groupe optaron por MongoDB y Couchbase durante sus fases iniciales de desarrollo para aprovechar la flexibilidad de esquemas y la rápida iteración sin remodelar la base de datos. Personalización y Modelos de Datos Complejos • Caso de Uso: Aplicaciones donde cada usuario final tiene un conjunto único de datos y relaciones, como en redes sociales o plataformas de recomendación. • Ejemplo: Facebook emplea o empleaba Cassandra para manejar los grandes y diversos conjuntos de datos de usuario, permitiendo personalizar el contenido y las relaciones en tiempo real de manera eficiente.

34 34 NoSQL (16/21) Enriquecimiento de la Experiencia del Usuario
con Bases de Datos Mixtas Al final, el tipo de datos y los requisitos específicos de la aplicación dictan la elección de la base de datos. En muchas ocasiones, se utilizan tanto bases de datos NoSQL como relacionales en conjunto para enriquecer la experiencia del usuario. A continuación, se presenta un ejemplo detallado de cómo diferentes tipos de bases de datos se pueden utilizar cooperativamente en una aplicación de redes sociales. Ejemplo Aplicación de Redes Sociales 1. Base de Datos de Grafos para Relaciones: a. Uso: Las bases de datos de grafos como Neo4j son ideales para gestionar y analizar las relaciones entre usuarios. Esta tecnología es excelente para caracterizaciones como "Amigos de Amigos", recomendaciones de nuevas conexiones y análisis de redes complejas. b. Ventaja: Permite consultas rápidas y eficientes sobre las relaciones y las conexiones entre los usuarios, mejorando las recomendaciones y las interacciones. 2. Base de Datos NoSQL para Datos No Estructurados: a. Uso: MongoDB se puede usar para almacenar perfiles de usuario, publicaciones, comentarios, y contenido multimedia como fotos y vídeos, que no requieren una estructura rígida. b. Ventaja: La flexibilidad en el esquema permite manejar diversas formas de datos sin necesidad de remodelar la base de manera constante, facilitando la rápida implementación de nuevas funcionalidades. 3. Base de Datos Relacional para Transacciones Financieras: a. Uso: Una base de datos relacional como MySQL o PostgreSQL se puede utilizar para manejar transacciones financieras, tales como compras en la aplicación o pagos de publicidad. b. Ventaja: Los sistemas relacionales son ideales para transacciones que requieren consistencia y confiabilidad ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad).

35 35 NoSQL (17/21) Integración en la Aplicación • Procesamiento
de Datos: En el backend, se pueden usar servicios de procesamiento de datos en tiempo real, como Apache Kafka, para integrar flujos de datos de diferentes bases de datos, asegurando que cada componente de la aplicación tenga acceso a los datos más recientes y relevantes. • Enriquecimiento de la Experiencia: Esto permite, por ejemplo, que cuando un usuario haga una compra (manejado por la base de datos relacional), esta información pueda ser rápidamente utilizada para actualizar su perfil e influir en las recomendaciones de amigos (basada en la base de datos de grafos) y en su feed de noticias (basado en la base de datos NoSQL). El uso combinado de diferentes tipos de bases de datos permite a las aplicaciones mejorar significativamente la experiencia del usuario al aprovechar las fortalezas únicas de cada tipo de base de datos. Desde la gestión eficiente de relaciones complejas y grandes volúmenes de datos no estructurados hasta el manejo fiable de transacciones críticas, la elección correcta y combinada de bases de datos es fundamental para el éxito de aplicaciones modernas y escalables. Nota del autor Durante una de mis formaciones sobre bases de datos NoSQL, un asistente me compartió una anécdota curiosa que ilustra los desafíos y malentendidos comunes al adoptar nuevas tecnologías. Esta persona me comentó que su equipo estaba trabajando en un proyecto con una base de datos NoSQL. Lo peculiar del proyecto era que, aunque usaban una base de datos NoSQL, su enfoque seguía siendo la normalización estricta de los datos, tal como se haría en una base de datos relacional. Esta anécdota me recordó la importancia de comprender los principios fundamentales detrás de las tecnologías que utilizamos. Las bases de datos NoSQL y relacionales tienen filosofías y objetivos diferentes, y tratar de implementar las técnicas de una en la otra puede llevar a resultados subóptimos.

36 36 NoSQL (18/21) La Desnormalización Formas Normales de Bases
de Datos Relacionales En el mundo de las bases de datos relacionales, la normalización es un proceso utilizado para organizar los datos en tablas para minimizar la redundancia y evitar problemas de integridad. Las formas normales más comunes incluyen: • Primera Forma Normal (1NF) • Asegura que cada columna en una tabla contenga valores atómicos y que cada valor de columna sea único. • Ejemplo: Una tabla de direcciones donde cada registro contiene una sola dirección por fila. • Segunda Forma Normal (2NF) • Cumple con todos los requisitos de 1NF. • Asegura que todos los atributos no clave están completamente dependientes de la clave primaria, eliminando dependencias parciales. • Ejemplo: Separar la relación de productos y categorías en dos tablas: una tabla de productos y otra tabla de categorías, vinculadas por una clave externa.

37 37 NoSQL (19/21) • Tercera Forma Normal (3NF) o
Forma Normal de Boyce-Codd (BCNF) • Tercera Forma Normal (3NF): • Cumple con todos los requisitos de 2NF. • Asegura que no existen dependencias transitivas entre los atributos no clave. • Ejemplo: En una tabla de empleados, se movería la información del departamento a una tabla separada para que cada departamento esté listada una vez, evitando la redundancia. • Forma Normal de Boyce-Codd (BCNF): • Es una forma más estricta de la 3NF. • Una tabla está en BCNF si cumple con las condiciones de 3NF y, además, para cada dependencia funcional de la forma A → B, el atributo A debe ser una superclave de la tabla. • Ejemplo: Imagina que en un hospital los médicos (medicoID) están asignados a una especialidad (especialidadID), y cada especialidad tiene un jefe de especialidad (jefeID). Aquí, tanto los médicos como el jefe dependen de la especialidad. Para eliminar dependencias redundantes y cumplir con la BCNF, podríamos descomponer la tabla original en dos: • Una tabla que relacione las especialidades con sus jefes:Especialidad (especialidadID, jefeID) • Otra tabla que asigne médicos a sus respectivas especialidades:MedicoEspecialidad (medicoID, especialidadID)

38 38 NoSQL (20/21) La Desnormalización Desnormalización en Bases de
Datos NoSQL En una base de datos NoSQL, la idea de normalización adopta una forma diferente. En lugar de centrarse en la eliminación de redundancias y en la conformidad con las formas normales, las bases de datos NoSQL optimizan el rendimiento, la escalabilidad y la flexibilidad del esquema. Algunos principios para NoSQL: • Desnormalización Controlada • Uso: Se acepta la duplicación de datos para mejorar la velocidad de lectura y escritura, lo cual es crucial para aplicaciones de alta disponibilidad y rendimiento. • Ejemplo en NoSQL: En una base de datos de documentos como MongoDB, almacenar datos del usuario junto con las publicaciones del blog en el mismo documento para acceso rápido en lugar de normalizar estos datos en diferentes colecciones.

39 39 NoSQL (21/21) • Modelado Basado en Consultas •
Uso: El diseño del esquema está basado en cómo se consulta y utiliza comúnmente la información, lo que puede implicar combinar diferentes entidades en una sola estructura. • Ejemplo en NoSQL: En una base de datos de grafos como Neo4j, modelar directamente las relaciones y acciones de usuario (amigos, likes, etc.) para consultas rápidas, en vez de separar cada interacción en tablas relacionadas como se haría en un modelo relacional. • Flexibilidad del Esquema • Uso: Permitir cambios en las estructuras de datos sin la necesidad de remodelar toda la base de datos. • Ejemplo en NoSQL: En una base de datos clave-valor como Redis, donde cada clave puede tener un valor que puede variar en estructura, desde un simple string a un set o un hash, permitiendo agregar nuevas características sin afectar las operaciones existentes. Nota del autor Este punto en concreto es uno de los mayores desafíos que enfrentan los profesionales al pasar de un modelo de base de datos relacional (SQL) a un modelo no relacional (NoSQL), como el de MongoDB, es el cambio en el enfoque en las consultas en base al modelado de datos tan distinto. Y aquí es donde las RU/s de Azure Cosmos DB se ven afectadas por la falta de agilidad al pensar en el modelo NoSQL. Nota del autor Lo sé, lo he repetido muchas veces. Pero es algo en lo que debo hacer hincapié, porque a menudo este es el problema fundamental cuando extraemos datos flexibles de NoSQL y los procesamos en memoria dentro de objetos estrictamente tipados en lenguajes como C#.

40 40 Azure Cosmos DB (1/53) Aspectos básicos Azure Cosmos
DB proporciona varias características fundamentales que permiten a las empresas obtener el máximo rendimiento y flexibilidad en la gestión de sus datos. A continuación, se describen algunos de los aspectos básicos que hacen de Azure Cosmos DB una opción robusta y eficiente para diversas cargas de trabajo y aplicaciones. Alta Disponibilidad y Baja Latencia Global Azure Cosmos DB asegura una disponibilidad del 99.999% mediante la replicación global de los datos. Esto significa que los datos se replican automáticamente en múltiples regiones geográficas, proporcionando baja latencia y alta disponibilidad a nivel mundial. Las principales características incluyen: • Replicación Multi-Master: Permite la escritura y lectura en cualquier región, eliminando cuellos de botella y mejorando significativamente la latencia. • Failover Automático: En caso de fallos en una región, Azure Cosmos DB redirige automáticamente las solicitudes a otra región sin interrumpir el servicio. • Reducción de Latencia: Gracias a la replicación global, las aplicaciones pueden acceder y escribir datos en la región más cercana al usuario final, garantizando tiempos de respuesta rápidos.

41 41 Azure Cosmos DB (2/53) Escalabilidad Automática Azure Cosmos
DB permite el escalado tanto automático como manual, ofreciendo flexibilidad y eficiencia para manejar incrementos en la carga de trabajo. Algunas de sus características clave son: • Escalabilidad Horizontal: Distribuye datos y solicitudes a través de múltiples nodos, permitiendo el reparto de la carga de trabajo sin interrupciones. • Ajuste de Capacidad: Los desarrolladores pueden configurar la capacidad de la base de datos en términos de Unidades de Solicitud (RU), ajustando automáticamente los recursos según el tráfico. • Crecimiento en Tiempo Real: Permite añadir o reducir capacidad sin tiempo de inactividad, adaptándose a las necesidades cambiantes de la aplicación y del negocio. Modelos de Consistencia Ajustables Azure Cosmos DB ofrece cinco niveles de consistencia ajustables, permitiendo a los desarrolladores elegir el balance adecuado entre consistencia y rendimiento según los requisitos de la aplicación: Nota del autor He incluido enlaces directos a los puntos específicos de la documentación de Microsoft Learn. Considero innecesario repetir lo que ya está claramente explicado en una fuente oficial. Prefiero ser breve y resumir en unos pocos párrafos lo esencial que debéis revisar, facilitándoos el acceso directo a la información clave y ahorrándoos tiempo en búsquedas.

42 42 Azure Cosmos DB (3/53) • Consistencia Fuerte: •
Descripción: Garantiza que las lecturas devuelvan siempre la versión más reciente de los datos mediante la confirmación de una mayoría de réplicas. • Uso Ideal: Aplicaciones que requieren total precisión y consistencia, como sistemas financieros. • Bounded Staleness (Desfase Acotado): • Descripción: Permite configuraciones de tiempo o cantidad de versiones específicas para determinar cuánto pueden diferir las lecturas de las escrituras más recientes. • Uso Ideal: Aplicaciones que necesitan un balance controlado entre consistencia y latencia, como sistemas de seguimiento de inventarios. • Consistencia de Sesión: • Descripción: Garantiza que todas las lecturas de una sesión de cliente vean las escrituras anteriores en la misma sesión, manteniendo un orden adecuado dentro de la sesión. • Uso Ideal: Aplicaciones centradas en usuarios individuales, donde un usuario espera ver sus propias actualizaciones de forma inmediata.

43 43 Azure Cosmos DB (4/53) • Prefijo Consistente: •
Descripción: Asegura que las lecturas nunca verán actualizaciones en un orden diferente del que fueron escritas, aunque pueden no ser las más recientes. • Uso Ideal: Aplicaciones que requieren el mantenimiento del orden de escrituras, como el procesamiento de eventos de IoT. • Consistencia Eventual: • Descripción: Proporciona alta disponibilidad y mayor rendimiento, permitiendo que diferentes réplicas converjan eventualmente al mismo valor. • Uso Ideal: Aplicaciones donde la rapidez y la disponibilidad son más importantes que la precisión inmediata, como redes sociales y sistemas de chat. Nota del autor Al acceder a los enlaces sobre los tipos de consistencias, encontraréis un ejemplo con notas musicales que ilustra de forma muy visual el efecto de cada una. Aunque Microsoft utiliza el término "coherencia", he optado por emplear el concepto más generalizado en el mundo de las bases de datos NoSQL, para que podáis familiarizaros con una nomenclatura más común. Mayor disponibilidad, menor latencia, mayor rendimiento Mayor Consistencia Menor Consistencia Fuerte Desfase Acotado Sesión Prefijo Consistente Eventual

44 44 Azure Cosmos DB (5/53) Multi-Modelo Azure Cosmos DB
es una base de datos multimodal que permite almacenar datos de diversas maneras, una de las más comunes es a través de documentos. Para entender por qué este modelo es robusto y flexible, es importante contrastarlo con las bases de datos relacionales tradicionales y entender cómo se manejan las unidades de datos en cada enfoque. Concepto de Documento en Azure Cosmos DB En el contexto de Azure Cosmos DB, un documento es la unidad más pequeña de almacenamiento en una base de datos de documentos. Los documentos están típicamente representados en formato JSON, lo que los hace altamente flexibles y humanamente legibles. Pueden contener una mezcla de datos estructurados y no estructurados, incluyendo: • Campos clave-valor: Similar a las columnas en una fila de una base de datos relacional, pero sin un esquema fijo. • Objetos anidados: Permite estructuras complejas dentro de un solo documento. • Matrices (Arrays): Permite almacenar listas de valores o objetos dentro del documento. Nota del autor Me centro ahora en los documentos ya que son el modelo de almacenamiento de la información más característico de una base de datos NoSQL, aunque ya hemos visto que tenemos las opciones de Key-Value, Grafos, etc.

45 45 Azure Cosmos DB (6/53) Azure Cosmos DB Account
Database - 1 Database - N Collection - 1 Collection - N Document - 1 Document - N Field - 1 Field - N … … … … Nota del autor Base de Datos (Database - 1): En Azure Cosmos DB, puedes tener múltiples bases de datos. En este caso, estamos viendo una sola base de datos. Colección (Collection - 1): Dentro de cada base de datos, puedes tener múltiples colecciones. Las colecciones son equivalentes a las tablas en bases de datos relacionales y almacenan documentos. Documento (Document - 1): Dentro de cada colección, puedes tener múltiples documentos. Cada documento es una instancia de datos, representado en formato JSON. En la imagen, el documento contiene información sobre un usuario y sus pedidos. Campos (Field - 1, Field - N): Dentro de cada documento, puedes tener múltiples campos. Los campos son las unidades básicas de información en un documento. En el JSON de la izquierda, los campos incluyen "id", "name", "email", "address", y "orders".

46 46 Comparación con Bases de Datos Relacionales En una
base de datos relacional, la unidad más pequeña de almacenamiento es la fila de una tabla. Cada fila contiene múltiples columnas, y las tablas están definidas por un esquema rígido que dicta los tipos de datos y las relaciones entre tablas. Este enfoque garantiza la integridad de los datos y minimiza la redundancia mediante la normalización. En una base de datos de documentos como Cosmos DB, toda esta información se puede almacenar en un solo documento JSON. Esto elimina la necesidad de uniones entre tablas y puede mejorar significativamente el rendimiento de las consultas, particularmente en aplicaciones que requieren acceso rápido a datos relacionados. Azure Cosmos DB (7/53)

47 47 Azure Cosmos DB (8/53) Ventajas del Enfoque de
Documento en Cosmos DB • Flexibilidad del Esquema: • Sin Esquema Fijo: Permite cambiar y expandir los datos sin necesidad de alterar un esquema rígido. • Agilidad en el Desarrollo: Los desarrolladores pueden agregar nuevos campos y estructuras anidadas sin interrumpir la base de datos existente. • Operaciones Atomicas en Niveles Más Altos: • Documentos Autónomos: Todas las relaciones y datos necesarios para un objeto o entidad se encuentran dentro de un solo documento. • Eficiencia de Consulta: Minimiza la necesidad de uniones y permite acceder a datos relacionados directamente. • Adaptabilidad a Diversos Casos de Uso: • Datos Semi-Estructurados y No Estructurados: Puede manejar JSON complejo, lo que permite un almacenamiento más natural de varios tipos de datos. • Escenarios de Alta Disponibilidad y Respuesta Rápida: Ideal para aplicaciones con requerimientos de baja latencia y alta disponibilidad.

48 48 Azure Cosmos DB (9/53) Un vistazo rápido a
Azure CosmosDB Ahora toca darse un paseo por las opciones disponibles que debemos conocer, las he agrupado en áreas. Solo aquellas opciones que he marcado son las que vamos a ver; son particularmente importantes para el desarrollo de aplicaciones con Azure Cosmos DB. Las opciones comunes de muchos recursos de Azure • Overview: Proporciona un resumen general del estado y las configuraciones de tu cuenta de Cosmos DB. • Activity log: Muestra un registro de las actividades y acciones realizadas en el recurso. • Access control (IAM): Administra quién tiene acceso a tu cuenta de Cosmos DB y qué permisos tienen. • Tags: Facilita la organización y categorización de recursos mediante etiquetas. • Diagnose and solve problems: Herramientas para identificar y resolver problemas comunes en Cosmos DB. • Cost Management: Supervisa y gestiona los costos asociados al uso de Cosmos DB. • Quick start: Proporciona guías rápidas para comenzar a usar Cosmos DB. • Backup & Restore: Administra las copias de seguridad y la restauración de datos. • Networking: Configura las opciones de red para acceder a tu base de datos de manera segura. • CORS: Configura la seguridad de las solicitudes HTTP entre diferentes orígenes. • Advisor Recommendations: Proporciona recomendaciones para optimizar el uso y rendimiento de Cosmos DB.

49 49 Azure Cosmos DB (10/53) • Microsoft Defender for
Cloud: Herramientas para mejorar la seguridad de tu cuenta de Cosmos DB. • Identity: Configura las opciones de identidad para el acceso a recursos. • Locks: Protege los recursos contra eliminaciones accidentales. • Monitoring: Herramientas para supervisar el rendimiento y la actividad de Cosmos DB. • Insights: Proporciona información detallada sobre el rendimiento. • Alerts: Configura alertas para eventos y métricas específicos. • Metrics: Muestra métricas clave de rendimiento. • Logs: Proporciona acceso a los registros de actividad y eventos de Cosmos DB. • Diagnostic settings: Configura la recopilación y exportación de datos de diagnóstico. • Workbooks: Crea y comparte informes visuales personalizados para el monitoreo. • Automation: Herramientas para automatizar tareas y procesos relacionados con Cosmos DB. • CLI / PS: Accede a la interfaz de línea de comandos y a PowerShell para gestionar Cosmos DB mediante scripts. • Tasks: Administra tareas automatizadas y programadas. • Export template: Exporta la configuración de tu recurso Cosmos DB como una plantilla ARM para su reutilización o despliegue automatizado. • Help: Recursos y soporte para ayudar con el uso de Cosmos DB. • Resource health: Verifica el estado de salud del recurso y recibe alertas sobre problemas. • Support: Accede a opciones de soporte técnico y documentación adicional.

50 50 Azure Cosmos DB (11/53) Esencial para principiantes •
Data Explorer: Interfaz para explorar y gestionar datos dentro de tu base de datos Cosmos DB. Esencial para el desarrollo • Mirroring in Fabric (Preview): Funcionalidad en vista previa para replicar datos. • Features: Lista de características adicionales que puedes habilitar para tu cuenta. • Replicate data globally: Configura la replicación de datos en diferentes regiones geográficas para mejorar la disponibilidad. • Default consistency: Establece el nivel de consistencia predeterminado para las operaciones de lectura en tu base de datos. • Keys: Muestra las claves de acceso necesarias para conectar aplicaciones a tu base de datos Cosmos DB. Esencial para entender cómo se gestionan las lecturas • Dedicated Gateway: Gestiona las configuraciones del gateway dedicado para un mejor rendimiento.

51 51 Azure Cosmos DB (12/53) Esencial para la conexión
de aplicaciones • Integrations: Herramientas y servicios que se pueden integrar con Cosmos DB. • Power BI: Integra con Power BI para análisis de datos. • Azure Synapse Link: Conecta con Azure Synapse para análisis en tiempo real. • Add Azure AI Search: Añade capacidades de búsqueda con Azure AI. • Add Azure Function: Integra funciones de Azure para automatización y procesamiento. • Containers: Gestiona los contenedores dentro de tu cuenta de Cosmos DB. • Browse: Navega a través de los contenedores y sus datos. • Scale: Ajusta la capacidad de los contenedores según las necesidades de la aplicación.

52 52 Azure Cosmos DB (13/53) Creación de un recurso
He presentado una visión general de las diversas opciones disponibles en Azure Cosmos DB antes de proceder con la creación del recurso. Es esencial que todos, especialmente aquellas personas que no tienen la opción de trabajar en la nube comprendan estas opciones antes de pasar a la creación de recursos, ya sea en la nube o en un entorno local. Crear una Instancia en la Nube

53 53 Azure Cosmos DB (14/53) Como puedes observar, podemos
crear hasta 6 tipos distintos de bases de datos NoSQL, cada una de ellas con sus propias características. ¿Cuál debo escoger? Ya hemos hablando con anterioridad de los tipos de NoSQL, aquí os agrupo cada uno de ellos: Por ejemplo, una característica importante de Azure Cosmos DB para NoSQL es que es un formato propietario de Microsoft mientras que MongoDB no lo es, pero Azure Cosmos DB te proporciona la opción incluso de desplegar un Clúster 100% de MongoDB. Documentos • Azure Cosmos DB para NoSQL • Azure Cosmos DB para MongoDB Key-Value • Azure Cosmos DB para Table Columnares • Azure Cosmos DB para Apache Cassandra Grafos • Azure Cosmos DB para Apache Gremlin Relacionales • Azure Cosmos DB para PostgreSQL

54 54 Azure Cosmos DB (15/53) Nosotros vamos a trabajar
con la opción que no he marcado de amarillo ya que es más sencilla de administrar y poner en funcionamiento, pero te invito a investigar por tu cuenta como funciona Azure Cosmos DB para MongoDB. Puede que os haya sorprendido encontrar un tipo de base de datos relacional como PostgreSQL en esta lista. Cuando mencioné que Azure Cosmos DB es multimodelo, quizás no os imaginabais hasta qué punto se extiende esta capacidad. Aunque no voy a hablar de la opción PostgreSQL, es importante destacar que se trata de una base de datos altamente escalable. Os invito a explorar más sobre esta fascinante tecnología. Por tanto, nos vamos a quedar con las opciones: 1, 2, 3, 4 y 5, para este documento. Vamos a empezar con la más sencilla de todas la API de NoSQL que nos ayudará a ver el recurso y las opciones más destacadas.

55 55 Azure Cosmos DB (16/53) API de NoSQL He
presentado una visión general de las diversas opciones disponibles en Azure Cosmos DB antes de proceder con la creación del recurso. Es esencial que todos, especialmente aquellas personas que no tienen la opción de trabajar en la nube comprendan estas opciones antes de pasar a la creación de recursos, ya sea en la nube o en un entorno local. Crear una Instancia en la Nube del tipo API NoSQL

56 56 Azure Cosmos DB (17/53) Crear una Instancia Local
Es sencillo configurar un emulador de CosmosDB siguiendo los pasos del enlace anterior. Sin embargo, en mi caso, siempre utilizaré Azure. Nota del autor El emulador no permite usar Apache Cassandra, o Apache Gremlin o Tabla, pero aquí os dejo las alternativas: • https://hub.docker.com/_/cassandra • https://hub.docker.com/r/tinkerpop/gremlin-server/tags Y la que más nos importará en este documento será la de MongoDB: docker pull mcr.microsoft.com/cosmosdb/linux/azure-cosmos- emulator:mongodb No es la mejor opción usar el emulador para este documento ya que alguna cosa no podrás ponerla en práctica.

57 57 Azure Cosmos DB (18/53) Quick start Ya hemos
pasado mucho tiempo leyendo, ahora nos toca algo más práctico:

58 58 Azure Cosmos DB (19/53) Data Explorer Cuando crees
tu primer contenedor, paso 1, y antes de abrir el código en tu editor, vamos a ver los datos que se han generado en Azure Cosmos DB al mismo tiempo que aprendemos a usar el Data Explorer.

59 59 Azure Cosmos DB (20/53) Al seleccionar Data Explorer
en la barra lateral, se despliega el Panel de Exploración de Datos. Este panel es el corazón de tus interacciones con los datos. Aquí podrás: • Crear Nuevos Contenedores: Utiliza el botón "New Container" para añadir contenedores, que son estructuras que organizan tus datos y definen la escala y el rendimiento. • Navegar por Colecciones y Elementos: En nuestro ejemplo, vemos una colección llamada "ToDoList" con un subcontenedor "Items". Esto nos permite ver y gestionar los documentos que residen allí. En la parte superior del área de trabajo, se presentan las Pestañas de Navegación. Estas pestañas facilitan el cambio rápido entre las vistas abiertas, como "Home" y "Items.Items". Son útiles para mantener múltiples consultas o vistas en paralelo mientras trabajas con tus datos. Dentro de cada contenedor, encontrarás opciones como: • Stored Procedures (Procedimientos Almacenados): Código que se ejecuta en el lado del servidor para operaciones complejas. • User Defined Functions (UDF, Funciones Definidas por el Usuario): Funciones personalizadas que puedes usar en tus consultas. • Triggers: Código que se ejecuta automáticamente en respuesta a ciertas operaciones de datos.

60 60 Azure Cosmos DB (21/53) Como aun no tenemos
datos, es el momento de abrir el código para empezar a trabajar y veréis que ya disponemos de la conexión (Keys) incluida: Explora la aplicación y comenta la línea 72 y 73 del Program.cs, vuelve a ejecutarla.

61 61 Azure Cosmos DB (22/53) Ya tendrás tiempo de
borrar el contenedor, ahora quiero mostraros las posibilidades de este lenguaje de consultas SQL: Si entramos de nuevo, podremos ver los datos como se almacenan además de lanzar consultas como podréis observar:

62 62 Azure Cosmos DB (23/53) Un paréntesis por si
os interesa como generar un Store Procedure y os dejo la documentación por si queréis ir por esta vía, aunque yo prefiero siempre optar por la opción de Azure Functions para los trigger y par UDF o Stores Procedures tenerlo todo en código que pueda añadir a mi flujo de DevOps. Procedimientos almacenados, desencadenadores y funciones definidas por el usuario (UDF) en Azure Cosmos DB

63 63 Azure Cosmos DB (24/53) Las opciones que podéis
aplicar de este lenguaje de SQL se encuentran en el siguiente documento: Consultas en Azure Cosmos DB for NoSQL, como podréis observar no existe la posibilidad de un inner, left, outer, etc. join en este lenguaje. Para realizar ese tipo de acciones nos os quedará más remedio que traeros la colección a memoria de vuestro programa o bien crear tablas intermedias para poder llegar a realizar esto; pero si la realidad de tu proyecto dicta que debes usarlo, quizá es el momento de plantearte si tus datos en realidad son relacionales.

64 64 Azure Cosmos DB (25/53) Y para dar por
concluido el API de NoSQL, solo nos queda saber que librería estamos usando en el ejemplo Quick Start, ya que será la librería que vamos a tener que usar para este tipo de API: https://github.com/Azure/azure-cosmos-dotnet-v3 dotnet add package Microsoft.Azure.Cosmos

65 65 Azure Cosmos DB (26/53) Insights Este es uno
de esos recursos de Azure que necesitan un seguimiento exhaustivo para que la infraestructura no se dispare de costes (en resumen, aplicar FinOps y GeenOps). Veamos primero que son las RU y luego vamos a relacionarlo con los Insights.

66 66 Azure Cosmos DB (27/53) Unidades de Solicitud (RU,
Request Units) Las RU son una medida de los recursos que consume cada operación en Cosmos DB. Cada operación que realizas, ya sea una lectura, escritura, consulta, actualización o eliminación de datos, consume una cierta cantidad de RUs. Lo que hace que el concepto de RU sea crucial se puede resumir en los siguientes puntos: • Costos: En Azure Cosmos DB, pagas por las RUs aprovisionadas. Monitorizar y entender el consumo de RUs te permitirá optimizar tu diseño de base de datos para minimizar costos. Si no monitorizas, podrías estar gastando más de lo necesario. • Performance (Rendimiento): Monitorizar las RUs te ayuda a identificar operaciones costosas que podrían estar afectando el rendimiento de tu base de datos. Al optimizar estas operaciones, puedes mejorar significativamente la rapidez y eficiencia de tu aplicación. • Dimensionamiento: Con un buen monitorizado de RUs, puedes anticipar cuándo necesitarás escalar hacia arriba o hacia abajo tus RUs aprovisionadas, ajustando así el throughput según la demanda y ahorrando costos. • Garantía de SLAs: Azure Cosmos DB ofrece SLAs (Acuerdos de Nivel de Servicio) para rendimiento y disponibilidad. Para garantizar que tu aplicación cumpla con estos SLAs, es esencial monitorizar el consumo de RUs y asegurarse de que la base de datos esté respondiendo en el tiempo y forma esperados. Aunque ya os he comentado que estimar en Cosmos DB suele ser un fallo seguro, al menos, podemos usar la herramienta de calculadora que nos proporcionar Microsoft para establecer un Base Line y luego ir ajustado según vemos el consumo.

67 67 Azure Cosmos DB (28/53) Monitorización de RUs con
Cosmos DB Insights Azure Cosmos DB Insights proporciona herramientas y métricas que te permiten monitorizar en detalle el consumo de Unidades de Solicitud (RUs) en tu base de datos. Estas son algunas maneras en que Insights ayuda a gestionar y entender el uso de RUs: • Métricas de Consumo de RUs: • Paneles de Métricas en Tiempo Real: Insights ofrece dashboards en tiempo real que muestran el consumo de RUs por cada operación (lecturas, escrituras, consultas, etc.). Esto te permite visualizar cómo se están utilizando las RUs en cualquier momento. • Vista Global del Consumo: Puedes ver el consumo agregado de RUs para todas tus colecciones, ayudándote a identificar colecciones que están sobrecargadas o subutilizadas. Nota del autor Cuidado que existen diversos documentos despendiendo del API que uses, la anterior que os he puesto es la de NoSQL, para MongoDB es este otro o Cassandra. Y la calculadora como tal: https://cosmos.azure.com/capacitycalculator/;mMucho cuidado, no será la primera vez que veo una estimación con la API que no corresponde.

68 68 Azure Cosmos DB (29/53) • Análisis de Tendencias:
• Tendencias de Largo Plazo: Insights te proporciona gráficos históricos que muestran cómo ha variado el consumo de RUs en el tiempo. Esto te ayuda a entender patrones y determinar en qué momentos del día, semana o mes se produce el mayor consumo, permitiéndote planificar el aprovisionamiento de RUs de manera eficiente. • Prevención de Picos y Problemas: Al observar las tendencias, puedes anticipar picos de consumo y prepararte para ellos, evitando problemas de rendimiento y costos inesperados. • Optimización de Consultas y Operaciones: • Identificación de Operaciones Costosas: Insights te permite identificar consultas y operaciones individuales que están consumiendo altas cantidades de RUs. Una vez identificadas, puedes trabajar en optimizarlas para reducir ese consumo. • Ajustes Precisos: Con métricas detalladas, puedes ajustar de manera precisa el diseño de tus consultas o la estructura de tu base de datos (por ejemplo, índices o particionamiento) para hacerlas más eficientes. • Alertas y Notificaciones (aunque ya no es propiamente Insight, esta relacionado con la monitorización): • Alertas Basadas en Consumo de RUs: Puedes configurar alertas personalizadas que te notifiquen cuando el consumo de RUs supera ciertos umbrales. Esto te permite reaccionar rápidamente para mitigar problemas antes de que afecten a tus usuarios o a tu presupuesto. • Notificaciones de Anomalías: Insights puede identificar patrones anormales en el uso de RUs y notificarte al respecto, permitiéndote investigar y solucionar posibles problemas antes de que escalen.

69 69 Azure Cosmos DB (30/53) Utilizando los datos proporcionados
por Insights, puedes tomar decisiones más informadas sobre cuándo aumentar o reducir las RUs aprovisionadas manualmente. Esto nos permitirá que basándome en las métricas de uso de RUs que Insights proporciona, podamos configurar políticas de escalado automático en Azure Cosmos DB para ajustarse dinámicamente a la carga de trabajo, optimizando costos mientras se asegura un rendimiento adecuado. ¿Cómo se Beneficia Operaciones con Insights y RUs? El monitoreo detallado y el análisis que te proporciona Cosmos DB Insights con respecto a las RUs impacta de manera directa en varios aspectos fundamentales de tu base de datos y aplicación: • Costos Más Bajos: Al optimizar el consumo de RUs y ajustar las necesidades de throughput de manera precisa, puedes lograr un uso más eficiente de los recursos, manteniendo los costos bajo control. • Rendimiento Mejorado: Al identificar y solucionar operaciones costosas, tu base de datos funcionará de manera más eficiente, proporcionando mejores tiempos de respuesta y una experiencia de usuario más fluida. • Robustez y Fiabilidad Aumentadas: Con sistemas de alerta y notificación actúa proactivamente en lugar de reactivamente ante problemas, incrementando la fiabilidad de tu aplicación. • Planificación Efectiva: Con datos históricos y tendencias, puedes planificar de manera más efectiva tanto el presupuesto como el escalado de recursos para futuras necesidades.

70 70 Azure Cosmos DB (31/53) Indexado El indexado juega
un papel significativo en el consumo de RUs y, por tanto, en los costos generales. ¿Por qué es importante conocer y aplicar bien el indexado? • Impacto del Índice en Lecturas • Lecturas Eficientes: Indices bien diseñados pueden reducir drásticamente la cantidad de RUs consumidas por las operaciones de lectura. Esto se debe a que un buen índice permite al motor de base de datos acceder a los datos necesarios de manera más rápida y eficiente, sin necesidad de escanear más registros de los necesarios. • Reducción de RUs: Operaciones de lectura optimizadas gracias al indexado adecuado consumirán menos RUs, lo que puede traducirse en ahorros sustanciales en costos, ya que puedes aprovisionar menos throughput para el mismo rendimiento. • Impacto del Índice en Escrituras • Sobrecarga de Escrituras: Cada vez que insertas o actualizas un documento, los índices asociados deben actualizarse. Si tienes muchos índices innecesarios, cada operación de escritura consumirá más RUs debido a esta sobrecarga adicional. • Optimización de Índices: Mantener solo los índices necesarios minimiza la sobrecarga en las escrituras, reduciendo así el consumo de RUs y por lo tanto los costos asociados.

71 71 Azure Cosmos DB (32/53) • Personalización del Índice
• Índices Personalizados: La capacidad de definir qué campos se indexan y cuáles no permite ajustar específicamente el uso de RUs y optimizar el rendimiento de la base de datos para tus necesidades particulares. • Caminos Excluidos/Includos: En la API SQL (Core), puedes usar políticas de indexación para incluir o excluir ciertos caminos (paths), optimizando qué se indexa y, en consecuencia, ajustando el consumo de RUs según los accesos más frecuentes de tu aplicación. • Índices Geoespaciales y de Texto • Consultas Específicas: Índices geoespaciales y de texto son costos en términos de RUs porque requieren cálculos adicionales y almacenamiento. Asegúrate de necesitar esos índices para consultas específicas y de usarlos de manera óptima para justificar su costo añadido. Por ejemplo, puedes poner índices solo en ciertos path para un API SQL:

72 72 Azure Cosmos DB (33/53) Importancia del Indexado adecuado
• Optimización de Consultas: Consultas optimizadas consumirán menos RUs, llevándote a costos más bajos. Esto es especialmente relevante en cargas de trabajo con muchas lecturas y consultas complejas. • Rendimiento: Una base de datos bien indexada responde más rápido a las consultas, mejorando la experiencia del usuario y permitiendo a la aplicación manejar más carga con el mismo aprovisionamiento de UTRs. • Costos a Largo Plazo: Al reducir el consumo innecesario de RUs mediante una indexación eficiente, puedes mantener bajo control tu presupuesto, evitando gastar en exceso por operaciones ineficientes. • Escalabilidad: Un buen diseño de índice habilita una escalabilidad más efectiva. Podrás manejar un crecimiento en los datos y consultas con menos necesidad de escalar indiscriminadamente el throughput (y por tanto los costos). API SQL (Core) • Indexación Automática: Por defecto, Cosmos DB automáticamente indexa todos los atributos de los documentos en una colección, lo cual elimina la necesidad de gestionar manualmente la indexación en la mayoría de los casos. • Índices Personalizados: Puedes personalizar la indexación mediante políticas de indexación que te permitan incluir o excluir ciertos caminos (paths) de los documentos. Esto es particularmente útil para optimizar el rendimiento y reducir costos. • Índices Compuestos: Cosmos DB soporta índices compuestos, lo cual permite mejorar el rendimiento de consultas que implican múltiples propiedades.

73 73 Azure Cosmos DB (34/53) API de Cassandra •
Basado en CQL: Usa el mismo esquema de indexado que Apache Cassandra. Se soportan índices secundarios (secondary indexes) basados en las columnas del modelo de datos. • Declaración de Índices: Los índices secundarios deben ser creados explícitamente usando comandos CQL (Cassandra Query Language). • Por ejemplo y aunque no hemos visto Cassandra: CREATE INDEX ON users (email); API de Gremlin • Índices de Propiedad: Para el modelo de grafos, puedes crear índices en propiedades de los vértices o aristas para optimizar las consultas de búsqueda. • Compatibilidad con TinkerPop: Gremlin sigue el estándar Apache TinkerPop, y sus índices se crean a través de Gremlin traversal API o consultas específicas. API de MongoDB • Compatible con MongoDB: El indexado sigue las mismas reglas y características que en MongoDB nativo. Puedes crear índices simples y compuestos, así como índices geoespaciales y de texto. • Comandos MongoDB: Utilizas comandos estándar de MongoDB para la creación y gestión de índices.

74 74 Azure Cosmos DB (35/53) Conclusión Entender y aplicar
bien el indexado en Azure Cosmos DB es crítico tanto para el rendimiento como para la optimización de costos. Cada modelo de datos (API SQL, Cassandra, Gremlin, MongoDB) tiene sus propias características y mejores prácticas de indexación. • Costos Bajos: Un indexado eficiente reduce significativamente el consumo de RUs, lo que directamente impacta los costos. • Mejor Rendimiento: Consultas optimizadas gracias a un buen índice resultan en tiempos de respuesta más rápido. • Planificación Efectiva: Un análisis detallado del uso de RUs y políticas de indexación ajustadas ayudan a planificar y presupuestar de manera precisa. La clave es encontrar un equilibrio entre los índices necesarios para un rendimiento óptimo y minimizar la sobrecarga en operaciones de escritura para mantenerse en un rango de costos manejable.

75 75 Azure Cosmos DB (36/53) Particionado El particionado es
un concepto fundamental en Azure Cosmos DB que permite escalar horizontalmente la base de datos para manejar grandes volúmenes de datos y alta concurrencia. En Cosmos DB, el particionado distribuye los datos en múltiples particiones físicas, lo cual ayuda a mejorar el rendimiento y la capacidad de almacenamiento. Fundamentos del Particionado • Particiones Lógicas: Cosmos DB utiliza particiones lógicas para organizar los datos. Todos los documentos dentro de una partición lógica comparten el mismo valor de clave de partición. • Particiones Físicas: Las particiones lógicas se distribuyen en particiones físicas. Una partición física puede contener múltiples particiones lógicas, y cada partición física tiene una capacidad máxima en términos de almacenamiento y rendimiento (aproximadamente 10 GB y 10,000 RU/s). Clave de Partición • La clave de partición es un campo específico en los documentos que Cosmos DB utiliza para distribuir los datos en las particiones lógicas. • Elegir una clave de partición adecuada es crucial ya que impacta directamente en el rendimiento y balance de carga de la base de datos. Idealmente, debería proporcionar buena distribución y minimizar la posibilidad de "particiones calientes" (una partición física con alta carga).

76 76 Azure Cosmos DB (37/53) Ejemplo de elección de
clave de partición en un documento JSON: API SQL (Core) • Claves de Partición Declarativas: En esta API, la clave de partición se especifica al crear una colección. Todas las consultas deben incluir la clave de partición para ser eficientes. • Manejo de Datos No Estructurados: Dado que los datos pueden ser semi-estructurados (JSON), elegir una clave de partición que tenga una alta cardinalidad y buena distribución es importante. await client.database("myDatabase").container("myContainer") .createIfNotExists({ partitionKey: { paths: ["/userId"] } });

77 77 Azure Cosmos DB (38/53) API de Cassandra •
Claves de Partición en Tablas CQL: En el modelo CQL de Cassandra, las claves de partición se especifican como parte del diseño de la tabla. Guarda ciertas similitudes a SQL. • Keyspace: Las tablas y claves de partición se organizan en un keyspace, reflejando el modelo distribuido de Cassandra. CREATE TABLE users ( userId text PRIMARY KEY, name text, age int ); API de Gremlin • Particionamiento de Grafos: En el modelo de grafos, los vértices y aristas se distribuyen en particiones en base a las propiedades del grafo. • Propiedades de Vértices como Claves de Partición: A menudo se usa una propiedad del vértice para determinar la partición. La eficiencia de las consultas de grafos depende mucho de cómo están distribuidos los vértices y las aristas. graph.createIndex('name', Vertex.class)

78 78 Azure Cosmos DB (39/53) API de MondoDB •
Campos de Documento como Claves de Partición: Similar a la API SQL, un campo del documento actúa como clave de partición. • Sharding en MongoDB: La API de MongoDB replica la funcionalidad de particionamiento (sharding) de MongoDB. La clave de partición se define a nivel de colección. sh.enableSharding("myDatabase"); sh.shardCollection("myDatabase.myCollection", { "userId": 1 }); Importancia de un Buen Diseño de Particionado • Rendimiento y Escalabilidad • Distribución Uniforme: Una clave de partición bien elegida asegura que los datos estén uniformemente distribuidos entre las particiones físicas, evitando "hot spots". • Concatenación de Performance: Un particionado efectivo permite escalar horizontalmente, manteniendo el alto rendimiento y la baja latencia.

79 79 Azure Cosmos DB (40/53) • Costos • Uso
de Recursos Optimizado: Con un buen particionado, las RUs se distribuyen eficazmente, evitando sobrecargas en particiones específicas y aprovechando al máximo los recursos aprovisionados, lo cual impacta directamente en los costos. • Evitar de re-aprovisonamiento: Un particionado desbalanceado puede requerir aumento frecuente de throughput solo para manejar pocas particiones, elevando innecesariamente los costos. • Mantenimiento y Operación • Simplicidad en Mantenimiento: Una clave de partición bien pensada facilita las operaciones de mantenimiento y reduce la necesidad de redistribuir datos, lo cual puede ser costoso y disruptivo. • Crecimiento Futuro: Un diseño adecuado anticipa el crecimiento en el volumen de datos y la carga de trabajo, asegurando que la base de datos se pueda escalar sin necesidad de rediseñar desde cero. Conclusión Un buen diseño de particionado asegura uniformidad en la carga, rendimiento óptimo, minimización de costos y facilidad de mantenimiento y escalabilidad futura. Por ello, comprender y aplicar correctas estrategias de particionado es crucial para aprovechar al máximo las capacidades de Azure Cosmos DB.

80 80 Azure Cosmos DB (41/53) Algunas características más Anteriormente
os indiqué que había unos conceptos del rescuros de Azure Cosmos DB que debíamos conocer, ahora es el momento de presentar los que faltaban: Features • Particiones Lógicas: Cosmos DB utiliza particiones lógicas para organizar los datos. Todos los documentos dentro de una partición lógica comparten el mismo valor de clave de partición.

81 81 Azure Cosmos DB (42/53) Replicate data globally •
Full-Text & Hybrid Search for NoSQL API (preview): Esta característica permite realizar búsquedas de texto completo e híbridas en la API NoSQL, integrando capacidades de búsqueda avanzada dentro de sus consultas. Útil para aplicaciones que requieren búsqueda textual avanzada. • Vector Search for NoSQL API: Permite realizar búsquedas utilizando vectores, ideal para casos de uso como recomendaciones y búsquedas aproximadas en datos no estructurados. • Dynamic Scaling (Per Region and Per Partition Autoscale): Facilita el escalado automático tanto por región como por partición en función de la carga. Esto asegura que las particiones individuales y las diferentes regiones puedan ajustarse dinámicamente a la demanda sin intervención manual. • Priority based execution (preview): Proporciona la capacidad de establecer la prioridad de ejecución para ciertas operaciones, permitiendo una gestión avanzada del rendimiento y la priorización del acceso a recursos. • Burst Capacity: Permite manejar picos temporales de carga utilizando una capacidad adicional de RUs. Es útil para aplicaciones con patrones de tráfico impredecibles o intermitentes. • Partition merge (preview): Automatiza la fusión de particiones, mejorando la gestión de datos y la eficiencia operativa al reducir la fragmentación de datos entre particiones. • Materialized Views for NoSQL API (preview): Permite la creación de vistas materializadas para la API NoSQL, simplificando las consultas complejas y permitiendo la generación eficiente de informes y análisis. • Diagnostics full-text query: Proporciona capacidades mejoradas de diagnóstico y depuración para consultas de texto completo, ayudando a identificar y solucionar problemas de rendimiento y precisión en las búsquedas.

82 82 Azure Cosmos DB (43/53) Caso de Uso Dynamic
Scaling (Per Region and Per Partition Autoscale) Supongamos que tienes una aplicación de comercio electrónico desplegada en varias regiones globales y que experimenta picos de tráfico significativos durante eventos de ventas especiales o temporadas festivas. Estos picos pueden variar significativamente entre regiones y momentos específicos. 1. Configuración: • Ya tienes activada la característica de Dynamic Scaling. 2. Beneficio en Acción: • Durante un evento de ventas como el "Black Friday", el tráfico hacia tu aplicación en la región de Norteamérica se incrementa drásticamente. • Gracias a la configuración de Dynamic Scaling, Cosmos DB automáticamente escala las particiones en esa región para manejar la carga adicional, asegurando que todas las solicitudes se manejen dentro de los SLAs establecidos. • Otras regiones, que pueden no estar experimentando el mismo pico de tráfico, no necesiten escalar al mismo nivel, lo que optimiza el uso de RUs y, por ende, los costos en esas regiones. 3. Post Evento: • Una vez finalizado el evento de ventas, el tráfico vuelve a su nivel normal. Cosmos DB reduce automáticamente el throughput en la región afectada, evitando costos innecesarios por sobre-provisionamiento. 4. Reporte y Auditoría: • Puedes utilizar las herramientas de monitoreo y reportes de Cosmos DB para revisar los ajustes automáticos realizados, analizar el impacto en el rendimiento y ajustar políticas si fuera necesario para futuros eventos. Caso de Uso Materialized Views for NoSQL API Supongamos que estás gestionando una plataforma de e-commerce que almacena una gran cantidad de información acerca de productos, pedidos, usuarios y transacciones. Los usuarios y administradores de tu plataforma necesitan acceder a diversos informes y análisis de datos de manera eficiente y en tiempo real. Desafío: Generar informes personalizados basados en datos agregados y derivados de múltiples colecciones puede ser intensivo en recursos si se ejecutan consultas complejas cada vez que se necesita un informe. Esto puede resultar en: Alto consumo de unidades de solicitud (RUs), Alta latencia en las respuestas de las consultas. Impacto negativo en la experiencia del usuario debido a tiempos de espera prolongados. Solución con Materialized Views: Permiten precomputar y almacenar los resultados de consultas complejas, actualizándose automáticamente cuando los datos subyacentes cambian.

83 83 Azure Cosmos DB (42/53) Replicate data globally •
Full-Text & Hybrid Search for NoSQL API (preview): Esta característica permite realizar búsquedas de texto completo e híbridas en la API NoSQL, integrando capacidades de búsqueda avanzada dentro de sus consultas. Útil para aplicaciones que requieren búsqueda textual avanzada. • Vector Search for NoSQL API: Permite realizar búsquedas utilizando vectores, ideal para casos de uso como recomendaciones y búsquedas aproximadas en datos no estructurados. • Dynamic Scaling (Per Region and Per Partition Autoscale): Facilita el escalado automático tanto por región como por partición en función de la carga. Esto asegura que las particiones individuales y las diferentes regiones puedan ajustarse dinámicamente a la demanda sin intervención manual. • Priority based execution (preview): Proporciona la capacidad de establecer la prioridad de ejecución para ciertas operaciones, permitiendo una gestión avanzada del rendimiento y la priorización del acceso a recursos. • Burst Capacity: Permite manejar picos temporales de carga utilizando una capacidad adicional de RUs. Es útil para aplicaciones con patrones de tráfico impredecibles o intermitentes. • Partition merge (preview): Automatiza la fusión de particiones, mejorando la gestión de datos y la eficiencia operativa al reducir la fragmentación de datos entre particiones. • Materialized Views for NoSQL API (preview): Permite la creación de vistas materializadas para la API NoSQL, simplificando las consultas complejas y permitiendo la generación eficiente de informes y análisis. • Diagnostics full-text query: Proporciona capacidades mejoradas de diagnóstico y depuración para consultas de texto completo, ayudando a identificar y solucionar problemas de rendimiento y precisión en las búsquedas.

84 84 Azure Cosmos DB (43/53) Replicate data globally La
capacidad de replicar datos globalmente es una de las características clave de Azure Cosmos DB que permite diseñar aplicaciones distribuidas y de alta disponibilidad. Azure Cosmos DB permite replicar datos en múltiples regiones geográficas, proporcionando ventajas como baja latencia, alta disponibilidad y continuidad del negocio. Beneficios de la Replicación Global • Alta Disponibilidad: Al replicar los datos en múltiples regiones, tu aplicación puede seguir funcionando correctamente incluso si una región experimenta una interrupción. Esto asegura una disponibilidad continua del servicio. • Baja Latencia: Replicar los datos en regiones cercanas a los usuarios finales reduce la latencia de las operaciones de lectura y escritura, mejorando la experiencia del usuario final. • Escalado Global: Facilita la expansión global de aplicaciones, permitiendo que los datos estén disponibles en cualquier parte del mundo sin necesidad de modificaciones significativas en la arquitectura de la aplicación. • Consistencia Configurable: Azure Cosmos DB ofrece varios niveles de consistencia (Fuerte, Vínculo Limitado, Sesión, Prefijo Consistente y Eventual), permitiendo a los desarrolladores elegir el equilibrio adecuado entre rendimiento y consistencia de datos según sus necesidades.

85 85 Azure Cosmos DB (44/53) Aunque ya hemos hablado
de los niveles de consistencia vamos a realizara un pequeño recordatorio: • Fuerte (Strong): Garantiza la mayor consistencia, pero puede aumentar la latencia. • Vínculo Limitado (Bounded Staleness): Ofrece buena consistencia dentro de ciertos límites de tiempo o versiones. • Sesión (Session): Mantiene la consistencia dentro de una sesión de usuario. • Prefijo Consistente (Consistent Prefix): Asegura que las actualizaciones se leen en el orden en que se escriben. • Eventual (Eventual): Ofrece la menor latencia, pero puede ser menos consistente. Configurar el nivel de consistencia predeterminado (default consistency) ajusta cómo se comportan las operaciones de lectura por defecto en tu base de datos. Esto se puede establecer cuando se crea la cuenta de Cosmos DB, y también se puede cambiar en cualquier momento posterior. Caso de Uso Replicación global Supongamos que estás desarrollando una plataforma de redes sociales con usuarios repartidos por todo el mundo. Los usuarios crean y consumen contenido (publicaciones, comentarios, likes, etc.) y requieren acceso rápido y confiable a sus datos, sin importar donde se encuentren. Desafío • Disponibilidad y Latencia: Los usuarios deben tener acceso rápido y fiable al contenido que crean y consumen. Además, la plataforma debe seguir estando disponible incluso en caso de interrupciones en una región particular. • Conformidad y Consistencia: Se necesitan diferentes niveles de consistencia para diferentes tipos de operaciones (por ejemplo, publicaciones de contenido deben ser altamente consistentes, mientras que los recuentos de likes pueden tener un nivel de consistencia eventual).

86 86 Azure Cosmos DB (45/53) Solución con Replicación Global
1. Configuración de la Replicación Global • Regiones de Replicación: Selecciona múltiples regiones geográficas para replicar tu base de datos. Por ejemplo, Norteamérica, Europa y Asia. • Azure Portal: Usa el portal de Azure para configurar la replicación. • Navega a tu cuenta de Azure Cosmos DB. • Selecciona la pestaña "Replica Data Globally". • Elige las regiones adicionales donde quieras replicar los datos. • Configura el nivel de consistencia global para tu aplicación. 2. Aplicación de la Replicación • Alta Disponibilidad: Con datos replicados en múltiples regiones, tu plataforma podrá manejar interrupciones en una región debido a que las otras regiones pueden continuar proporcionando el servicio. • Distribución de Tráfico: El tráfico de usuarios se puede dirigir a la región más cercana, reduciendo la latencia y mejorando la experiencia del usuario.

87 87 Azure Cosmos DB (46/53) Cache Integrada Aplicable a
NoSQL. La caché integrada de Azure Cosmos DB proporciona una solución en memoria que mejora la administración de costos y reduce la latencia a medida que aumenta el volumen de solicitudes. Su configuración es sencilla y elimina la necesidad de escribir código adicional para la invalidación de caché o de gestionar la infraestructura de back-end. Esta caché utiliza una puerta de enlace dedicada, la cual puede configurarse en cuanto al número de nodos y al tamaño de cada nodo según los núcleos y la memoria que su carga de trabajo demande. Cada nodo con puerta de enlace dedicada tiene una caché integrada e independiente. La caché integrada se activa automáticamente en la puerta de enlace dedicada e incluye: • Una caché de elementos para lecturas puntuales. • Una caché de consulta para consultas.

88 88 Azure Cosmos DB (47/53) Opera como una caché
de lectura y escritura. Y sigue una política de eliminación basada en los elementos menos usados recientemente (LRU). Tanto la caché de elementos como la caché de consulta comparten el mismo espacio de almacenamiento dentro de la caché integrada, siendo esta política de LRU aplicable a ambas. Esto significa que los datos se eliminan de la caché basándose únicamente en la última vez que se utilizaron, sin distinción entre datos de consulta o de lecturas puntuales. Además, los datos almacenados en caché en cada nodo dependen de los datos que han sido leídos o escritos recientemente a través de ese nodo específico, por lo que un elemento o consulta almacenados en un nodo no necesariamente estarán en caché en los otros nodos.

89 89 Azure Cosmos DB (48/53) Caso de Uso Contexto
Para una empresa de fabricación de chips, Cosmos DB podría desempeñar un papel crucial en la gestión de datos operativos y analíticos. Requisitos • Tipo de Datos: • Local: Datos de producción de chips en cada fábrica. • Área: Datos de control de calidad y mantenimiento. • Regional: Datos de rendimiento de producción y logística. • Global: Datos de ventas, distribución y análisis de mercado. • Usuarios: • Operador de Línea de Producción: Acceso a datos de producción local. • Ingeniero de Calidad: Acceso a datos de control de calidad en su área. • Gerente de Producción Regional: Acceso a datos de producción y logística regional. • Gerente de Ventas Global: Acceso a datos de ventas y análisis global.

90 90 Azure Cosmos DB (49/53) Arquitectura de Alto Nivel
• Datos Operativos: • Almacenamiento Local: Cada fábrica almacena datos de producción en Cosmos DB, lo que permite gestionar diferentes modelos de datos según las necesidades específicas de cada planta (por ejemplo, diferentes tipos de chips). • Replicación Regional: Datos críticos como rendimiento y mantenimiento se replican a nivel regional para análisis de tendencias y mejora de procesos. • Acceso Global: Datos de ventas y distribución son accesibles globalmente para la toma de decisiones estratégicas. • Análisis de Datos: • Uso de la tienda analítica integrada de Cosmos DB para realizar análisis casi en tiempo real de los datos de producción y calidad sin afectar las operaciones diarias. • Integración con Azure Synapse para realizar uniones complejas y análisis avanzados de datos de ventas y mercado.

91 91 Azure Cosmos DB (50/53) Beneficios de Cosmos DB
• Flexibilidad del Modelo de Datos: Permite almacenar y gestionar diferentes tipos de datos, desde información de producción en tiempo real hasta datos de ventas históricos. • Distribución Geográfica: Facilita la replicación de datos entre diferentes plantas y oficinas globales, asegurando la coherencia y disponibilidad de los datos. • Modelos de Consistencia Personalizables: Ajuste de la consistencia de los datos según las necesidades de cada proceso, equilibrando latencia y consistencia. • Capacidad de Análisis en Tiempo Real: La tienda analítica permite realizar análisis sin necesidad de procesos ETL complejos, lo cual es crítico para la mejora continua de la producción. • Escalabilidad y Disponibilidad: Garantiza el nivel de rendimiento necesario mediante un SLA, adaptándose a las variaciones en la demanda de producción. Este enfoque permite a la empresa de fabricación de chips optimizar su cadena de producción y distribución, mejorar la calidad de sus productos y adaptar rápidamente sus estrategias de mercado basadas en datos analíticos precisos.

92 92 Azure Cosmos DB (51/53) Diagrama de Arquitectura de
Datos Nota del autor Podríamos estar hablando de datos producción local como información IoT de los Robot de fabricación e incluso información propia del chip (número de serie década componente)

93 93 Azure Cosmos DB (52/53) Diagrama de Flujo de
Usuarios

94 94 Azure Cosmos DB (53/53) Diagrama de Análisis de
Datos ¿Qué es el almacén analítico de Azure Cosmos DB?

95 95 API Mongo DB (1/71) Introducción ¿Qué es la
API de MongoDB? La API de MongoDB en Azure Cosmos DB nos permite utilizar la misma sintaxis y comandos que usarían con una base de datos de MongoDB tradicional, pero aprovechando las características únicas de Azure Cosmos DB, como la escalabilidad global y la baja latencia. MongoDB es una base de datos NoSQL altamente popular, conocida por su flexibilidad y capacidad para manejar grandes volúmenes de datos no estructurados. Puntos clave: • Compatibilidad: La API de MongoDB en Cosmos DB es totalmente compatible con las herramientas y los controladores de MongoDB existentes. Esto significa que cualquier aplicación que funcione con MongoDB se puede migrar a Cosmos DB sin necesidad de cambiar el código. • Documentos JSON: Al igual que MongoDB, Cosmos DB con la API de MongoDB almacena datos en formato de documentos JSON, permitiendo una fácil manipulación y consulta de datos. • Ecosistema de MongoDB: podemos usar usar las mismas herramientas que usan para MongoDB, como MongoDB Compass, MongoDB Shell, Studio 3T, VS Code Extension for MongoDB y otros clientes.

96 96 API Mongo DB (2/71) Si quieres trabajar con
MongoDB nativo tienes varias opciones: • Opción 1: Crear una Cuenta Gratuita en la Nube (MongoDB Atlas). MongoDB Atlas es el servicio de base de datos en la nube completamente administrado por MongoDB. Es una forma rápida y sencilla de comenzar sin tener que preocuparse por la infraestructura subyacente. • Opción 2: Usar Docker para Ejecutar MongoDB. • Opción 3: Instalar el Servidor de MongoDB Localmente. • Opción 4: Azure Cosmos DB for MongoDB. Nota del autor En muchos escenarios, Azure Cosmos DB con la API de MongoDB puede resultar más económico en comparación con MongoDB Atlas debido a su modelo de precios flexible basado en unidades de solicitud, la inclusión de mantenimiento y gestión en el costo base, y las opciones de escalado y replicación global más costo-efectivas. La elección final dependerá de las necesidades específicas de cada aplicación y organización, pero aquellos que busquen una solución de base de datos gestionada y escalable a un costo competitivo, desde mi experiencia, pueden encontrar en Azure Cosmos DB una opción muy atractiva.

97 97 API Mongo DB (3/71) Ventajas de usar la
API de MongoDB en Cosmos DB • Escalabilidad Global: Azure Cosmos DB está diseñado para ser una base de datos global distribuida que permite replicar los datos en diversas regiones alrededor del mundo. Esta capacidad de replicación reduce la latencia de acceso a los datos y proporciona alta disponibilidad. • Baja Latencia: Independientemente de la ubicación geográfica del usuario, la API de MongoDB en Cosmos DB garantiza acceso de baja latencia a los datos. • Disponibilidad de Nueve: Cosmos DB ofrece SLA (Service Level Agreement) para disponibilidad, latencia, rendimiento, y consistencia, proporcionando una confianza excepcional en el servicio. • Modelo de Consistencia Flexible: Cosmos DB proporciona cinco niveles de consistencia ajustables: Fuerte, Sesión, Prefijo Consistente, Eventual, y Bounded Staleness. Esto permite a los usuarios elegir el nivel de consistencia que mejor se adapte a sus necesidades específicas. • Consistencia Fuerte: Garantiza que las operaciones de lectura siempre devuelvan los datos más recientes. • Consistencia Eventual: Mejora el rendimiento y reduce la latencia a costa de la consistencia inmediata. • Capacidad de Escalado Elástico: Cosmos DB permite un escalado elástico y automático según la demanda del tráfico de la aplicación, reduciendo la complejidad y los costos asociados al manejo de la infraestructura. • Auto-escalado: Capacidad de ajustar automáticamente los recursos provisionados según la carga de trabajo. • Costos Predecibles: Modelo de precios basado en unidades de solicitud (RU/s) que facilita la estimación y previsión de costos.

98 98 API Mongo DB (4/71) • Integración con el
Ecosistema de Azure: Cosmos DB con la API de MongoDB se integra perfectamente con otros servicios de Azure, como Azure Functions, Logic Apps, y servicios de Machine Learning, permitiendo el desarrollo rápido y la implementación de aplicaciones complejas en la nube. • DevOps y CI/CD: Integración con Azure DevOps para un ciclo de vida de desarrollo completo y eficiente. • Big Data y Analítica: Fácil integración con servicios de análisis de datos como Azure Synapse Analytics y Azure Data Lake. Casos de Uso Comunes • Aplicaciones Web y Móviles de Alta Demanda: Para aplicaciones que requieren baja latencia y alta disponibilidad global, la API de MongoDB en Cosmos DB es una opción ideal. Ejemplos incluyen: • Aplicaciones de Redes Sociales: Donde los usuarios esperan una interacción casi en tiempo real. • E-Commerce Global: Que requiere disponibilidad en múltiples regiones para mejorar la experiencia del usuario. • IoT y Telemetría en Tiempo Real: Las soluciones de Internet de las Cosas (IoT) generan grandes volúmenes de datos en tiempo real que deben ser procesados y analizados rápidamente. Cosmos DB con la API de MongoDB ofrece una solución robusta para este tipo de escenarios: • Data Ingestion en Tiempo Real: Recopilación y análisis de datos de dispositivos IoT. • Dashboards en Tiempo Real: Presentación de datos de telemetría y analítica en dashboards en tiempo real.

99 99 API Mongo DB (5/71) • Backends de Capa
de Datos para Microservicios: La arquitectura de microservicios requiere bases de datos que puedan escalar y manejar concurrentemente múltiples servicios pequeños y autónomos. Cosmos DB es ideal para estas arquitecturas por su escalabilidad y flexibilidad. • Gestión de Usuarios: Manejo eficiente de perfiles y accesos de usuario. • Catalog Management: Gestión de catálogos de productos, inventarios y otros datos dinámicos. • Aplicaciones Fintech y Gestión Financiera: En el sector financiero, la alta disponibilidad, confiabilidad y bajo tiempo de respuesta son extremadamente importantes. La API de MongoDB en Cosmos DB ofrece: • Transacciones Financieras: Gestión segura y eficiente de las transacciones financieras. • Análisis de Fraude: Detección y prevención de actividad fraudulenta en tiempo real.

100 100 API Mongo DB (6/71) Operaciones CRUD Básicas Configuración
del Entorno Ya os he comentado que existen 2 opciones principales y además también existe la opción de usar capacidad reservada, que abarata los costes:

101 101 API Mongo DB (7/71) Vamos a crear una
con la versión RU y con las siguientes opciones:

102 102 API Mongo DB (8/71) Vamos a instalar la
extensión de VS Code para MongoDB y así poder ver los datos, también tienes la opción del Data Explorer. Nota del autor Aquí la parte que más difiere con API de NoSQL es la creación de la colección, es aquí donde podremos ver que nos van a pedir si queremos un Shard o por el contrario no, pero con una restricción de un máximo de 20GB.

103 103 API Mongo DB (9/71) Y como podréis observar
este Quick Start ya es algo diferente al que teníamos con el API de NoSQL: Nota del autor Las opciones disponibles son similares a las que teníamos con el API de NoSQL. Solo voy a entrar en detalle en aquella/s que son de especial interés para MongoDB.

104 104 API Mongo DB (10/71) Operaciones Desde un Playground
En MongoDB, las operaciones CRUD permiten a los desarrolladores gestionar eficazmente la información almacenada en documentos JSON. Estas operaciones son esenciales para el mantenimiento y manipulación de datos dentro de las colecciones de MongoDB, y optimizar su uso es crucial para el rendimiento de las aplicaciones. • Creación de Documentos • Inserción de un Documento: Para insertar un documento en MongoDB, usamos el método insertOne. Este método agrega un solo documento a la colección especificada. // Seleccionar la base de datos a usar use('mongodbSampleDB'); // Insertar un documento en la colección 'users' db.getCollection('users').insertOne({ 'name': 'Alicia', 'age': 25, 'city': 'Madrid' });

105 105 API Mongo DB (11/71) • Inserción de Múltiples
Documentos: Para insertar múltiples documentos, usamos el método insertMany. • Lectura de Documentos • Utilizamos los métodos find y findOne para recuperar documentos de una colección. find devuelve todos los documentos que coinciden con los criterios, mientras que findOne devuelve solo el primero que coincide. // Insertar múltiples documentos en la colección 'users' db.getCollection('users').insertMany([ { 'name': 'Alicia', 'age': 25, 'city': 'Madrid' }, { 'name’: ‘Pau', 'age': 30, 'city': 'Barcelona' } ]); // Leyendo documentos con find db.getCollection('users').find({ city: 'Madrid' }).toArray(); // Leyendo un solo documento con findOne db.getCollection('users').findOne({ name: 'Alicia' });

106 106 API Mongo DB (12/71) • Filtros de Consulta
Básicos: Los filtros nos permiten especificar criterios detallados para encontrar los documentos que necesitamos. • Lectura de Documentos • Métodos updateOne y updateMany: Estos métodos se utilizan para actualizar documentos existentes. // Filtro básico de consulta const usersInMadrid = db.getCollection('users').find({ city: 'Madrid' }).count(); // Actualizar un solo documento db.getCollection('users').updateOne( { 'name': 'Alicia' }, { $set: { 'city': ‘Sevilla' } } ); // Actualizar múltiples documentos, incrementa en 1 la edad db.getCollection('users').updateMany( { 'age': { $lt: 30 } }, { $inc: { 'age': 1 } } );

107 107 API Mongo DB (13/71) • Eliminación de Documentos
• Métodos deleteOne y deleteMany: Estos métodos eliminan documentos de una colección según los criterios especificados. // Eliminar un solo documento db.getCollection('users').deleteOne( { 'name': 'Alice' } ); // Eliminar múltiples documentos db.getCollection('users').deleteMany( { 'age': { $eq: 30 } } ); Nota del autor Los anteriores ejemplos son la forma estándar de trabajar con MongoDB y desde muchos editores nos permiten trabajar así, pero como estamos en el mundo .NET y C# os voy a poner como se debe hacer en .NET.

108 108 API Mongo DB (14/71) Acciones Descripción (solo aquellos
que no son auto-explicativos) db.<collection>.insert() db.<collection>.insertOne() db.<collection>.insertMany() db.<collection>.save() Actualiza un documento existente o inserta uno nuevo. db.<collection>.update() db.<collection>.updateOne() db.<collection>.updateMany() db.<collection>.drop() Borra completamente la colección. db.<collection>.remove() Borra uno o varios documentos en base a un filtro. db.<collection>.deleteOne() db.<collection>.deleteMany() db.<collection>.find() Se amplia en el siguiente cuadro.

109 109 API Mongo DB (15/71) Acciones Descripción (solo aquellos
que no son auto-explicativos) $eq Equal $gt Greather $gte Greather than or equal: {age: {$gt:10}} $lt Less tan $lte Less than or equal $ne Not ecual $in In: {lastname: {$in: [“doe”, “foo”]}} $nin None $or Or $and And: db.users.find($and:[{firtsname:”jhon”},{lasname:”doe”}]}); $not Not $regex Documentos que comienzan con m: {a: {$regex: “^m”}}

110 110 API Mongo DB (16/71) Operaciones Desde .NET en
C# Usaremos la biblioteca MongoDB.Driver y una cadena de conexión personalizada para conectarnos a nuestra base de datos de MongoDB. using System; using MongoDB.Bson; using MongoDB.Driver; using System.Threading.Tasks; namespace MongoDB_CRUD_Example { class Program { private static IMongoCollection<BsonDocument> GetUsersCollection() { string connectionString = "your-connection-string"; MongoClient client = new MongoClient(connectionString); IMongoDatabase database = client.GetDatabase("mongodbSampleDB"); return database.GetCollection<BsonDocument>("users"); } static async Task Main(string[] args) { var collection = GetUsersCollection();

111 111 API Mongo DB (17/71) await InsertOneDocument(collection); await InsertManyDocuments(collection);
await FindDocuments(collection); await FindOneDocument(collection); await UpdateOneDocument(collection); await UpdateManyDocuments(collection); await DeleteOneDocument(collection); await DeleteManyDocuments(collection); } // Creación de Documentos private static async Task InsertOneDocument(IMongoCollection<BsonDocument> collection) { var document = new BsonDocument { { "name", "Alicia" }, { "age", 25 }, { "city", "Madrid" } }; await collection.InsertOneAsync(document); Console.WriteLine("Inserted one document."); } private static async Task InsertManyDocuments(IMongoCollection<BsonDocument> collection) { var documents = new [] { new BsonDocument { { "name", "Alicia" }, { "age", 25 }, { "city", "Madrid" } }, new BsonDocument { { "name", “Pau" }, { "age", 30 }, { "city", "Barcelona" } } }; await collection.InsertManyAsync(documents); Console.WriteLine("Inserted multiple documents."); }

112 112 API Mongo DB (18/71) // Lectura de Documentos
private static async Task FindDocuments(IMongoCollection<BsonDocument> collection) { var filter = Builders<BsonDocument>.Filter.Eq("city", "Madrid"); var documents = await collection.Find(filter).ToListAsync(); Console.WriteLine("Found documents:"); foreach (var doc in documents) { Console.WriteLine(doc.ToString()); } } private static async Task FindOneDocument(IMongoCollection<BsonDocument> collection) { var filter = Builders<BsonDocument>.Filter.Eq("name", "Alicia"); var document = await collection.Find(filter).FirstOrDefaultAsync(); Console.WriteLine("Found one document:"); Console.WriteLine(document.ToString()); } // Actualización de Documentos private static async Task UpdateOneDocument(IMongoCollection<BsonDocument> collection) { var filter = Builders<BsonDocument>.Filter.Eq("name", "Alicia"); var update = Builders<BsonDocument>.Update.Set("city", "Seville"); var result = await collection.UpdateOneAsync(filter, update); Console.WriteLine($"Matched {result.MatchedCount} document(s) and modified {result.ModifiedCount} document(s) for update one."); } private static async Task UpdateManyDocuments(IMongoCollection<BsonDocument> collection) { var filter = Builders<BsonDocument>.Filter.Lt("age", 30); var update = Builders<BsonDocument>.Update.Inc("age", 1); var result = await collection.UpdateManyAsync(filter, update); Console.WriteLine($"Matched {result.MatchedCount} document(s) and modified {result.ModifiedCount} document(s) for update many.");

113 113 API Mongo DB (19/71) // Eliminación de Documentos
private static async Task DeleteOneDocument(IMongoCollection<BsonDocument> collection) { var filter = Builders<BsonDocument>.Filter.Eq("name", "Alicia"); var result = await collection.DeleteOneAsync(filter); Console.WriteLine($"Deleted {result.DeletedCount} document(s) for delete one."); } private static async Task DeleteManyDocuments(IMongoCollection<BsonDocument> collection) { var filter = Builders<BsonDocument>.Filter.Eq("age", 30); var result = await collection.DeleteManyAsync(filter); Console.WriteLine($"Deleted {result.DeletedCount} document(s) for delete many."); } } }

114 114 API Mongo DB (20/71) Operaciones Desde .NET en
C# Usaremos la biblioteca MongoDB.Driver y una cadena de conexión personalizada para conectarnos a nuestra base de datos de MongoDB. using System; using MongoDB.Bson; using MongoDB.Driver; using System.Threading.Tasks; namespace MongoDB_CRUD_Example { class Program { private static IMongoCollection<BsonDocument> GetUsersCollection() { string connectionString = "your-connection-string"; MongoClient client = new MongoClient(connectionString); IMongoDatabase database = client.GetDatabase("mongodbSampleDB"); return database.GetCollection<BsonDocument>("users"); } static async Task Main(string[] args) { var collection = GetUsersCollection();

115 115 API Mongo DB (21/71) Aspectos Avanzados Vamos a
ver diversos ejemplos avanzados en sintaxis nativa y el equivalente en C#. Operadores de Comparación MongoDB Nativo // Documentos con edad mayor a 25 db.getCollection('users').find({ age: { $gt: 25 } }); // Documentos con edad menor o igual a 30 db.getCollection('users').find({ age: { $lte: 30 } });

116 116 API Mongo DB (22/71) C# private static async
Task FindByComparisonOperators(IMongoCollection<BsonDocument> collection) { // Mayor que ($gt) var filterGt = new BsonDocument("age", new BsonDocument("$gt", 25)); var documentsGt = await collection.Find(filterGt).ToListAsync(); Console.WriteLine("Documents with age > 25:"); foreach (var doc in documentsGt) Console.WriteLine(doc); // Menor o igual que ($lte) var filterLte = new BsonDocument("age", new BsonDocument("$lte", 30)); var documentsLte = await collection.Find(filterLte).ToListAsync(); Console.WriteLine("Documents with age <= 30:"); foreach (var doc in documentsLte) Console.WriteLine(doc); }

117 117 API Mongo DB (23/71) Operadores Lógicos MongoDB Nativo
// Documentos donde la ciudad es 'Madrid' y la edad es mayor o igual a 25 db.getCollection('users').find({ $and: [ { city: 'Madrid' }, { age: { $gte: 25 } } ] }); // Documentos donde la ciudad es 'Madrid' o la edad es menor de 25 db.getCollection('users').find({ $or: [ { city: 'Madrid' }, { age: { $lt: 25 } } ] }); // Documentos donde la ciudad no es 'Madrid' db.getCollection('users').find({ city: { $not: { $eq: 'Madrid' } } });

Task FindByLogicalOperators(IMongoCollection<BsonDocument> collection) { // Operador AND ($and) var filterAnd = new BsonDocument("$and", new BsonArray { new BsonDocument("city", "Madrid"), new BsonDocument("age", new BsonDocument("$gte", 25)) }); var documentsAnd = await collection.Find(filterAnd).ToListAsync(); Console.WriteLine("Documents matching AND condition:"); foreach (var doc in documentsAnd) Console.WriteLine(doc); // Operador OR ($or) var filterOr = new BsonDocument("$or", new BsonArray { new BsonDocument("city", "Madrid"), new BsonDocument("age", new BsonDocument("$lt", 25)) }); var documentsOr = await collection.Find(filterOr).ToListAsync(); Console.WriteLine("Documents matching OR condition:"); foreach (var doc in documentsOr) Console.WriteLine(doc); // Operador NOT ($not) var filterNot = new BsonDocument("city", new BsonDocument("$not", new BsonDocument("$eq", "Madrid"))); var documentsNot = await collection.Find(filterNot).ToListAsync(); Console.WriteLine("Documents not in Madrid:"); foreach (var doc in documentsNot) Console.WriteLine(doc); }

119 119 API Mongo DB (25/71) Creación de Índices MongoDB
Nativo C# // Crear un índice en los campos 'age' y 'city' db.getCollection('users').createIndex({ age: 1, city: 1 }); private static async Task CreateAndUseIndices(IMongoCollection<BsonDocument> collection) { // Crear un índice var indexKeysDefinition = Builders<BsonDocument>.IndexKeys.Ascending("age").Ascending("city"); var indexModel = new CreateIndexModel<BsonDocument>(indexKeysDefinition); await collection.Indexes.CreateOneAsync(indexModel); Console.WriteLine("Index created on age and city fields."); // Usar el índice creado en una consulta var filter = new BsonDocument("city", "Madrid"); var documents = await collection.Find(filter).Sort(new BsonDocument("age", 1)).ToListAsync(); Console.WriteLine("Documents found using index:"); foreach (var doc in documents) Console.WriteLine(doc); }

120 120 API Mongo DB (26/71) Sobre los índices: Los
índices en MongoDB son estructuras que mejoran la velocidad de las operaciones de búsqueda en una colección. Al igual que en muchas bases de datos, los índices en MongoDB pueden acelerar significativamente las consultas al permitir búsquedas más eficientes y accesos más rápidos a los datos. En el contexto de Azure Cosmos DB con la API de MongoDB, los índices tienen algunas peculiaridades y beneficios adicionales. • Concepto de Índices en MongoDB: un índice es una estructura de datos que almacena una pequeña parte de la colección de datos en una forma fácil de trabajar. Los índices permiten que las operaciones de consulta busquen documentos específicos de manera más eficiente de lo que podrían usando un simple recorrido secuencial de la base de datos. • Índices Predeterminados: MongoDB automáticamente crea un índice en el campo _id cuando se crea una nueva colección. • Índices Compuestos: Permitir combinaciones de múltiples campos para optimizar consultas complejas. • Índices Únicos: Garantizan la unicidad de los datos en los campos indexados, evitando entradas duplicadas. • Peculiaridades de los Índices en Azure Cosmos DB con la API de MongoDB: cuando se utiliza la API de MongoDB en Azure Cosmos DB, se heredan muchas de las características fundamentales de los índices de MongoDB, pero con algunos matices que optimizan aún más el rendimiento y la gestión en un entorno de base de datos globalmente distribuido.

121 121 API Mongo DB (27/71) • Gestión Automática de
Índices: Azure Cosmos DB proporciona una gestión automática de índices muy eficiente. Al crear una colección en Cosmos DB utilizando la API de MongoDB, Azure Cosmos DB configura y mantiene automáticamente índices sobre cada campo en los documentos hasta un nivel de anidación definido. • Índices Autoadministrados: Los índices se gestionan automáticamente, reduciendo la necesidad de tareas administrativas manuales y la carga operativa. • Índices Globales: A diferencia del MongoDB tradicional, Cosmos DB implementa índices que son eficientes a nivel global para minimizar la latencia en una base de datos distribuida globalmente. • Personalización y Exclusiones de Índices: Aunque Azure Cosmos DB gestiona automáticamente los índices, permite configurar exclusiones de índices. Esto es útil si quieres evitar el indexado en campos específicos que no sean necesarios para las consultas frecuentes. • Exclusión de Campos: Personaliza qué campos deberían o no ser indexados para optimizar el rendimiento en tareas específicas. • Control de Índices: Similar al índice compuesto, puedes definir los documentos JSON que representan el índice de política que se quiere excluir o incluir. • Índices Compuestos: Como en MongoDB tradicional, la API de MongoDB en Cosmos DB permite la creación de índices compuestos, que incluye múltiples campos en un solo índice. • Consultas Complejas: Ideal para optimizar consultas que filtran o clasifican en varios campos. • Optimización de Rendimiento: Minimiza el tiempo de consulta en operaciones complejas, proporcionando eficacia y velocidad en el acceso a datos distribuidos.

122 122 API Mongo DB (28/71) TTL (Time-to-Live) Hay un
tema que es crucial para el manejo eficiente de los datos en MongoDB y en Cosmos DB con la API de MongoDB: los índices TTL (Time-to-Live). Los índices TTL permiten a los desarrolladores configurar un tiempo de vida para los documentos en una colección, especificando cuándo deben ser automáticamente eliminados. Esta funcionalidad es especialmente útil para gestionar datos temporales y mantener la base de datos limpia y eficiente sin la necesidad de realizar limpiezas manualmente. Importancia de los Índices TTL • Gestión Automática de Datos Temporales: Permite eliminar automáticamente documentos que ya no son válidos o necesarios. • Optimización de Almacenamiento: Ayuda a reducir el uso del almacenamiento al eliminar datos obsoletos. • Mantenimiento y Rendimiento: Facilita el mantenimiento de la base de datos y mejora el rendimiento al asegurarse de que solo los datos relevantes son almacenados.

123 123 API Mongo DB (29/71) MongoDB Nativo C# //
Crear un índice TTL en el campo 'createdAt' con un tiempo de expiración de 3600 segundos (1 hora) db.getCollection('users').createIndex( { "createdAt": 1 }, { expireAfterSeconds: 3600 } ); private static async Task CreateTTLIndex(IMongoCollection<BsonDocument> collection) { // Definir el índice TTL en el campo 'createdAt' con un tiempo de expiración de 3600 segundos (1 hora) var indexKeysDefinition = Builders<BsonDocument>.IndexKeys.Ascending("createdAt"); var indexOptions = new CreateIndexOptions { ExpireAfter = TimeSpan.FromSeconds(3600) }; var indexModel = new CreateIndexModel<BsonDocument>(indexKeysDefinition, indexOptions); await collection.Indexes.CreateOneAsync(indexModel); Console.WriteLine("TTL Index created on 'createdAt' field with expiration of 1 hour."); } // Ejemplo de inserción de un documento con el campo 'createdAt' private static async Task InsertDocumentWithTTL(IMongoCollection<BsonDocument> collection) { var document = new BsonDocument { { "name", "John Doe" }, { "createdAt", DateTime.UtcNow } }; await collection.InsertOneAsync(document); Console.WriteLine("Inserted document with 'createdAt' field."); }

124 124 API Mongo DB (30/71) Agregaciones … ... Pipelines:
Las agregaciones de tipo pipeline son la forma más común y potentes de realizar operaciones de agregación en MongoDB. Un pipeline de agregación consiste en una serie de etapas que se aplican secuencialmente a los documentos de entrada de una colección, transformándolos en la salida deseada. Cada etapa del pipeline realiza una operación diferente, como filtrado, agrupación, ordenación y agrupación. MongoDB Nativo // Agrupando usuarios por ciudad y calculando la edad promedio y el total de usuarios db.getCollection('users').aggregate([ { $match: { city: 'Madrid' } }, { $group: { _id: "$city", averageAge: { $avg: "$age" }, totalUsers: { $sum: 1 } }} ]);

Task AggregateDocuments(IMongoCollection<BsonDocument> collection) { var pipeline = new[] { new BsonDocument("$match", new BsonDocument("city", "Madrid")), new BsonDocument("$group", new BsonDocument { { "_id", "$city" }, { "averageAge", new BsonDocument("$avg", "$age") }, { "totalUsers", new BsonDocument("$sum", 1) } }) }; var result = await collection.Aggregate<BsonDocument>(pipeline).ToListAsync(); Console.WriteLine("Aggregation result:"); foreach (var doc in result) Console.WriteLine(doc); }

126 126 API Mongo DB (32/71) Al ejecutar un pipeline,
MongoDB canaliza operaciones entre sí. Si estas familiarizado con el concepto de pipeline de Linux, sería una buena analogía. Es decir, que la salida de un operador se convierte en la entrada del siguiente operador. El resultado de cada operador es una nueva colección de documentos. Por ejemplo, una posible canalización sería: Podemos agregar tantos operadores en el pipeline como queramos; también podemos agregar el mismo operador más de una vez y en una posición diferente de la canalización: collection $project $match $group $project $group = result collection $project $match $group = result

127 127 API Mongo DB (33/71) ... Map-Reduce: Map-Reduce es
otra forma de realizar agregaciones en MongoDB y es particularmente útil cuando se necesitan operaciones complejas y personalizadas que no se pueden expresar fácilmente con pipelines de agregación. Map-Reduce emplea dos funciones JavaScript: • map: recorre cada documento de entrada y emite pares clave-valor intermedios. • reduce: combina los valores intermedios asociados a la misma clave para producir los resultados agregados. MongoDB Nativo var mapFunction = function() { emit(this.city, this.age); }; var reduceFunction = function(key, values) { return Array.avg(values); }; db.getCollection('users').mapReduce( mapFunction, reduceFunction, { out: "average_age_by_city" } );

Task MapReduceDocuments(IMongoCollection<BsonDocument> collection) { var mapFunction = "function() { emit(this.city, this.age); }"; var reduceFunction = "function(key, values) { return Array.avg(values); }"; var options = new BsonDocument { { "mapReduce", collection.CollectionNamespace.CollectionName }, { "map", mapFunction }, { "reduce", reduceFunction }, { "out", new BsonDocument("inline", 1) } }; var command = new BsonDocumentCommand<BsonDocument>(options); var result = await collection.Database.RunCommandAsync(command); Console.WriteLine("Map-Reduce result:"); Console.WriteLine(result); } Nota del autor Siempre he tenido problemas con el driver de MongoDB en .NET al realizar este tipo de consultas, unas veces por que he visto en la documentación que esta obsoleto, otras no se sabe por qué da error, etc. Y donde nunca he tenido problemas en con mongoose de Node.JS.

Task MapReduceDocuments(IMongoCollection<BsonDocument> collection) { var mapFunction = "function() { emit(this.city, this.age); }"; var reduceFunction = "function(key, values) { return Array.avg(values); }"; var options = new BsonDocument { { "mapReduce", collection.CollectionNamespace.CollectionName }, { "map", mapFunction }, { "reduce", reduceFunction }, { "out", new BsonDocument("inline", 1) } }; var command = new BsonDocumentCommand<BsonDocument>(options); var result = await collection.Database.RunCommandAsync(command); Console.WriteLine("Map-Reduce result:"); Console.WriteLine(result); }

130 130 API Mongo DB (36/71) ... De un solo
proposito: MongoDB ofrece diversos métodos de agregación de un solo propósito como count(), distinct(), y group(), que pueden utilizarse directamente en la colección. Estos métodos proporcionan una manera rápida y sencilla de realizar ciertas operaciones de agregación comunes. MongoDB Nativo para Distinct() C# para Distinct() // Obtener los nombres únicos de las ciudades db.getCollection('users').distinct("city"); private static async Task DistinctCities(IMongoCollection<BsonDocument> collection) { var cities = await collection.DistinctAsync<string>("city", new BsonDocument()).ToListAsync(); Console.WriteLine("Distinct cities:"); foreach (var city in cities) Console.WriteLine(city); }

131 131 API Mongo DB (37/71) Operador Unwind Uno de
los operadores más poderosos y comúnmente utilizados en pipelines de agregación es $unwind. El operador $unwind descompone un arreglo en distintos documentos, es decir, toma cada elemento de un arreglo y lo descomprime en un documento individual. Los datos originales: [ { "nombre": "Alicia", "edad": 25, "ciudad": "Madrid", "hobbies": ["leer", "viajar", "nadar"] }, { "nombre": “Pau", "edad": 30, "ciudad": "Barcelona", "hobbies": ["cocinar", "correr"] }, { "nombre": "Carlos", "edad": 28, "ciudad": "Sevilla", "hobbies": ["viajar", "fotografía"] } ]

132 132 API Mongo DB (38/71) Mongo DB Nativo C#
// Descomprimir el 'hobbies' de cada usuario en documentos individuales db.getCollection('users').aggregate([ { $unwind: "$hobbies" }, { $group: { _id: "$hobbies", totalUsers: { $sum: 1 } }} ]); private static async Task AggregateWithUnwind(IMongoCollection<BsonDocument> collection) { var pipeline = new[] { new BsonDocument("$unwind", "$hobbies"), new BsonDocument("$group", new BsonDocument { { "_id", "$hobbies" }, { "totalUsers", new BsonDocument("$sum", 1) } }) }; var result = await collection.Aggregate<BsonDocument>(pipeline).ToListAsync(); Console.WriteLine("Resultado de la agregación con $unwind y $group:"); foreach (var doc in result) Console.WriteLine(doc); }

133 133 API Mongo DB (39/71) Los datos tras usar
el $unwind: Los datos tras usar el $group: [ { "nombre": "Alicia", "edad": 25, "ciudad": "Madrid", "hobbies": "leer" }, { "nombre": "Alicia", "edad": 25, "ciudad": "Madrid", "hobbies": "viajar" }, { "nombre": "Alicia", "edad": 25, "ciudad": "Madrid", "hobbies": "nadar" }, { "nombre": "Bob", "edad": 30, "ciudad": "Barcelona", "hobbies": "cocinar" }, { "nombre": "Bob", "edad": 30, "ciudad": "Barcelona", "hobbies": "correr" }, { "nombre": "Carlos", "edad": 28, "ciudad": "Sevilla", "hobbies": "viajar" }, { "nombre": "Carlos", "edad": 28, "ciudad": "Sevilla", "hobbies": "fotografía" } ] [ { "_id": "leer", "totalUsers": 1 }, { "_id": "viajar", "totalUsers": 2 }, { "_id": "nadar", "totalUsers": 1 }, { "_id": "cocinar", "totalUsers": 1 }, { "_id": "correr", "totalUsers": 1 }, { "_id": "fotografía", "totalUsers": 1 } ]

134 134 API Mongo DB (40/71) Resumen y algo más,
de lo que hemos visto hasta ahora db.collection.aggregate([ { <stage 1> }, { <stage 2>}, … ]); Operador Descripción Equivalencia SQL $project Cambias cada documento en la secuencia, por ejemplo, agregando o quitando campos. SELECT $match Autoexplicativo. Filtra el flujo para que entre lo que coincida con lo que se pide. WHERE $redact Cambia la forma de cada documento en la secuencia restringiendo el contenido de cada documento basado en la información almacenada en los documentos. Más información aquí. N/A $limit Autoexplicativo. Limita la salida al numero de documento que indiques. LIMIT / TOP $skip Autoexplicativo. Salta n documentos. LIMIT / OFFSET $unwind Ir a la sección donde se explicaba este mecanismo. Es más usado que $redact. N/A $group Agrupa documentos de entrada por una expresión de identificador(s) y aplica la(s) expresión(es) de acumulador, si se especifica, a cada grupo. GROUP BY $sort Autoexplicativo. Ordenar documentos. ORDER BY $lookup Realiza una combinación left-outer con la colección. JOIN $out Escribe los documentos resultantes de la canalización. Se debe usar en la ultima etapa. SELECT ... ... Y muchas más cosas que puedes ver en la documentación oficial … ...

135 135 API Mongo DB (41/71) Colecciones Limitadas (Capped Collections)
Son colecciones que tienen un tamaño fijo y mantienen sus datos en orden de inserción. A medida que se insertan nuevos documentos y se alcanza el tamaño máximo de la colección, los documentos más antiguos se eliminan automáticamente para dar cabida a los nuevos documentos. Esto asegura un tamaño constante para la colección, lo que puede ser muy útil para ciertos tipos de aplicaciones, como registros de logs, datos de telemetría, y cualquier escenario donde solo los datos más recientes sean relevantes. Características de las Colecciones Limitadas: • Tamaño Fijo: Puedes especificar el tamaño máximo de la colección en bytes en el momento de su creación. Una vez alcanzado este límite, los documentos más antiguos se eliminan automáticamente conforme se insertan nuevos documentos. • Orden de Inserción: Las colecciones limitadas mantienen los documentos en el orden en que fueron insertados y no permiten la eliminación individual de documentos. • Alto Rendimiento: Debido a su naturaleza ordenada y tamaño fijo, las operaciones de inserción son muy rápidas y eficientes. • Limitaciones de Actualización: Las actualizaciones de documentos no pueden aumentar el tamaño del documento. Si se intenta aumentar el tamaño del documento, la operación producirá un error.

136 136 API Mongo DB (42/71) Mongo DB Nativo C#
// Crear una colección limitada con tamaño máximo de 1MB y 1000 documentos db.createCollection("logs", { capped: true, size: 1048576, max: 1000 }); private static async Task CreateCappedCollection(IMongoDatabase database) { var options = new CreateCollectionOptions { Capped = true, MaxSize = 1048576, // Tamaño máximo de la colección en bytes (1MB) MaxDocuments = 1000 // Número máximo de documentos }; await database.CreateCollectionAsync("logs", options); Console.WriteLine("Colección limitada 'logs' creada."); }

137 137 API Mongo DB (43/71) Migraciones de MongoDB a
Azure CosmosDB • Utilizar Azure Database Migration Service para realizar migraciones de MongoDB a Azure Cosmos DB for MongoDB RU sin conexión. • Migración de MongoDB a Azure Cosmos DB for MongoDB RU en línea mediante Azure Database Migration Service.

138 138 API Mongo DB (44/71) ¿Te sientes apurado para
traducir de SQL a MongoDB? Supongamos que soy un experto en SQL Server y por supuesto del lenguaje de consultas, puedo hacer cualquier cosa en 5 minutos, pero me toca irme a MongoDB y no se como hacer una consulta, pues gracias a la IA Generativa lo tienes muy fácil. Partimos de: queremos realizar una consulta para obtener la suma total de los montos de los pedidos para cada cliente en una ciudad específica, y además, filtrar aquellos clientes cuyo total de pedidos sea mayor a un valor determinado. Por ejemplo, queremos extraer los clientes de la ciudad "Madrid" con un total de pedidos mayor a 1000. En SQL es así de sencilla, para mí, que soy un experto en SQL: SELECT c.CustomerID, c.Name, SUM(o.Amount) as TotalAmount FROM Customers c JOIN Orders o ON c.CustomerID = o.CustomerID WHERE c.City = 'New York' GROUP BY c.CustomerID, c.Name HAVING SUM(o.Amount) > 1000;

139 139 API Mongo DB (45/71) Si la estructura de
datos fuera similar, es decir, fuese relacional, en ambos casos: Con el siguiente Prompt, tendrías una consulta casi de inmediato: Quiero que traduzcas la consulta de SQL <inserta la consulta> que tiene esta estructura de datos <estructura de ejemplo> a una consulta de MongoDB Nativo. { "_id": ObjectId("..."), "customerID": NumberInt(1), "name": "John Doe", "city": "New York" } { "_id": ObjectId("..."), "orderID": NumberInt(1001), "customerID": NumberInt(1), "orderDate": ISODate("2023-04- 10T00:00:00Z"), "amount": 500 }

140 140 API Mongo DB (46/71) Lógicamente es una conversión:
db.customers.aggregate([ // Primero, hacemos un join con la colección 'orders' { $lookup: { from: "orders", localField: "customerID", foreignField: "customerID", as: "ordersInfo" } }, // Aplanamos el array resultante de 'ordersInfo' { $unwind: "$ordersInfo" }, // Aplicamos filtros y operaciones de agrupación { $match: { "city": "New York" } }, { $group: { _id: { customerID: "$customerID", name: "$name" }, totalAmount: { $sum: "$ordersInfo.amount" } } }, // Filtramos clientes con total de pedidos mayor a 1000 { $match: { totalAmount: { $gt: 1000 } } }, // Proyectamos el formato final de salida { $project: { _id: 0, customerID: "$_id.customerID", name: "$_id.name", totalAmount: 1 } } ]);

141 141 API Mongo DB (47/71) Tal y como están
los datos y la consulta que hemos realizado, los RUs se disparan de coste y cada vez que ejecutemos algo tan sencillo nos estaremos gastando más de lo que pensábamos. A través del ejemplo anterior a parte de mostraros como la IA Generativa nos puede ayudar, a convertir cosas también os muestro que una mala migración de SQL a NoSQL es una ruina. Voy a continuar con el ejemplo como si hubiéramos creado una conversión ayudándonos de las ventajas de las NoSQL. { "_id": ObjectId("..."), "name": "John Doe", "city": "New York", "orders": [ { "orderID": ObjectId("..."), "date": ISODate("2023-04-10T00:00:00Z"), "amount": 500 }, { "orderID": ObjectId("..."), "date": ISODate("2023-04-15T00:00:00Z"), "amount": 600 } ] }

142 142 API Mongo DB (48/71) Nuestra consulta ahora sería:
db.customers.aggregate([ // Filtramos clientes que están en la ciudad "New York" { $match: { "city": "New York" } }, // Desenmascaramos y agrandamos el array 'orders' { $unwind: "$orders" }, // Aplicamos agrupación por 'customerId' para sumar los totales de los montos de órdenes { $group: { _id: { customerId: "$_id", name: "$name" }, totalAmount: { $sum: "$orders.amount" } } }, // Filtramos aquellos clientes cuyo total de órdenes sea mayor a 1000 { $match: { totalAmount: { $gt: 1000 } } }, // Proyectamos el formato final de salida { $project: { _id: 0, customerId: "$_id.customerId", name: "$_id.name", totalAmount: 1 } } ]);

143 143 API Mongo DB (49/71) Comparación de RUs antes
y después con un ejemplo de Playground en MongoDB: https://gist.github.com/jmfloreszazo/fc5e926e70e5b3290d83b6ddc84ec172

144 144 API Mongo DB (50/71) Estos son los resultados:
Por lo que podemos concluir con: • Separate Collections (Clientes y órdenes en colecciones separadas) Operación Base de Datos RequestCharge (RUs) RequestDuration (ms) Inserción de Clientes mongodbSampleDBSeparateCollectio ns 45.25 457 nserción de Órdenes mongodbSampleDBSeparateCollectio ns 50.59 365 Inserción de Clientes mongodbSampleDBUnifiedCollections 45.25 390 Consulta mongodbSampleDBSeparateCollectio ns 5.05 4 Consulta mongodbSampleDBUnifiedCollections 5.34 14

145 145 API Mongo DB (51/71) • Ventajas: • Consultas
más eficientes y baratas: La consulta find en colecciones separadas usa solo 5.05 RUs y tarda 4ms, mientras que la consulta aggregate en la unificada requiere 5.34 RUs y 14ms. • Mejor rendimiento en operaciones CRUD: Las inserciones están distribuidas en dos colecciones, lo que puede reducir bloqueos y mejorar la escalabilidad. • Mejor organización y normalización: Sigue el principio de separación de responsabilidades, lo que facilita la evolución del modelo de datos sin afectar toda la estructura. • Desventajas: • Consultas más complejas pueden requerir joins o agregaciones que no son tan eficientes en MongoDB como en bases de datos relacionales. • Mayor número de colecciones a administrar. • Debes ejecutar acciones en la memoria del cliente, y aquí entra en juego balancear qué es más eficiente: ¿usar la memoria o usar la colección y trabajar con agregaciones? ¿Enviar los datos unificados a analíticas o no? En el ejemplo, estamos iterando en memoria con:: customersInNewYork.forEach(customer => {… • Unified Collection (Clientes y órdenes en una sola colección) • Ventajas: • Inserciones más rápidas y centralizadas: No es necesario realizar múltiples operaciones en distintas colecciones. • Consultas que requieren joins son más simples porque los datos ya están agrupados.

146 146 API Mongo DB (52/71) • Ventajas: • Consultas
más eficientes y baratas: La consulta find en colecciones separadas usa solo 5.05 RUs y tarda 4ms, mientras que la consulta aggregate en la unificada requiere 5.34 RUs y 14ms. • Mejor rendimiento en operaciones CRUD: Las inserciones están distribuidas en dos colecciones, lo que puede reducir bloqueos y mejorar la escalabilidad. • Mejor organización y normalización: Sigue el principio de separación de responsabilidades, lo que facilita la evolución del modelo de datos sin afectar toda la estructura. • Desventajas: • Consultas más costosas y lentas: Se observa que aggregate requiere más RUs y tiempo que find en las colecciones separadas. • Mayor consumo de RUs en el tiempo si las consultas se vuelven más complejas. • Escalabilidad más difícil: Si la colección crece demasiado, puede afectar la eficiencia de las consultas y actualizaciones.

147 147 API Mongo DB (53/71) • Conclusión: ¿Cuál es
mejor a largo plazo? Si el objetivo es optimizar CRUD y consultas complejas, separar las colecciones es la mejor opción. Razones principales: • Consultas más eficientes y económicas en términos de RUs. • Menos impacto en el rendimiento a medida que la base de datos crece. • Mejor organización y escalabilidad a largo plazo. Si la aplicación tiene más consultas que requieren múltiples joins y el acceso frecuente a datos combinados justifica el costo adicional de las agregaciones. Y para terminar os dejo un Prompt que uso para poder optimizar consultas de MongoDB, pero siempre teniendo en cuenta esto.

148 148 API Mongo DB (54/ 71) Administración y Seguridad
Estrategias de particionamiento (sharding) En MongoDB, el escalado se gestiona mediante un proceso llamado Sharding. Se trata de una configuración manual que permite escalar una instancia de MongoDB añadiendo más capacidad de cómputo y almacenamiento. MongoDB realiza la fragmentación de datos a nivel de colección; por lo tanto, cada colección se distribuye en múltiples shards. Aunque ya he hablado sobre el sharding, quiero retomar este tema, ya que es de vital importancia en las bases de datos de MongoDB. // MongoDB Nativo db.adminCommand({ shardCollection: "myDatabase.myCollection", key: { shardKey: 1 } // Definición de la clave de partición }); // C#: Crear colección con clave de partición var containerProperties = new ContainerProperties("shardingCollection", "/partitionKey"); var container = await database.Database.CreateContainerIfNotExistsAsync(containerProperties, throughput: 400);

149 149 API Mongo DB (55/ 71) APP Server ROUTER
1 (mongos) APP Server ROUTER N (mongos) Shard 1 (replica set) Shard N (replica set) Config Server (replica set) ... ...

150 150 API Mongo DB (56/ 71) En un clúster
fragmentado de MongoDB, existen tres categorías principales de componentes: • Mongos: Actúan como routers de consulta para lecturas y escrituras, dirigiendo las peticiones a los shards correspondientes. Su función es abstraer la fragmentación, manteniendo los metadatos de los shards para localizar los datos de manera eficiente. • Servidores de configuración: Almacenan los ajustes de configuración y los metadatos de cada shard. Estos servidores deben estar configurados como un Replica Set para garantizar la disponibilidad y consistencia de los datos. • Shards: Son los nodos reales que contienen un subconjunto de los datos del clúster. MongoDB divide los datos en fragmentos denominados chunks, los cuales se distribuyen y equilibran dinámicamente entre los shards mediante un balanceador de carga del clúster. La estrategia de fragmentación es crucial para optimizar el rendimiento. Existen tres tipos de shard key para definir cómo se distribuyen los datos: • Range Key: Basado en rangos de valores, es la metodología más utilizada, ya que no emplea hashing ni zonas, permitiendo un acceso más eficiente a los datos. Y que se puede usar en Azure Cosmos DB.

151 151 API Mongo DB (57/ 71) • Hashed Key:
calculan el valor hash de la clave y la usa para distribuir los datos a un nodo en forma de rangos. Que no se puede usar en Azure Cosmos DB. • Zones: fragmentos basados en una zona geográfica, o en un clúster específico o debido a problemas legales de los datos. Que no se puede usar en Azure Cosmos DB. < 20 Chunck Shard-1 < 30 Chunck Shard-1 < 40 Chunck Shard-1 Age: 19 Age: 25 Age: 39 Hashing Function Zone = 1 Chunck Shard-1 Zone = 1, 2 Chunck Shard-1 Zone = 3 Chunck Shard-1 Age: 19 Age: 25 Age: 39 Hashing Function

152 152 API Mongo DB (58/ 71) En un clúster
fragmentado de MongoDB, existen tres categorías principales de componentes: • Mongos: Actúan como routers de consulta para lecturas y escrituras, dirigiendo las peticiones a los shards correspondientes. Su función es abstraer la fragmentación, manteniendo los metadatos de los shards para localizar los datos de manera eficiente. • Servidores de configuración: Almacenan los ajustes de configuración y los metadatos de cada shard. Estos servidores deben estar configurados como un Replica Set para garantizar la disponibilidad y consistencia de los datos. • Shards: Son los nodos reales que contienen un subconjunto de los datos del clúster. MongoDB divide los datos en fragmentos denominados chunks, los cuales se distribuyen y equilibran dinámicamente entre los shards mediante un balanceador de carga del clúster. La estrategia de fragmentación es crucial para optimizar el rendimiento. Existen tres tipos de shard key para definir cómo se distribuyen los datos: • Range Key: Basado en rangos de valores, es la metodología más utilizada, ya que no emplea hashing ni zonas, permitiendo un acceso más eficiente a los datos. Y que se puede usar en Azure Cosmos DB.

153 153 API Mongo DB (59/ 71) Es fundamental seleccionar
una clave de fragmentación óptima, ya que será la base del rendimiento en operaciones de lectura y escritura. Pero en nuestro caso con Azure Cosmos DB, ese trabajo ya lo hace el recurso por nosotros, solo usa un tipo. Una vez elegida la clave de fragmentación, no se puede modificar; si es necesario cambiarla, se debe recrear la colección. Una estrategia efectiva es elegir la clave en función de los patrones de consulta. Por ejemplo, si siempre realizas búsquedas basadas en una empresa, lo ideal sería fragmentar por su ID, asegurando que los datos relacionados se almacenen en el mismo nodo, optimizando así el acceso. Comparto esta información por si en algún momento trabajáis con MongoDB nativo fuera de Azure Cosmos DB, donde la fragmentación funciona de manera más flexible.

154 154 API Mongo DB (60/ 71) Seguridad Autenticación using
System; using System.Threading.Tasks; using Microsoft.Azure.Cosmos; class Program { private static readonly string EndpointUri = "https://your-cosmos-db-endpoint.documents.azure.com:443/"; private static readonly string PrimaryKey = "your-cosmos-db-key"; private static CosmosClient cosmosClient; static async Task Main(string[] args) { cosmosClient = new CosmosClient(EndpointUri, PrimaryKey); // Acceso a la base de datos y colección var database = cosmosClient.GetDatabase("sampleDatabase"); var container = database.GetContainer("sampleCollection"); // Ejemplo de inserción de documentos await container.CreateItemAsync(new { id = "1", name = "John Doe", city = "New York" }); Console.WriteLine("Authentication and data insertion successful!"); } }

155 155 API Mongo DB (61/ 71) Autorización para MongoDB
Nativo Para la asignación de roles en Cosmos DB, generalmente gestionarás estos a través del portal de Azure, PowerShell o la CLI de Azure. La gestión de roles no se puede realizar directamente a través del SDK de Cosmos DB. db.createRole({ role: "readWriteRole", privileges: [ { resource: { db: "exampleDB", collection: "" }, actions: ["find", "insert", "update", "remove"] } ], roles: [] });

156 156 API Mongo DB (62/ 71) Cifrados de conexiones
El SDK de Cosmos DB utiliza TLS/SSL por defecto, por lo que no necesitas configuraciones adicionales en la mayoría de los casos. Aquí mostramos cómo asegurar que las conexiones están encriptadas: using System; using System.Threading.Tasks; using Microsoft.Azure.Cosmos; class Program { private static readonly string EndpointUri = "https://your-cosmosdb-endpoint.documents.azure.com:443/"; private static readonly string PrimaryKey = "your-cosmos-db-key"; private static CosmosClient cosmosClient; static async Task Main(string[] args) { var cosmosClientOptions = new CosmosClientOptions { ApplicationName = "CosmosDBDotnetQuickstart", ConnectionMode = ConnectionMode.Direct, GatewayModeMaxConnectionLimit = 100, ResponseContinuationTokenLimitInKb = 1024, RequestTimeout = new TimeSpan(0, 1, 0), // 1 minuto MaxRetryAttemptsOnThrottledRequests = 9, MaxRetryWaitTimeOnThrottledRequests = new TimeSpan(0, 0, 30) // 30 segundos }; // Asegurar conexiones seguras cosmosClient = new CosmosClient(EndpointUri, PrimaryKey, cosmosClientOptions); // Acceso a la base de datos y colección var database = cosmosClient.GetDatabase("sampleDatabase"); var container = database.GetContainer("sampleCollection"); // Ejemplo de inserción de documentos await container.CreateItemAsync(new { id = "1", name = "John Doe", city = "New York" }); Console.WriteLine("Secure connection and data insertion successful!"); } }

157 157 API Mongo DB (63/ 71) Mejores Prácticas de
Rendimiento Optimización de Consultas La optimización de consultas en MongoDB y Azure Cosmos DB implica varias estrategias clave, que hemos discutido anteriormente, pero aquí detallamos algunos puntos adicionales: • Filtrado y Proyección Eficientes: • Utiliza operadores de comparación específicos ($eq, $lt, $lte, $gt, $gte, $ne) y otros operadores de consulta ($in, $nin, etc.) para filtrar datos de manera eficiente. • Asegúrate de proyectar solo los campos necesarios utilizando el operador $project en las consultas y etapas de agregación. Reducir los datos retornados mejora significativamente el rendimiento. db.collection.find( { "field": { $gt: 5 } }, { "field1": 1, "field2": 1 } );

158 158 API Mongo DB (64/ 71) • Uso de
Agregaciones: • Las agregaciones permiten ejecutar consultas complejas de manera más eficiente utilizando el pipeline de agregación. Utiliza etapas como $match, $group, $unwind, y $sort para optimizar el rendimiento. Uso eficiente de índices El uso eficiente de índices es crucial para mejorar el rendimiento de las consultas en MongoDB y Azure Cosmos DB. Aquí se incluyen algunos aspectos clave: • Creación de Índices: • Crea índices en los campos usados frecuentemente en las consultas de filtro, ordenación y proyección. • Usa índices compuestos para consultas que filtran por múltiples campos. db.collection.aggregate([ { $match: { "city": "New York" } }, { $unwind: "$orders" }, { $group: { _id: "$_id", totalAmount: { $sum: "$orders.amount" } } }, { $match: { totalAmount: { $gt: 1000 } } }, { $project: { _id: 0, customerId: "$_id", totalAmount: 1 } } ]);

159 159 API Mongo DB (65/ 71) • Índices Multikey:
• Los índices multikey pueden indexar arrays y son útiles para consultas que involucran varios valores. • Índices Texto: • Los índices de texto pueden acelerar las consultas de búsqueda de texto, usando el operador $text. • Uso de $explain: • Usa el método $explain para comprender mejor cómo MongoDB ejecuta tus consultas y optimizar los índices en consecuencia.. db.collection.createIndex({ "field1": 1, "field2": -1 }); db.collection.createIndex({ "arrayField": 1 }); db.collection.createIndex({ "description": "text" }); db.collection.find({ "field": "value" }).explain("executionStats");

160 160 API Mongo DB (66/ 71) Técnicas de Comprensión
y Almacenamiento La compresión y el almacenamiento eficiente son aspectos importantes para controlar los costos y mejorar el rendimiento en Azure Cosmos DB. • Compresión de Datos: • Las técnicas de compresión de datos ayudan a reducir el tamaño del almacenamiento y el uso de ancho de banda. Azure Cosmos DB aplica compresión en nivel de almacenamiento automáticamente, pero mantener los documentos compactos es clave. • Minimiza los tamaños de los documentos eliminando datos redundantes y utilizando tipos de datos eficientes (por ejemplo, int en lugar de string cuando sea posible). • Optimización del Almacenamiento: • Diseña tus documentos para que sean lo más pequeños posible, evitando anidar documentos innecesariamente y manteniendo arrays dentro de un tamaño manejable. • Usa técnicas de normalización y desnormalización de acuerdo con los patrones de acceso a tus datos para optimizar el almacenamiento y las consultas. • TTL (Time-to-Live) Indexes, del que hemos hablado antes: • Aplica índices TTL para eliminar automáticamente los documentos obsoletos después de un cierto período, ahorrando espacio de almacenamiento y manteniendo los datos actualizados.

161 161 API Mongo DB (67/ 71) • Modelo de
Datos Adecuado: • Escoge el modelo de datos adecuado según las necesidades de tu aplicación. Un diseño en anchura puede ser más adecuado para casos con relaciones complejas y consultas que requieran varios documentos relacionados. • Usa una clave de partición adecuada para distribuir datos uniformemente en todos los nodos del clúster. Una buena clave de partición puede mejorar significativamente el rendimiento y evitar cuellos de botella. Escalado Automático (Autoscale) La característica llamada autoscale permite ajustar automáticamente la cantidad de Request Units por segundo (RUs/s) en función de la carga actual de la aplicación. • Configuración de Autoscale: • RUs mínimos y máximos: Cuando configuras el autoscale, defines un límite máximo de RUs/s y Cosmos DB ajustará las RUs automáticamente entre un mínimo y ese máximo según sea necesario. • Beneficios del Autoscale: Mejora la administración y reduce los costos al ajustar los recursos automáticamente según la demanda variable, sin necesidad de intervención manual.

162 162 API Mongo DB (68/ 71) using Microsoft.Azure.Cosmos; using
System.Threading.Tasks; public class AutoscaleExample { private static readonly string EndpointUri = "https://your-cosmos-db-endpoint.documents.azure.com:443/"; private static readonly string PrimaryKey = "your-cosmos-db-key"; private static CosmosClient cosmosClient; public static async Task Main(string[] args) { cosmosClient = new CosmosClient(EndpointUri, PrimaryKey); Database database = await cosmosClient.CreateDatabaseIfNotExistsAsync("myDatabase"); ContainerProperties containerProperties = new ContainerProperties("myContainer", "/partitionKey"); ThroughputProperties autoscaleThroughput = ThroughputProperties.CreateAutoscaleThroughput(10000); Container container = await database.CreateContainerIfNotExistsAsync(containerProperties, autoscaleThroughput); Console.WriteLine("Container created with autoscale enabled."); } }

163 163 API Mongo DB (69/ 71) Límites de Partición
• Particionamiento: Azure Cosmos DB distribuye tus datos entre varias particiones para asegurar el escalado horizontal. Cada partición representa un subconjunto de tu colección y se identifica usando una clave de partición. • Clave de Partición: La selección correcta de la clave de partición es crítica para el rendimiento y la escalabilidad. • Buena distribución: La clave debe permitir una distribución uniforme de los datos para evitar la concentración de datos en una sola partición, lo que podría convertirse en un cuello de botella. • Usabilidad en Consultas: La clave de partición debe ser utilizada en todas las consultas para asegurar que las operaciones se distribuyan eficientemente. ContainerProperties properties = new ContainerProperties(id: "myContainer", partitionKeyPath: "/partitionKey");

164 164 API Mongo DB (70/ 71) Gestión de grandes
volúmenes de datos • Desnormalización: En algunos casos, es mejor replicar ciertos datos en lugar de mantener relaciones complejas entre documentos (join-like queries). Esto minimiza el número de lecturas necesarias. • Control de Tamaño de Documentos: Mantén tus documentos a un tamaño manejable para optimizar el rendimiento y la eficiencia de almacenamiento. • Uso de TTL. • Bulk Operations: Utiliza el SDK de Cosmos DB para ejecutar operaciones en lote, lo que reduce las RUs totales y mejora la eficiencia de procesamiento. Ejemplos de Escalabilidad en Aplicaciones Reales Aplicación de Comercio Electrónico • Características Escalables: • Escalado Horizontal: Almacenar catálogos de productos de millones de artículos, con particionamiento basado en categorías de productos. • Índices de Texto: Utilizar índices de texto para búsquedas rápidas de productos mediante descripciones y nombres. • Autoscale: Implementar autoscale para manejas picos de tráfico durante ventas y promociones.

165 165 API Mongo DB (71/ 71) Sistema de Monitoreo
de IoT • Características Escalables: • Almacenamiento de Streams: Recibir y almacenar datos constantemente de dispositivos IoT en tiempo real. • TTL: Configurar TTL para eliminar datos antiguos automáticamente y mantener el almacenamiento manejable. • Sharding Dinámico: Hacer particionamiento basado en la ubicación geográfica de los dispositivos para mejorar la latencia. Red Social • Características Escalables: • Desempeño en tiempo real: Manejar grandes volúmenes de mensajes y actividades de usuario en tiempo real. • Desnormalización selectiva: Almacenar directamente la cantidad de "likes" en las publicaciones para evitar operaciones de join frecuentes. • Operaciones Bulk: Utilizar operaciones en lote para procesar métricas y análisis de grandes volúmenes de datos de usuario de forma eficiente.

166 166 Gremlin API (1/18) Aspectos Básicos ¿Qué es Gremlin?
Gremlin es un lenguaje de consulta de grafos que forma parte de Apache TinkerPop, un framework de procesamiento de grafos. Gremlin permite realizar operaciones complejas de navegación y manipulación en grafos, proporcionando una forma poderosa de interactuar con datos altamente conectados. Gremlin como lenguaje de consulta de grafos Gremlin se utiliza para • Consulta: Realizar búsquedas complejas en grafos. • Manipulación de Datos: Añadir, actualizar y eliminar vértices y aristas. • Análisis: Ejecución de algoritmos para analizar patrones, detectar comunidades, calcular caminos más cortos, entre otros.

167 167 Gremlin API (2/18) Importancia de los Grafos en
la Representación de Datos Complejos y Relaciones Los grafos son esenciales para representar entidades interconectadas y sus relaciones. En muchas aplicaciones, como redes sociales, recomendaciones, detección de fraudes, e IoT, las conexiones entre entidades son tan importantes como las entidades mismas. Los grafos ofrecen una forma natural y eficiente de modelar estas relaciones complejas. Arquitectura de Datos de Gremlin Vértices (Vertices): Los vértices representan entidades o nodos en el grafo. Cada vértice puede tener propiedades asociadas que describen sus atributos. Aristas (Edges): Las aristas representan las relaciones entre los vértices. Al igual que los vértices, las aristas también pueden tener propiedades que describen la naturaleza de la relación. Propiedades en Vértices y Aristas: Las propiedades son metadatos asociados a los vértices y aristas que describen información adicional, como atributos de un vértice (por ejemplo, el nombre o la edad de una persona) o detalles de una relación (como la fecha en que dos personas se conocieron).

168 168 Gremlin API (3/18) Configuración Inicial Creación de una
Cuenta de Cosmos DB con Gremlin API Para crear una cuenta de Cosmos DB con soporte para la API de Gremlin: 1. En el Portal de Azure, selecciona "Crear un recurso". 2. Busca "Azure Cosmos DB" y selecciona "Crear". 3. Selecciona "API de Gremlin" al configurar la cuenta. 4. Completa las configuraciones necesarias y crea la cuenta. 5. Herramientas para Interactuar con Gremlin API Algunas herramientas útiles para interactuar con Gremlin API incluyen: • Portal de Azure: Para gestionar la cuenta de Cosmos DB y ver gráficos. • Gremlin Console: Una herramienta de línea de comando para ejecutar consultas de Gremlin. • SDKs: Uso de SDKs en varios lenguajes de programación como Java, .NET, Python y más para interactuar programáticamente con Cosmos DB.

169 169 Gremlin API (4/18) Si quieres saber más Dispongo
de un documento que he usado en varias presentaciones y hablo sobre los grafos, aquí podrás ampliar mucha más información, ya que de ahora en adelante voy a ir directamente al grano. • Video en YouTube: Grafos, la tercera vía para nuestros datos, primera versión. • Presentación: Grafos, la tercera vía para nuestros datos, segunda versión. En esos enlaces estoy usando también una de las mejores bases de datos de grafos: Neo4j, que puede ser de vuestro interés, pero con cuidado, el lenguaje de consulta es otro muy distinto llamado Cypher. Operaciones CRUD Antes de empezar con las operaciones CRUD, asegúrate de tener los paquetes necesarios incluidos en tu proyecto: dotnet add package Gremlin.Net.Driver

170 170 Gremlin API (5/18) Crear using System; using System.Threading.Tasks;
using Gremlin.Net.Driver; using Gremlin.Net.Structure.IO.GraphSON; public class GremlinCrudExamples { private static readonly string Hostname = "your-cosmos-db-account.gremlin.cosmos.azure.com"; private static readonly int Port = 443; private static readonly string AuthKey = "your-cosmos-db-key"; private static readonly string Database = "your-database"; private static readonly string Graph = "your-graph"; private static GremlinClient gremlinClient; public static async Task Main(string[] args) { var gremlinServer = new GremlinServer(Hostname, Port, enableSsl: true, username: $"/dbs/{Database}/colls/{Graph}", password: AuthKey); using (gremlinClient = new GremlinClient(gremlinServer, new GraphSON2Reader(), new GraphSON2Writer(), Gremlin.Net.Driver.RequestMessage.KeepAlive))

171 171 Gremlin API (6/18) { // Create Vertex var
addVertexQuery = "g.addV('person').property('id', '1').property('name', 'John Doe').property('age', 29)"; await SubmitRequestAsync(addVertexQuery); // Create Edge var addEdgeQuery = "g.V('1').addE('knows').to(g.V('2'))"; await SubmitRequestAsync(addEdgeQuery); } } private static async Task SubmitRequestAsync(string query) { try { var resultSet = await gremlinClient.SubmitAsync<dynamic>(query); foreach (var result in resultSet) { Console.WriteLine(result); } } catch (Exception ex) { Console.WriteLine($"Error: {ex.Message}"); } } }

172 172 Gremlin API (7/18) Leer Actualizar public static async
Task ReadExampleAsync() { // Read Vertex var readVertexQuery = "g.V().has('person', 'name', 'John Doe')"; await SubmitRequestAsync(readVertexQuery); // Read Edge var readEdgeQuery = "g.E().hasLabel('knows')"; await SubmitRequestAsync(readEdgeQuery); } public static async Task UpdateExampleAsync() { // Update Vertex Property var updateVertexQuery = "g.V('1').property('age', 30)"; await SubmitRequestAsync(updateVertexQuery); // Update Edge Property var updateEdgeQuery = "g.E('e_id').property('since', '2023')"; await SubmitRequestAsync(updateEdgeQuery); }

173 173 Gremlin API (8/18) Borrar public static async Task
DeleteExampleAsync() { // Delete Vertex var deleteVertexQuery = "g.V('1').drop()"; await SubmitRequestAsync(deleteVertexQuery); // Delete Edge var deleteEdgeQuery = "g.E('e_id').drop()"; await SubmitRequestAsync(deleteEdgeQuery); }

174 174 Gremlin API (9/18) Aspectos Avanzados Clave de Partición
Para evitar cuellos de botella y asegurar que los datos se distribuyan de manera uniforme en todo el clúster, debes seleccionar una clave de partición adecuada. Una clave de partición es un atributo presente en cada vértice y arista que se utiliza para distribuir los datos en diferentes particiones físicas. Características de una Buena Clave de Partición: • Alta Cardinalidad: La clave de partición debe tener muchos valores únicos. Esto asegura que los datos se distribuyan de manera uniforme entre las particiones. • Consultas Frecuentes: La clave de partición debe ser un atributo por el que frecuentemente se consultan los datos, para maximizar la eficiencia de las consultas. // Crear vértice con propiedad de clave de partición "location“ para una red social suponiendo que los usuarios estan uniformemente distribuidos g.addV('person').property('id', '1').property('name', 'John Doe').property('location', 'New York').property('age', 29) // Crear arista con propiedad de clave de partición "location" g.V('1').addE('knows').to(g.V('2')).property('location', 'New York')

175 175 Gremlin API (10/18) Para el anterior ejemplo las
consultas serían: Índices Para optimizar el rendimiento de las consultas en Azure Cosmos DB con la API de Gremlin, el uso adecuado de índices es fundamental. Los índices aseguran que las consultas se ejecuten de manera eficiente, permitiendo buscar y recuperar datos rápidamente. Aquí te proporciono una guía sobre cómo gestionar y usar índices en Gremlin API, incluyendo ejemplos prácticos. Tipos de Índices en Cosmos DB con API de Gremlin: • Índices Automáticos: Cosmos DB indexa automáticamente todos los campos en los documentos, lo que significa que cualquier propiedad agregada a los vértices o aristas es indexada de forma predeterminada. Sin embargo, aún puedes personalizar los índices para mejorar la eficiencia. • Índices Personalizados: Permiten definir qué campos deben ser indexados y cómo. Puedes optar por indexar solamente ciertos campos o excluir otros para optimizar el rendimiento y reducir costos. // Buscar todas las personas en la partición 'New York' g.V().has('location', 'New York') // Buscar todas las aristas 'knows' en la partición 'New York' g.E().has('location', 'New York').hasLabel('knows')

176 176 Gremlin API (11/18) Por ejemplo: using Microsoft.Azure.Cosmos; using
System; using System.Threading.Tasks; public class IndexManagement { private static readonly string EndpointUri = "https://your-cosmos-db-endpoint.documents.azure.com:443/"; private static readonly string PrimaryKey = "your-cosmos-db-key"; private static CosmosClient cosmosClient; public static async Task Main(string[] args) { cosmosClient = new CosmosClient(EndpointUri, PrimaryKey); Database database = await cosmosClient.CreateDatabaseIfNotExistsAsync("your-database"); Container container = await CreateContainerWithIndexes(database); } private static async Task<Container> CreateContainerWithIndexes(Database database) {

177 177 Gremlin API (12/18) Y al consultar vía .has
un índice, la consulta será mucho más rápida: IndexingPolicy = new IndexingPolicy( new IncludedPath { Path = "/location/?" }, new IncludedPath { Path = "/name/?" }) { IndexingMode = IndexingMode.Consistent } }; return await database.CreateContainerIfNotExistsAsync(containerProperties, throughput: 400); } } // Consulta en un campo indexado g.V().has('location', 'New York')

178 178 Gremlin API (13/18) Por supuesto también se puede
consultar a las aristas que tengan índice: Con los índices podemos realizar consultas muy complejas como: // Consulta en un campo indexado g.E().has('location', 'New York').hasLabel('knows') ``` // Busqueda por patrones: encontrar personas mayores de 30 años que viven en 'New York' g.V().has('person', 'location', 'New York').has('age', gt(30)) // Agregaciones: contar personas según la ubicación g.V().hasLabel('person').groupCount().by('location’) // Filtros combinado: Encontrar amigos de personas en 'New York' que tengan más de 2 amigos g.V().has('location', 'New York').out('knows').groupCount().by('name').unfold().where(select(values).is(gt(2)))

179 179 Gremlin API (14/18) Operador Transversal Recursivo (Repeat) El
operador repeat permite realizar traversales recursivos a través de un grafo para encontrar caminos o realizar análisis de conectividad. Agrupar y Contar (Group y Count) // Encontrar amigos hasta una profundidad de 3 g.V('1').repeat(out('knows')).times(3).emit().path() // Contar el número de conexiones por tipo de relación g.V().group().by(label).by(bothE().count()) // Agrupar personas por edad y contar cuántas hay en cada grupo g.V().hasLabel('person').groupCount().by('age')

180 180 Gremlin API (15/18) Ordenación (Order) y Rangos (Range)
El operador repeat permite realizar traversales recursivos a través de un grafo para encontrar caminos o realizar análisis de conectividad. Patrones de Búsqueda (Match) // Obtener las 5 personas más jóvenes g.V().hasLabel('person').order().by('age', decr).limit(5) // Encontrar un patrón específico de amigos g.V().match( __.as('a').hasLabel('person').has('name', 'John Doe'), __.as('a').out('knows').as('b'), __.as('b').has('name', 'Jane Smith') ).select('a', 'b')

181 181 Gremlin API (16/18) Unión y Desunión (Unión, Coalesce)
Operaciones de Caminos (Path, SimplePath, CyclicPath) // Combinar resultados de dos traversales diferentesg.V().union( __.hasLabel('person').has('age', gt(30)), __.hasLabel('software').has('name', 'Gremlin’) ) // Realizar traversales alternativos y tomar el primer resultado válido g.V().coalesce( __.has('name', 'John Doe'), __.has('name', 'Jane Doe') ) // Encontrar todos los caminos simples en la red de amigos g.V('1').repeat(both()).until(__.loops().is(3)).simplePath().path() // Encontrar caminos que pasan por vértices específicos g.V('1').repeat(out()).until(hasId('5')).path()

182 182 Gremlin API (17/18) Subgrafos y Proyecciones (Subgraph, Cap)
Fold y Unfold Estos operadores son útiles para trabajar con listas o colecciones dentro de un traversal de Gremlin. • Fold: Agrupa los resultados en una lista. • Unfold: Desagrega una lista en sus componentes individuales. // Crear un subgrafo basado en un criterio g.V().hasLabel('person').has('name', 'John Doe').subgraph('subGraph').bothE().subgraph('subGraph').bothV().cap('subGraph’) // Proyección de propiedades específicas g.V().hasLabel('person').project('name', 'age').by('name').by('age') // Crear una lista de todas las personas y luego desplegar los resultados g.V().hasLabel('person').fold().unfold()

183 183 Gremlin API (18/18) Y muchos más • Local:
Ejecuta sub-traversals para cada elemento. • Select: Accede a elementos etiquetados previamente. • Dedup: Elimina elementos duplicados. • Choose: Opera como una estructura condicional para diferentes traversales. Aquí podrás ver las características que se soportan en Azure Comos DB para grafos usando el lenguaje Gremlin.

184 184 Cassandra API (1/11) Aspectos Básicos Cuando nos disponemos
a crear una base de datos de Cassandra, tenemos 2 opciones, en nuestro caso vamos a crearla por RU. Modelo de datos de Cassandra • Keyspace es el contenedor principal en Cassandra, equivalente a una base de datos en sistemas relacionales. Un keyspace agrupa las tablas y define aspectos importantes como las políticas de replicación y la estrategia de persistencia de los datos. Características del Keyspace: • Define el alcance de replicación de los datos. • Agrupa múltiples tablas bajo un mismo namespace lógico. • Creación de un Keyspace: Puedes crear un keyspace especificando la política de replicación y el factor de replicación.

185 185 Cassandra API (2/11) En este ejemplo: • SimpleStrategy
es la estrategia de replicación básica, adecuada para un solo datacenter. • replication_factor indica cuántas réplicas de cada dato se almacenan en el clúster. Estrategias de Replicación • SimpleStrategy • NetworkTopologyStrategy (Recomendado para clústers en múltiples datacenters): CREATE KEYSPACE my_keyspace WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 3}; CREATE KEYSPACE my_keyspace WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 3}; CREATE KEYSPACE my_keyspace WITH replication = {'class': 'NetworkTopologyStrategy', 'datacenter1': 3, 'datacenter2': 2};

186 186 Cassandra API (3/11) • Tables son análogas a
las tablas en SQL, y contienen filas de datos. Cada tabla define un esquema que incluye columnas y tipos de datos. Características de las Tables: • Estructura de columnas con tipos específicos. • Definición de claves primarias y claves de clustering. • Soporte para características avanzadas como TTL (Time-to-Live) específicas por fila. En este ejemplo: • user_id es la clave primaria. • La tabla users tiene columnas para first_name, last_name, y email. CREATE TABLE my_keyspace.users ( user_id UUID PRIMARY KEY, first_name text, last_name text, email text );

187 187 Cassandra API (4/11) • Rows son los registros
dentro de una tabla, análogos a las filas en tables relacionales. Cada fila contiene valores para las columnas definidas en la tabla. Características de las Rows: • Cada fila es identificada de manera única por su clave primaria. • Las filas pueden tener TTL para datos que no necesitan ser almacenados indefinidamente. • Particionamiento y Claves Primarias. Particionamiento es la manera en que Cassandra distribuye los datos en un clúster. Los datos se dividen en múltiples particiones basadas en la clave de partición. Cada partición se almacena en múltiples nodos según la estrategia de replicación. Claves Primarias en Cassandra son fundamentales para determinar la ubicación de los datos y el ordenamiento dentro de una partición. Se componen de: • Clave de Partición (Partition Key): Determina en qué nodo(s) se almacenan los datos. • Claves de Clustering (Clustering Keys): Definen el orden de los datos dentro de una partición. INSERT INTO my_keyspace.users (user_id, first_name, last_name, email) VALUES (uuid(), 'John', 'Doe', '[email protected]'); CREATE TABLE my_keyspace.user_activities ( user_id UUID, activity_id UUID, activity_date timestamp, activity_type text, PRIMARY KEY (user_id, activity_date) ) WITH CLUSTERING ORDER BY (activity_date DESC);

188 188 Cassandra API (5/11) CRUD Básicos en Cassandra Nativo
(CQL) // Crear KeySpace CREATE KEYSPACE IF NOT EXISTS my_keyspace WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 3}; // Crear Tabla CREATE TABLE IF NOT EXISTS my_keyspace.users ( user_id UUID PRIMARY KEY, first_name text, last_name text, email text ); // Create (Insertar Datos) INSERT INTO my_keyspace.users (user_id, first_name, last_name, email) VALUES (uuid(), 'John', 'Doe', '[email protected]’); // Read (Leer Datos) SELECT * FROM my_keyspace.users WHERE user_id = {uuid}; // Update (Actualizar Datos) UPDATE my_keyspace.users SET first_name = 'Jonathan', email = '[email protected]' WHERE user_id = {uuid}; // Delete (Eliminar Datos) DELETE FROM my_keyspace.users WHERE user_id = {uuid};

189 189 Cassandra API (6/11) CRUD Básicos en .NET El
primer paso sismpre es añadir el paquete NuGet correspondiente: dotnet add package CassandraCSharpDriver using System; using System.Threading.Tasks; using Cassandra; class Program { private static Cluster cluster; private static ISession session; static async Task Main(string[] args) { // Conecta al cluster de Cassandra cluster = Cluster.Builder() .AddContactPoint("your-cosmosdb-account.cassandra.cosmos.azure.com") .WithPort(10350) .WithAuthProvider(new PlainTextAuthProvider("username", "primary-key")) .WithSSL() .Build(); session = cluster.Connect();

190 190 // Crear Keyspace y Tabla si no existen
await session.ExecuteAsync(new SimpleStatement( "CREATE KEYSPACE IF NOT EXISTS my_keyspace WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 3};")); await session.ExecuteAsync(new SimpleStatement( "CREATE TABLE IF NOT EXISTS my_keyspace.users (user_id UUID PRIMARY KEY, first_name text, last_name text, email text);")); // Insertar Datos string insertQuery = "INSERT INTO my_keyspace.users (user_id, first_name, last_name, email) VALUES (?, ?, ?, ?);"; var insertStatement = new SimpleStatement(insertQuery, Guid.NewGuid(), "John", "Doe", "[email protected]"); await session.ExecuteAsync(insertStatement); // Leer Datos string selectQuery = "SELECT * FROM my_keyspace.users WHERE user_id = ?;"; var selectStatement = new SimpleStatement(selectQuery, new Guid("your-uuid")); var rowSet = await session.ExecuteAsync(selectStatement); foreach (var row in rowSet) { Console.WriteLine($"User: {row["first_name"]} {row["last_name"]}, Email: {row["email"]}"); } // Actualizar Datos string updateQuery = "UPDATE my_keyspace.users SET first_name = ?, email = ? WHERE user_id = ?;"; var updateStatement = new SimpleStatement(updateQuery, "Jonathan", "[email protected]", new Guid("your-uuid")); await session.ExecuteAsync(updateStatement); // Eliminar Datos string deleteQuery = "DELETE FROM my_keyspace.users WHERE user_id = ?;"; var deleteStatement = new SimpleStatement(deleteQuery, new Guid("your-uuid")); await session.ExecuteAsync(deleteStatement); } } Cassandra API (7/11)

191 191 Cassandra API (8/11) Aspectos Avanzados Cuando trabajas con
Cassandra, es muy útil conocer ciertos aspectos avanzados del sistema que te permitirán diseñar mejor tus modelos de datos y optimizar el rendimiento de tus aplicaciones. A continuación, se detallan algunos conceptos avanzados que debes conocer: Desnormalización En Cassandra, a diferencia de las bases de datos relacionales, se suele desnormalizar los datos para optimizar las consultas de lectura. Esto significa que puedes almacenar datos redundantes en diferentes tablas para evitar operaciones de join (unión) que pueden ser costosas. -- Tabla Principal CREATE TABLE my_keyspace.users ( user_id UUID PRIMARY KEY, first_name text, last_name text, email text ); -- Tabla de Actividades CREATE TABLE my_keyspace.user_activities ( user_id UUID, activity_id UUID, activity_date timestamp, activity_type text, PRIMARY KEY (user_id, activity_date) );

192 192 Cassandra API (9/11) Materialized Views Las vistas materializadas
permiten crear consultas alternativas sobre los datos sin duplicar los datos completos. Son útiles para diferentes patrones de acceso a los datos. Índices Secundarios • Los índices secundarios permiten realizar consultas de búsqueda basadas en columnas que no son claves de partición. • Útil para columnas que son frecuentemente consultadas, pero no forman parte de la clave primaria. CREATE MATERIALIZED VIEW my_keyspace.user_activities_by_type AS SELECT * FROM my_keyspace.user_activities WHERE activity_type IS NOT NULL AND activity_date IS NOT NULL PRIMARY KEY (activity_type, activity_date, user_id); CREATE INDEX ON my_keyspace.users (email);

193 193 Cassandra API (10/11) Consultas con Claves de Clustering
Puedes realizar consultas avanzadas usando claves primarias compuestas y claves de clustering. Consultas con Rangos Estrategias de Replicación Configurar estrategias de replicación adecuadas para asegurarse de que los datos sean altamente disponibles y resistentes a fallos. Niveles de Consistencia Puedes configurar el nivel de consistencia para las operaciones según lo requieras (ONE, QUORUM, ALL). SELECT * FROM my_keyspace.user_activities WHERE user_id = {user_id} ORDER BY activity_date DESC; SELECT * FROM my_keyspace.user_activities WHERE user_id = {user_id} AND activity_date > '2022-01-01' AND activity_date < '2023-01-01'; CREATE KEYSPACE my_keyspace WITH replication = {'class': 'NetworkTopologyStrategy', 'datacenter1': 3, 'datacenter2': 2}; SELECT * FROM my_keyspace.users WHERE user_id = {user_id} USING CONSISTENCY QUORUM;

194 194 Cassandra API (11/11) Niveles de Consistencia: • Consistency
Level ONE: Baja latencia, alta disponibilidad, menos consistencia. • Idóneo para operaciones rápidas donde la consistencia no es crítica. • Consistency Level QUORUM: Balance entre consistencia y disponibilidad. • Ideal para la mayoría de las aplicaciones. • Consistency Level ALL: Alta consistencia, menos disponibilidad y más latencia. • Adecuado para datos críticos donde es vital que todos los nodos estén sincronizados. Estrategias de Compactación Gestionar estrategias de compactación para mantener la performance y eficiencia del almacenamiento. Uso de TTL (Time-To-Live) ALTER TABLE my_keyspace.user_activities WITH compaction = {'class': 'SizeTieredCompactionStrategy'}; INSERT INTO my_keyspace.session_data (session_id, user_id, data) VALUES (uuid(), user_id, 'some data') USING TTL 86400;

195 195 Table API (1/9) Aspectos Básicos ¿Qué es la
Table API? • La Table API de Azure Cosmos DB proporciona acceso a datos en un modelo NoSQL basado en tablas. • Ofrece compatibilidad con Azure Table Storage, lo que facilita la migración de aplicaciones. • Al aprovechar Cosmos DB, obtienes escalabilidad global, opciones de consistencia configurables y baja latencia. Modelo de Datos en Table API • Entidad: Una fila en una tabla, análoga a una fila en una base de datos tabular. • Propiedades: Columnas dentro de una entidad, donde cada propiedad puede tener un tipo de datos específico (cadena, número entero, número de punto flotante, booleano, etc.). • Claves Primarias (Primary Keys): • PartitionKey: Elige la partición en la que se almacena la entidad. Ayuda a distribuir uniformemente los datos entre particiones. • RowKey: Identifica de manera única una entidad dentro de una partición. • Timestamp: Cada entidad incluye un campo de timestamp que indica la última vez que se actualizó. Nota del autor Internamente las Table Storages de la versión 2.0 me hacen sospechar que tiene como tecnología subyacente Azure Cosmos DB

196 196 Table API (2/9) Operaciones CRUD Básicas Sobre un
ejemplo: using Microsoft.Azure.Cosmos.Table; using System; using System.Threading.Tasks; class Program { static async Task Main(string[] args) { string storageConnectionString = "DefaultEndpointsProtocol=https;AccountName=yourAccountName;AccountKey=yourAccountKey;TableEndpoint=https://yourAccountName.table.cosmos.azure.com:443/;"; CloudStorageAccount storageAccount = CloudStorageAccount.Parse(storageConnectionString); CloudTableClient tableClient = storageAccount.CreateCloudTableClient(new TableClientConfiguration()); CloudTable table = tableClient.GetTableReference("myTable"); // Crear la tabla si no existe await table.CreateIfNotExistsAsync(); // Crear entidad DynamicTableEntity entity = new DynamicTableEntity("partitionKey", "rowKey") { Properties = { { "Property1", new EntityProperty("Value1") }, { "Property2", new EntityProperty(42) } } };

197 197 Table API (3/9) // Insertar entidad TableOperation insertOperation
= TableOperation.Insert(entity); await table.ExecuteAsync(insertOperation); // Leer entidad TableOperation retrieveOperation = TableOperation.Retrieve<DynamicTableEntity>("partitionKey", "rowKey"); TableResult result = await table.ExecuteAsync(retrieveOperation); DynamicTableEntity retrievedEntity = result.Result as DynamicTableEntity; if (retrievedEntity != null) { Console.WriteLine("Property1: " + retrievedEntity.Properties["Property1"].StringValue); Console.WriteLine("Property2: " + retrievedEntity.Properties["Property2"].Int32Value); // Actualizar entidad retrievedEntity.Properties["Property1"].StringValue = "UpdatedValue"; TableOperation updateOperation = TableOperation.Replace(retrievedEntity); await table.ExecuteAsync(updateOperation); // Eliminar entidad TableOperation deleteOperation = TableOperation.Delete(retrievedEntity); await table.ExecuteAsync(deleteOperation); } } }

198 198 Table API (4/9) Buenas Prácticas PartitionKey • La
clave de partición determina cómo se distribuyen los datos entre las particiones físicas. Esto afecta la escalabilidad y el rendimiento. • Una PartitionKey eficiente garantiza una distribución uniforme de los datos, evitando cuellos de botella y mejorando la paralelización de las operaciones. • Buenas Prácticas para Seleccionar PartitionKey: • Alta Cardinalidad: selecciona una clave de partición que tenga muchos valores distintos (alta cardinalidad) para asegurar una distribución uniforme de los datos. var entity = new DynamicTableEntity("userId123", "rowId1");

199 199 Table API (5/9) • Evitar Hot Partitions: Asegúrate
de que ningún valor de PartitionKey acumule una cantidad desproporcionada de datos (evita particiones calientes), lo que podría causar desequilibrio y afectar el rendimiento. • Ejemplo: Si utilizas una fecha o estado específico con pocos valores únicos como PartitionKey (state con valores limitados como 'CA', 'NY', etc.), podría resultar en particiones calientes. • Considerar Patrón de Acceso: Elige una PartitionKey que refleje el patrón de acceso de tu aplicación. Si esperas que las operaciones lean o escriban en grupos específicos, asegúrate de agrupar esos registros bajo la misma PartitionKey. • Ejemplo: Para una aplicación de redes sociales, podrías utilizar el identificador del usuario como PartitionKey, asegurándote de que todas las publicaciones de un usuario se almacenen juntas. RowKey • La RowKey identifica de manera única una entidad dentro de la partición determinada por PartitionKey. • Junto con PartitionKey, garantiza la unicidad y proporciona el orden de las entidades dentro de una partición. • Buenas Prácticas para Seleccionar RowKey: • Unicidad: Asegúrate de que la combinación de PartitionKey y RowKey sea única para cada entidad. La RowKey debe ser única dentro de cada partición. var entity = new DynamicTableEntity("partitionKey123", Guid.NewGuid().ToString());

200 200 Table API (6/9) • Ordenación y Búsqueda: •
Elige una RowKey que facilite las operaciones de ordenación y búsqueda dentro de una partición. • Si necesitas ordenar por fecha, considera incluir un timestamp invertido en la RowKey. • Ejemplo: Formato de timestamp invertido para RowKey: DateTime.MaxValue.Ticks - DateTime.UtcNow.Ticks. • Combinar Valores para Crear Compuesto: En algunos casos, puede ser útil combinar varios valores en la RowKey para permitir búsquedas multi-criterio. • Ejemplo: Combinar nombre y fecha en la RowKey para un historial de eventos. var entity = new DynamicTableEntity("partitionKey123", (DateTime.MaxValue.Ticks - DateTime.UtcNow.Ticks).ToString()); var entity = new DynamicTableEntity("partitionKey123", "EventName_" + DateTime.UtcNow.ToString("yyyyMMddHHmmss"));

201 201 Table API (7/9) Realizar una Operación de Join
en .NET con Table API En Azure Cosmos DB con la Table API (y en NoSQL en general, incluyendo Cassandra), las operaciones de join directas y complejas como las que existen en SQL no están soportadas nativamente. Sin embargo, puedes realizar operaciones de join en tus aplicaciones .NET uniendo los datos en el nivel de la aplicación después de recuperar las entidades correspondientes. using Microsoft.Azure.Cosmos.Table; using System; using System.Threading.Tasks; class Program { static async Task Main(string[] args) { string storageConnectionString = "DefaultEndpointsProtocol=https;AccountName=yourAccountName;AccountKey=yourAccountKey;TableEndpoint=https://yourAccountName.table.cosmos.azure.com:443/;"; CloudStorageAccount storageAccount = CloudStorageAccount.Parse(storageConnectionString); CloudTableClient tableClient = storageAccount.CreateCloudTableClient(new TableClientConfiguration()); CloudTable ordersTable = tableClient.GetTableReference("Orders"); CloudTable orderDetailsTable = tableClient.GetTableReference("OrderDetails"); // Crear las tablas si no existen await ordersTable.CreateIfNotExistsAsync(); await orderDetailsTable.CreateIfNotExistsAsync();

202 202 // Insertar datos en OrdersTable var order =
new DynamicTableEntity("customerId123", "orderId456") { Properties = { { "OrderDate", new EntityProperty(DateTime.UtcNow) }, { "OrderTotal", new EntityProperty(150.00) } } }; TableOperation insertOrder = TableOperation.Insert(order); await ordersTable.ExecuteAsync(insertOrder); // Insertar datos en OrderDetailsTable var orderDetail = new DynamicTableEntity("orderId456", "itemId1") { Properties = { { "ProductName", new EntityProperty("Product 1") }, { "Quantity", new EntityProperty(2) }, { "Price", new EntityProperty(50.00) } } }; TableOperation insertOrderDetail = TableOperation.Insert(orderDetail); await orderDetailsTable.ExecuteAsync(insertOrderDetail); // Realizar la operación de "join" en el nivel de aplicación string partitionKey = "customerId123"; TableQuery<DynamicTableEntity> orderQuery = new TableQuery<DynamicTableEntity>().Where( TableQuery.GenerateFilterCondition("PartitionKey", QueryComparisons.Equal, partitionKey)); Table API (8/9)

203 203 var orderSegment = await ordersTable.ExecuteQuerySegmentedAsync(orderQuery, null); var orders
= orderSegment.Results; foreach (var orderEntity in orders) { string orderPartitionKey = orderEntity.RowKey; TableQuery<DynamicTableEntity> orderDetailQuery = new TableQuery<DynamicTableEntity>().Where( TableQuery.GenerateFilterCondition("PartitionKey", QueryComparisons.Equal, orderPartitionKey)); var orderDetailSegment = await orderDetailsTable.ExecuteQuerySegmentedAsync(orderDetailQuery, null); var orderDetails = orderDetailSegment.Results; Console.WriteLine($"Order ID: {orderEntity.RowKey}, Total: {orderEntity.Properties["OrderTotal"].DoubleValue}"); foreach (var detailEntity in orderDetails) { Console.WriteLine($" Product: {detailEntity.Properties["ProductName"].StringValue}, Quantity: {detailEntity.Properties["Quantity"].Int32Value}, Price: {detailEntity.Properties["Price"].DoubleValue}"); } } } } Table API (9/9) Operaciones Batch Minimiza la cantidad de solicitudes haciendo uso de operaciones batch donde sea posible para mejorar la eficiencia.

204 204 IA y Azure CosmosDB (1/8) Integraciones con Inteligencia
Artificial Azure Cognitive Search Servicio de búsqueda en la nube que proporciona capacidades potentes de búsqueda y análisis de texto. Combinar Azure Cognitive Search con Cosmos DB permite enriquecer los datos y facilitar búsquedas avanzadas y análisis de texto. Usos Comunes: • Búsqueda Full-Text: Permite realizar búsquedas de texto completo en los datos almacenados en Cosmos DB. • Indexación: Indexa datos de Cosmos DB automáticamente y permite consultas de búsqueda ricas con facetas y filtros. • Enriquecimiento de Datos: Utiliza el enriquecimiento cognitivo para extraer información adicional de los datos durante el proceso de indexación.

205 205 IA y Azure CosmosDB (2/8) Pasos para Integrar
Azure Cognitive Search con Cosmos DB: • Crear un Servidor de Azure Cognitive Search: • Navega al portal de Azure. • Crea un recurso de Azure Cognitive Search. • Configurar la Fuente de Datos (Data Source): • Configura una fuente de datos que apunte a tu base de datos en Cosmos DB. • Selecciona el tipo de data source como "Azure Cosmos DB". • Crear un Índice de Búsqueda: • Define el esquema del índice que refleja la estructura de tus datos en Cosmos DB. • Configurar un Indexador (Indexer): • Crea un indexador para Azure Cognitive Search que sincronice automáticamente los datos de Cosmos DB con el índice de búsqueda.

206 206 IA y Azure CosmosDB (3/8) Ejemplo: using Microsoft.Azure.Search;
using Microsoft.Azure.Search.Models; public async Task ConfigureSearchServiceAsync() { string searchServiceName = "your-search-service"; string queryApiKey = "your-search-service-query-key"; string adminApiKey = "your-search-service-admin-key"; string cosmosDbConnectionString = "your-cosmos-db-connection-string"; string cosmosDbDatabaseName = "your-database-name"; string cosmosDbCollectionName = "your-collection-name"; SearchServiceClient searchServiceClient = new SearchServiceClient(searchServiceName, new SearchCredentials(adminApiKey)); // Crear Data Source DataSource dataSource = DataSource.AzureCosmosDb( name: "cosmosdb-datasource", connectionString: cosmosDbConnectionString, collection: cosmosDbCollectionName, database: cosmosDbDatabaseName ); await searchServiceClient.DataSources.CreateOrUpdateAsync(dataSource);

207 207 // Crear Índice Index index = new Index()
{ Name = "my-index", Fields = FieldBuilder.BuildForType<MyDocument>() }; await searchServiceClient.Indexes.CreateOrUpdateAsync(index); // Crear Indexador Indexer indexer = new Indexer(name: "my-indexer", dataSourceName: dataSource.Name, targetIndexName: index.Name); await searchServiceClient.Indexers.CreateOrUpdateAsync(indexer); // Ejecutar Indexador await searchServiceClient.Indexers.RunAsync(indexer.Name); } public class MyDocument { [System.ComponentModel.DataAnnotations.Key] [IsFilterable] public string Id { get; set; } [IsSearchable] [Analyzer(AnalyzerName.AsString)] public string Content { get; set; } } IA y Azure CosmosDB (4/8)

208 208 IA y Azure CosmosDB (5/8) Retrieval-Augmented Generation (RAG)
Técnica avanzada que combina la recuperación de información con la generación de respuestas a través de modelos de lenguaje natural, como GPT-3 o GPT-4. Esto permite generar respuestas informadas y relevantes basadas en datos estructurados y no estructurados almacenados en Cosmos DB. Usos Comunes: • Chatbots Inteligentes: Genera respuestas enriquecidas basadas en documentos y datos almacenados en Cosmos DB. • Asistencia al Cliente: Integra el poder de recuperación de información con generación automática de respuestas para proporcionar una experiencia más interactiva y precisa. • Sistemas de Recomendación: Combina información recuperada para generar recomendaciones personalizadas.

209 209 IA y Azure CosmosDB (6/8) Pasos para Integrar
Azure Cognitive Search con Cosmos DB: • Almacenar Datos en Cosmos DB: • Almacena documentos o datos estructurados que contengan información útil para la generación de respuestas. • Configurar un Modelo de Lenguaje para Generación: • Utiliza servicios como OpenAI o Azure OpenAI para acceder a modelos avanzados de generación de lenguaje. • Implementar Recuperación de Información: • Utiliza Azure Cognitive Search o consultas directas a Cosmos DB para recuperar información relevante basada en una entrada del usuario. • Integrar con Generación de Respuestas: • Pasa la información recuperada al modelo de lenguaje para generar una respuesta coherente y contextual.

210 210 IA y Azure CosmosDB (7/8) Ejemplo: using Microsoft.Azure.Cosmos;
using Azure.Search.Documents; using Azure.Search.Documents.Models; using OpenAI_API; using System; using System.Collections.Generic; using System.Threading.Tasks; public class RagExample { private static readonly string EndpointUri = "https://your-cosmos-db-endpoint.documents.azure.com:443/"; private static readonly string PrimaryKey = "your-cosmos-db-key"; private static CosmosClient cosmosClient; private static Database database; private static Container container; public static async Task Main(string[] args) { cosmosClient = new CosmosClient(EndpointUri, PrimaryKey); database = cosmosClient.GetDatabase("your-database-name"); container = database.GetContainer("your-container-name"); // Recuperar información relevante de Cosmos DB QueryDefinition queryDefinition = new QueryDefinition("SELECT TOP 5 * FROM c WHERE CONTAINS(c.content, @keyword)") .WithParameter("@keyword", "your-search-keyword"); FeedIterator<YourDocumentModel> queryResultSetIterator = container.GetItemQueryIterator<YourDocumentModel>(queryDefinition);

211 211 List<YourDocumentModel> documents = new List<YourDocumentModel>(); while (queryResultSetIterator.HasMoreResults) {
FeedResponse<YourDocumentModel> currentResultSet = await queryResultSetIterator.ReadNextAsync(); foreach (YourDocumentModel document in currentResultSet) { documents.Add(document); } } // Integrar con OpenAI para generar respuesta string prompt = $"Based on the following documents: {string.Join(" ", documents.Select(d => d.Content))}, provide a summary or answer to this question: 'your-question'"; OpenAIAPI api = new OpenAIAPI("your-openai-api-key"); CompletionRequest completionRequest = new CompletionRequest { Prompt = prompt, MaxTokens = 150 }; var response = await api.Completions.CreateCompletionAsync(completionRequest); Console.WriteLine(response.Completions[0].Text); } public class YourDocumentModel { public string id { get; set; } public string Content { get; set; } } } IA y Azure CosmosDB (8/8)

212 212 Otras Integraciones (1/5) Listado de Integraciones • Azure
Functions: Procesamiento de cambios, HTTP triggers, y tareas programadas. • Azure Logic Apps: Automatización e integración con múltiples servicios. • Azure Data Factory (ADF): ETL y flujos de trabajo de datos. • Azure Cognitive Search: Búsqueda avanzada e indexación enriquecida. • Event Grid: Arquitectura event-driven y flujos de trabajo. • Azure Stream Analytics: Análisis de datos en tiempo real. • Power BI: Visualización de datos y análisis interactivo. • Azure Synapse Analytics: Análisis de big data. • Azure Kubernetes Service (AKS): Aplicaciones containerizadas escalables. • Azure Security Center: Monitoreo y aseguramiento de datos. • Azure Monitor: Supervisión y alertas. • Azure Data Lake Storage (ADLS): Almacenamiento y análisis de big data. • Azure Event Hubs: Ingestión de eventos a alta velocidad. • Salesforce: Sincronización de datos de CRM. • APIs Personalizadas (SDKs): Desarrollo de aplicaciones personalizadas con soporte para múltiples lenguajes.

213 213 Otras Integraciones (2/5) Integraciones de Azure Cosmos DB
con Azure Functions Servicio de computación sin servidor que permite ejecutar código en respuesta a eventos y escalarlos automáticamente. Integrar Cosmos DB con Azure Functions permite desencadenar funciones cuando hay cambios en los datos, lo que es útil para procesamiento en tiempo real, notificaciones y más. Azure Cosmos DB ofrece una característica llamada Change Feed que proporciona un flujo ordenado de operaciones de inserción y actualización en las bases de datos de Cosmos DB. Puede desencadenar una función de Azure Functions para procesar estos cambios en tiempo real.

214 214 using System.Collections.Generic; using Microsoft.Azure.Documents; using Microsoft.Azure.WebJobs; using Microsoft.Extensions.Logging;
public static class CosmosDbChangeFeedFunction { [FunctionName("CosmosDbChangeFeedFunction")] public static void Run( [CosmosDBTrigger( databaseName: "your-database-name", collectionName: "your-collection-name", ConnectionStringSetting = "CosmosDBConnection", LeaseCollectionName = "leases", CreateLeaseCollectionIfNotExists = true)] IReadOnlyList<Document> input, ILogger log) { if (input != null && input.Count > 0) { foreach (var document in input) { log.LogInformation($"Document modified ID: {document.Id}"); // Procesamiento adicional según lo necesario } } } } Otras Integraciones (3/5)

215 215 Otras Integraciones (4/5) Azure Data Factory para ETL
y Movimiento de Datos Azure Data Factory (ADF) es un servicio ETL (Extract, Transform, Load) que facilita el movimiento y transformación de datos desde diversas fuentes hacia destinos como Cosmos DB. { "name": "CopyFromSQLToCosmosDB", "properties": { "activities": [ { "name": "CopyFromSQLToCosmosDB", "type": "Copy", "inputs": [ { "name": "SQLSource" } ], "outputs": [ { "name": "CosmosDBSink" } ], "typeProperties": { "source": { "type": "SqlSource", "sqlReaderQuery": "SELECT * FROM SourceTable" }, "sink": { "type": "CosmosDbSqlApiSink", "writeBehavior": "upsert" } } } ] } }

216 216 Otras Integraciones (5/5) Azure Event Grid para Integración
de Eventos Facilita la creación de arquitecturas event-driven, distribuyendo eventos de fuentes a suscriptores. using System.Collections.Generic; using Microsoft.Azure.WebJobs; using Microsoft.Azure.WebJobs.Extensions.EventGrid; using Microsoft.Extensions.Logging; using Newtonsoft.Json.Linq; public static class EventGridFunction { [FunctionName("EventGridFunction")] public static void Run( [EventGridTrigger] EventGridEvent eventGridEvent, ILogger log) { log.LogInformation(eventGridEvent.Data.ToString()); var data = ((JObject)eventGridEvent.Data).ToObject<CustomEventData>(); log.LogInformation($"Document ID: {data.DocumentId}, Timestamp: {data.Timestamp}"); } } public class CustomEventData { public string DocumentId { get; set; } public string Timestamp { get; set; } }

217 217 Anexos (1/5) Azure Cosmos DB y Cumplimiento con
Normativas de Seguridad Azure Cosmos DB cumple con varias normativas y certificaciones de seguridad que garantizan la protección de los datos almacenados en la plataforma. Microsoft ha diseñado Cosmos DB con un enfoque en la seguridad, privacidad y cumplimiento de regulaciones globales y específicas de la industria. Cumplimiento con el GDPR (Reglamento General de Protección de Datos - Europa) GDPR (General Data Protection Regulation) establece reglas estrictas sobre cómo se deben manejar los datos personales dentro de la Unión Europea. Azure Cosmos DB cumple con el GDPR al proporcionar: • Cifrado de datos en tránsito y en reposo para proteger la privacidad. • Control de acceso basado en roles (RBAC) para restringir el acceso a datos sensibles. • Herramientas de auditoría y monitoreo a través de Azure Monitor y Azure Security Center. • Opciones de residencia de datos para garantizar que los datos europeos permanezcan en regiones específicas si es necesario.

218 218 Anexos (2/5) Certificación ISO (Estándares Internacionales de Seguridad
de la Información) Azure Cosmos DB cuenta con múltiples certificaciones ISO (International Organization for Standardization), lo que demuestra que cumple con buenas prácticas de seguridad. Entre ellas: • ISO 27001: Estándar de seguridad de la información. • ISO 27017: Controles de seguridad específicos para servicios en la nube. • ISO 27018: Protección de información personal en la nube. • ISO 22301: Continuidad del negocio y recuperación ante desastres. Cumplimiento con SOC (System and Organization Controls) Azure Cosmos DB cumple con los estándares SOC (Service Organization Control), que son auditorías de seguridad y privacidad aplicadas a proveedores de servicios en la nube: • SOC 1: Garantiza la integridad financiera de los datos almacenados en Cosmos DB. • SOC 2: Se centra en la seguridad, disponibilidad, procesamiento y confidencialidad. • SOC 3: Un informe público que certifica que Microsoft sigue buenas prácticas de seguridad en la nube.

219 219 Anexos (3/5) Otras Certificaciones y Cumplimientos Además de
los mencionados, Azure Cosmos DB también cumple con otras de especial interés: • HIPAA (Health Insurance Portability and Accountability Act - EE.UU.): Para el sector de la salud, Cosmos DB cumple con la HIPAA, que exige fuertes controles sobre la privacidad y seguridad de los datos médicos y personales. • FedRAMP (EE.UU.): Cumplimiento con estándares de seguridad en la nube para agencias gubernamentales. • PCI DSS: Seguridad para datos de tarjetas de pago. • C5 (Alemania): Certificación de seguridad para proveedores de servicios en la nube en Alemania.

220 220 Anexos (4/5) Principios Clave del Modelado en Cosmos
DB Modelado Basado en Consultas • En Cosmos DB, el esquema debe diseñarse según las consultas más frecuentes, en lugar de la normalización estricta usada en bases de datos relacionales. • Objetivo: Minimizar la cantidad de consultas y optimizar el uso de Request Units (RUs). Uso de Particiones de Forma Eficiente • Cosmos DB distribuye datos en particiones lógicas, por lo que elegir una buena clave de partición es fundamental para evitar hotspots y mejorar la escalabilidad. • Claves de partición recomendadas: Deben ser de alta cardinalidad (muchos valores únicos) y uniformemente distribuidas. • Consejo: Evita claves con pocos valores únicos (ejemplo: "tipoProducto": "Electrónica") ya que podrían generar sobrecarga en una sola partición. Desnormalización vs. Normalización en NoSQL • Cosmos DB prefiere desnormalización (guardar datos relacionados en un solo documento). • Sin embargo, la normalización puede ser útil cuando los datos cambian con frecuencia.

221 221 Anexos (5/5) Manejo de Datos Jerárquicos y Relacionados
• Cosmos DB admite estructuras anidadas y arrays, lo que permite representar relaciones sin necesidad de JOINs. • Consejo: Para consultas eficientes, usa índices compuestos en los atributos más consultados. Optimización de Consultas y Costos • Indexado: Cosmos DB indexa automáticamente todos los campos, pero se pueden personalizar índices para optimizar rendimiento. • Ru/s (Request Units): Evita consultas que hagan escaneos innecesarios. • Consejo: Filtra por clave de partición siempre que sea posible para mejorar la eficiencia.

Azure Cosmos DB para tus aplicaciones con NoSQL

Azure Cosmos DB para tus aplicaciones con NoSQL

More Decks by Jose María Flores Zazo

Other Decks in Programming

Featured

Transcript