Soluciones relacionales y datos NoSQL

Sugerencia

Este contenido es un extracto del libro electrónico “Architecting Cloud Native .NET Applications for Azure” (Diseño de la arquitectura de aplicaciones .NET nativas en la nube para Azure), disponible en Documentos de .NET o como un PDF descargable y gratuito que se puede leer sin conexión.

Descargar PDF

Los datos relacionales y NoSQL son dos tipos de sistemas de base de datos que se implementan con frecuencia en las aplicaciones nativas de nube. Se diferencian en cómo se crean, la forma en la que almacenan datos y en cómo se accede a ellas. En esta sección, se abordarán los dos tipos. Más adelante en este capítulo, nos centraremos en una tecnología de base de datos emergente denominada NewSQL.

Las bases de datos relacionales son una tecnología predominante desde hace décadas. Demuestran madurez, se han probado y son ampliamente implementadas. Los productos de base de datos, las herramientas y la experiencia de la competencia son abundantes. Las bases de datos relacionales proporcionan un almacén de tablas de datos relacionadas. Estas tablas presentan un esquema fijo, usan SQL (Lenguaje de consulta estructurado) para administrar datos y admiten garantías ACID.

Las bases de datos NoSQL se refieren a los almacenes de datos no relacionales y de alto rendimiento. Destacan por su facilidad de uso, escalabilidad, resistencia y disponibilidad. En lugar de combinar tablas de datos normalizados, NoSQL almacena datos no estructurados o semiestructurados, a menudo en pares clave-valor o documentos JSON. Los base de datos no SQL no suelen ofrecen garantías ACID aparte del ámbito de una única partición de base de datos. Los servicios de gran volumen que requieren tiempos de respuesta por debajo de un segundo dan prioridad a los almacenes de datos NoSQL.

Es necesario insistir en la importancia del efecto de las tecnologías NoSQL en sistemas nativos de nube distribuidos. La proliferación de nuevas tecnologías de datos en este espacio ha alterado las soluciones que antes confiaban exclusivamente en bases de datos relacionales.

Las bases de datos NoSQL incluyen varios modelos diferentes para acceder a los datos y administrarlos, cada uno adecuado para casos de uso concretos. En la figura 5-9 se presentan cuatro modelos frecuentes.

Figura 5-9: modelos de datos para bases de datos NoSQL

Modelo	Características
Almacén de documentos	Los datos y los metadatos se almacenan jerárquicamente en documentos basados en JSON dentro de la base de datos.
Almacén de clave-valor	La más sencilla de las bases de datos NoSQL, los datos se representan como una colección de pares clave-valor.
Almacén de columna ancha	Los datos relacionados se almacenan como un conjunto de pares clave-valor anidados dentro de una sola columna.
Almacén de grafos	Los datos se almacenan en una estructura de grafo como propiedades de nodo, borde y datos.

Teorema CAP

Para entender las diferencias entre estos tipos de bases de datos, piense en el teorema CAP, una serie de principios aplicados a los sistemas distribuidos que almacenan el estado. En la figura 5-10 se muestran las tres propiedades del teorema CAP.

Figura 5-10. Teorema CAP

El teorema indica que los sistemas de datos distribuidos ofrecerán un equilibrio entre la coherencia, la disponibilidad y la tolerancia a particiones. Además, cualquier almacén de datos solo puede garantizar dos de las tres propiedades:

• Coherencia Cada nodo del clúster responde con los datos más recientes, incluso si el sistema debe bloquear la solicitud hasta que se actualicen todas las réplicas. Si consulta un «sistema coherente» para un artículo que se está actualizando en ese momento, tendrá que esperar hasta que todas las réplicas se actualicen correctamente. Sin embargo, recibirá los datos más actualizados.

• La disponibilidad. Cada nodo devuelve una respuesta inmediata, incluso si esa respuesta no son los datos más recientes. Si consulta un «sistema disponible» para un artículo que se está actualizando, obtendrá la mejor respuesta posible que el servicio puede ofrecer en ese momento.

• Tolerancia a la partición. Garantiza que el sistema sigue funcionando incluso si se produce un error en un nodo de datos replicados o se pierde la conectividad con otros nodos de datos replicados.

El teorema CAP explica la solución de compromiso que se adopta en la administración de la coherencia y disponibilidad durante una partición de red. Sin embargo, las soluciones de compromiso relacionadas con la coherencia y el rendimiento existen también sin una partición de red. El teorema CAP se suele ampliar a PACELC para explicar las soluciones de compromiso globalmente.

Las bases de datos relacionales suelen proporcionar coherencia y disponibilidad, pero no tolerancia a particiones. Normalmente se aprovisionan en un único servidor y se escalan verticalmente al agregar más recursos a la máquina.

Muchas bases de datos relacionales admiten características de replica integradas en las que se pueden hacer copias de la bases de datos principales en otras instancias de servidor secundarias. Las operaciones de escritura se hacen en la instancia principal y se replican en cada una de las secundarias. Tras un error, la instancia principal puede conmutar por error en una secundaria para proporcionar alta disponibilidad. Las instancias secundarias también se pueden usar operaciones de lectura distribuidas. Aunque las operaciones de escritura siempre van en contra de la réplica principal, las operaciones de lectura se pueden enrutar a cualquiera de las secundarias para reducir la carga del sistema.

Los datos se pueden particionar horizontalmente en varios nodos, como con particionamiento. Sin embargo, el particionamiento aumenta drásticamente la sobrecarga operativa al dividir los datos en muchas partes que no se pueden comunicar fácilmente. Administrarlo puede ser costoso y lento. Las características relacionales que incluyen combinaciones de tablas, transacciones e integridad referencial necesitan penalizaciones de rendimiento en las implementaciones particionadas.

Es posible optimizar la coherencia de la réplica y los objetivos de punto de recuperación al configurar si la réplica se produce sincrónica o asincrónicamente. Si las réplicas de datos perdieran conectividad de red en un clúster de bases de datos relacionales «altamente coherentes» o sincrónicas, no podría escribir en la base de datos. El sistema rechazaría la operación de escritura porque no podría replicar ese cambio en la otra réplica de datos. Cada réplica de datos tiene que actualizarse antes de que pueda completar la transacción.

Las bases de datos NoSQL suelen admitir alta disponibilidad y tolerancia a la partición. Se escalan horizontalmente, a menudo en servidores de productos básicos. Con este enfoque se proporciona una gran disponibilidad, tanto entre como en las regiones geográficas a un coste reducido. Puede crear particiones y replicar datos en estas máquinas o nodos, lo que proporciona redundancia y tolerancia a errores. La coherencia se suele ajustar por medio de protocolos de consenso o mecanismos de quorum. Se obtiene un mayor control para explorar soluciones de compromiso en las que se tiene que elegir entre una réplica sincrónica y una asincrónica en sistemas relacionales.

Si las réplicas de datos perdieran conectividad en un clúster de base de datos NoSQL de «alta disponibilidad», se podría completar una operación de escritura en la base de datos. El clúster de base de datos permitiría la operación de escritura y actualizaría cada réplica de datos a medida que estén disponibles. Las bases de datos NoSQL que admiten varias réplicas grabables puede reforzar todavía más la alta disponibilidad evitando que sea necesaria una conmutación por error al optimizar el objetivo del tiempo de recuperación.

Las bases de datos NoSQL modernas suelen implementar funcionalidades de creación de particiones como una característica del diseño del sistema. La administración de particiones suele estar integrada en la base de datos y el enrutamiento se obtiene por medio de sugerencias de selección de ubicación, que se suelen llamar claves de partición. Mediante un modelo de datos flexible, las bases de datos NoSQL reducen la carga de administración de esquemas y mejoran la disponibilidad al implementar actualizaciones de aplicación que requieren modificaciones en el modelo de datos.

A menudo la alta disponibilidad y la escalabilidad masiva son más importantes para la empresa que las combinaciones de tablas relacionales y la integridad referencial. Los desarrolladores pueden implementar técnicas y patrones como Sagas, CQRS y mensajería asincrónica para adoptar la coherencia final.

Hoy en día, conviene prestar atención al considerar las restricciones del teorema CAP. Un nuevo tipo de bases de datos, denominada NewSQL, ha surgido y amplía el motor de base de datos relacional para admitir la escalabilidad horizontal y el rendimiento escalable de los sistemas NoSQL.

Cuestiones sobre las diferencias entre los sistemas relacionales y NoSQL

En función de los requisitos de datos específicos, un microservicio nativo puede implementar un almacén de datos relacional, una base de datos NoSQL o ambos.

Plantéese un almacén de datos NoSQL cuando:	Plantéese una base de datos relacional cuando:
Tiene cargas de trabajo de gran volumen que requieren una latencia predecible a gran escala (por ejemplo, la latencia medida en milisegundos mientras hace millones de transacciones por segundo)	El volumen de carga de trabajo por lo general se ajusta a miles de transacciones por segundo
Los datos son dinámicos y cambian frecuentemente	Los datos están altamente estructurados y necesitan integridad referencial
Las relaciones pueden ser modelos de datos desnormalizados	Las relaciones se expresan por medio de combinaciones de tablas en modelos de datos normalizados
La recuperación de datos es sencilla y se expresa sin combinaciones de tabla	Maneja consultas e informes complejos
Los datos se suelen replicar entre zonas geográficas y se requiere un control más preciso sobre la coherencia, la disponibilidad y el rendimiento	Normalmente, los datos están centralizados o pueden replicarse regiones de forma asincrónica
La aplicación se implementará en hardware de productos básicos, como con nubes públicas	La aplicación se implementará en un hardware grande y de gama alta

En las secciones siguientes, se explorarán las opciones disponibles en la nube de Azure para almacenar y administrar los datos nativos de nube.

Base de datos como servicio

Para empezar, puede aprovisionar una máquina virtual de Azure e instalar las bases de datos que prefiere para cada servicio. Aunque tiene control absoluto sobre el entorno, renunciaría a muchas características integradas de la plataforma en la nube. También sería responsable de administrar la máquina virtual y la base de datos de cada servicio. Este enfoque podría convertirse rápidamente en una solución cara y lenta.

En su lugar, las aplicaciones nativas de nube priorizan servicios de datos expuestos como una base de datos como servicio (DBaaS). Totalmente administrado por un proveedor en la nube, estos servicios ofrecen seguridad, escalabilidad y supervisión integradas. En lugar de ser propietario del servicio, simplemente se consume como un servicio de respaldo. El proveedor opera el recurso a escala y asume la responsabilidad del rendimiento y del mantenimiento.

Pueden configurarse en las zonas de disponibilidad en la nube y las regiones para obtener una alta disponibilidad. Todos admiten la capacidad Just-In-Time y el modelo de pago por uso. Azure ofrece diferentes tipos de opciones de servicios de datos administrados, cada una con ventajas específicas.

En primer lugar, trataremos los servicios de base de datos como servicios relacionales disponibles en Azure. Verá que la base de datos de SQL Server, buque insignia de Microsoft, está disponible con varias opciones de código abierto. A continuación, abordaremos los servicios de datos NoSQL en Azure.

Bases de datos relacionales de Azure

Para los microservicios nativos de nube que requieren datos relacionales, Azure proporciona cuatro ofertas bases de datos relacionales administradas como servicio, como se muestra en la figura 5-11.

Figura 5-11. Bases de datos relacionales administradas disponibles con Azure

En la figura anterior se puede ver cómo cada una se encuentra en una infraestructura de base de datos como servicios común con funcionalidades clave sin coste adicional.

Estas funcionalidades son especialmente importantes para organizaciones que aprovisionan grandes cantidades de bases de datos, pero no tienen muchos servicios para administrarlas. Puede aprovisionar una base de datos de Azure en minutos al seleccionar la cantidad de núcleos de procesamiento, memoria y almacenamiento subyacente. Puede escalar la base de datos sobre la marcha y ajusta dinámicamente los recursos con poco o sin tiempo de inactividad.

Azure SQL Database

Los equipos de desarrollo que tienen experiencia en Microsoft SQL Server debería considerar Azure SQL Database. Es una base de datos como servicios relacional totalmente administrada que se basa en el Motor de base de datos de Microsoft SQL Server. El servicio comparte muchas características con la versión local de SQL Server y ejecuta la última versión estable del motor de base de datos de SQL Server.

Para usarlo con un microservicio nativo de nube, Azure SQL Database está disponible con tres opciones de implementación:

• Una Base de datos única representa una SQL Database totalmente administrada que se ejecuta en un servidor de Azure SQL Database en la nube de Azure. La base de datos se considera independiente, dado que no tiene dependencias de configuración en el servidor de bases de datos subyacente.

• Una instancia administrada es una instancia totalmente administrada del motor de base de datos de Microsoft SQL Server, que proporciona casi el 100 % de compatibilidad con un SQL Server local. Esta opción admite bases de datos más amplias, de hasta 35 TB, y se coloca en una Virtual Network de Azure para obtener mejor aislamiento.

• Azure SQL Database sin servidor es un nivel de proceso para una base de datos única que escala automáticamente en función de la demanda de la carga de trabajo. Solo se factura la cantidad de proceso utilizado por segundo. El servicio es adecuado para cargas de trabajo con patrones de uso intermitentes e impredecibles, intercalados con períodos de inactividad. Además, el nivel de proceso sin servidor pausa automáticamente las bases de datos durante períodos de inactividad para que se factura solo el almacenamiento. Se reactiva automáticamente al reanudarse la actividad.

Además de la pila tradicional de Microsoft SQL Server, Azure también dispone de versiones administradas de tres bases de datos de código abierto.

Bases de datos de código abierto de Azure

Las bases de datos relacionales de código abierto han alcanzado una gran popularidad para las aplicaciones nativas de nube. Cuentan con la prioridad que les dan muchas empresas frente a productos de bases de datos comerciales, en especial por razones económicas. A muchos equipos de desarrollo les interesa su flexibilidad, el desarrollo respaldado por la comunidad y su ecosistema de herramientas y extensiones. Las bases de datos de código abierto pueden implementarse en varios proveedores de nube, con lo que se minimiza el problema del «bloqueo del vendedor».

Los desarrolladores pueden hospedar de forma sencilla cualquier base de datos de código abierto en una máquina virtual de Azure. Al proporcionarle control absoluto, con este enfoque usted es el encargado de la administración, supervisión y mantenimiento de la base de datos y máquina virtual.

Sin embargo, Microsoft mantiene su compromiso de mantener Azure como una «plataforma abierta» al ofrecerle varias bases de datos de código abierto populares como servicios DBaaS totalmente administrados.

Azure Database for MySQL

MySQL es una base de datos relacional de código abierto y constituye la base de las aplicaciones integradas en la pila de software LAMP. Especialmente popular por las cargas de trabajo de lectura intensiva, la usan muchas compañías grandes, entre las que se incluyen Facebook, Twitter y YouTube. La community edition está disponible de forma gratuita, mientras que para la enterprise edition es necesario comprar una licencia. Creado en 1995, Sun Microsystems compró el producto en 2008. Oracle adquirió Sun y MySQL en 2010.

Azure Database for MySQL es un servicio de base de datos relacional administrado que se basa en el motor de código abierto MySQL. Usa la edición MySQL Community. El servidor de Azure MySQL es el punto administrativo del servicio. Es el mismo motor de servidor de MySQL que se usa en las implementaciones locales. El motor puede crear una base de datos única por servidor o varias bases de datos por servidor que comparten recursos. Puede seguir administrando los datos con las mismas herramientas de código abierto sin tener que adquirir aptitudes nuevas o administrar máquinas virtuales.

Azure Database for MariaDB

El servidor MariaDB Server es otro servidor de bases de datos de código abierto ampliamente usado. Se creó como bifurcación de MySQL cuando Oracle adquirió Sun Microsystems, propietario de MySQL. Se pretendía garantizar que MariaDB siguiera siendo de código abierto. Dado que MariaDB es una bifurcación de MySQL, las definiciones de los datos y las tablas son compatibles. Por su parte, los protocolos de cliente, las estructuras y las API están estrechamente unidas.

MariaDB cuenta con una comunidad sólida y la usan muchas grandes empresas. Mientras Oracle sigue manteniendo, mejorando y admitiendo MySQL, la fundación MariaDB administra MariaDB, lo que permite contribuciones públicas al producto y documentación.

Azure Database for MariaDB es una base de datos relacional totalmente administrada como servicio en la nube de Azure. Este servicio se basa en el motor de servidor de MariaDB Community Edition. Puede controlar cargas de trabajo críticas con un rendimiento predecible y escalabilidad dinámica.

Azure Database for PostgreSQL

PostgreSQL es una base de datos relacional de código abierto con más de treinta años de desarrollo activo. PostgreSQL debe su gran reputación a su confiabilidad e integridad de datos. Tiene muchas funcionalidades, es compatible con SQL y se considera más eficaz que MySQL, especialmente para cargas de trabajo con consultas complejas y escrituras intensivas. Muchas grandes empresas, entre las que se incluyen Apple, Red Hat y Fujitsu, han creado productos con PostgreSQL.

Azure Database for PostgreSQL es un servicio de base de datos relacional totalmente administrado basado en el motor de base de datos de código abierto Postgres. El servicio admite muchas plataformas de desarrollo, como C++, Java, Python, Node, C# y PHP. Se pueden migrar las bases de datos de PostgreSQL a este servicio, con la herramienta de interfaz de la línea de comandos o Azure Data Migration Service.

Azure Database for PostgreSQL está disponible con dos opciones de implementación:

• La opción de implementar un único servidor en un punto administrativo central para varias bases de datos en las que se pueden implementar muchas bases de datos. Los precios se calculan por servidor en función de los núcleos y el almacenamiento.

• La opción Hiperescala (Citus) funciona con la tecnología Citus Data. Permite alto rendimiento al escalar horizontalmente una base de datos única en cientos de nodos para ofrecer un rendimiento y una escala rápidos. De este modo, el motor puede ajustarse a más datos en la memoria, paralelizar consultas en cientos de nodos e indexar los datos con mayor rapidez.

Datos NoSQL en Azure

Cosmos DB es un servicio de base de datos NoSQL distribuida globalmente y totalmente administrada en la nube de Azure. Muchas grandes empresas en todo el mundo la han adoptado, entre las que se incluyen Coca-Cola, Skype, ExxonMobil y Liberty Mutual.

Si los servicios requieren una respuesta rápida desde cualquier punto del globo, alta disponibilidad o escalabilidad elástica, Cosmos DB es una excelente opción. En la figura 5-12 se muestra Cosmos DB.

Figura 5-12: Introducción a Azure Cosmos DB

En la figura anterior se presentan muchas funcionalidades integradas nativas de nube disponibles en Cosmos DB. En este apartado las veremos con más detalle.

Compatibilidad global

Las aplicaciones nativas de nube suelen tener una audiencia global y requieren una escala global.

Puede distribuir bases de datos de Cosmos en regiones o en todo el mundo, acercando los datos a sus usuarios, mejorando el tiempo de respuesta y reduciendo la latencia. Puede agregar o eliminar una base de datos de una región sin pausar o volver a implementar los servicios. En segundo plano, Cosmos DB replica de forma transparente los datos a cada una de las regiones configuradas.

Cosmos DB admite la agrupación en clústeres activo/activo a un nivel global, lo que le permite configurar una de las regiones de la base de datos para admitir escrituras y lecturas.

El protocolo de escribir en varias regiones es una característica importante de Cosmos DB que habilita las características siguientes:

• Escalabilidad de escritura y lectura elásticas ilimitada.

• 99,999 % de disponibilidad de lectura y escritura en todo el mundo.

• Garantía de lecturas y escrituras atendidas en menos de 10 milisegundos en el percentil 99.

Con las API de hospedaje múltiple de Cosmos DB, el microservicio conoce automáticamente la región de Azure más próxima y le envía solicitudes. Cosmos DB identifica la región más cercana sin hacer cambios de configuración. Si una región deja de estar disponible, la característica de hospedaje múltiple solicitará automáticamente la ruta a la siguiente región disponible más cercana.

Compatibilidad con varios modelos

Al transportar aplicaciones monolíticas a una arquitectura nativa de nube, los equipos de desarrollo a veces tienen que migrar almacenes de datos NoSQL de código abierto. Mediante Cosmos DB, no se pierde la inversión en estos almacenes de datos NoSQL con su plataforma de datos de varios modelos. En la tabla siguiente se muestran las API de compatibilidad NoSQL admitidas.

Proveedor	Descripción
NoSQL API	La API para NoSQL almacena datos en formato de documento
API de Mongo DB	Admite las API de Mongo DB y los documentos JSON
API de Gremlin	Admite la API de Gremlin con nodos basados en gráficos y representaciones de datos perimetrales
Cassandra API	Admite la API de Casandra para representar datos de columnas anchas
Table API	Admite Azure Table Storage con mejoras premium
API PostgreSQL	Servicio administrado para ejecutar PostgreSQL a cualquier escala

Los equipos de desarrollo puede migrar bases de datos existentes de Mongo, Gremlin o Cassandra en Cosmos DB con mínimas modificaciones en los datos o el código. En el caso de las nuevas aplicaciones, los equipos de desarrollo pueden decidirse por una de las opciones de código abierto o el modelo de API de SQL integrado.

De forma interna, Cosmos almacena los datos en un formato de estructura simple formado por tipos de datos primitivos. En cada solicitud, el motor de base de datos traduce los datos primitivos en la representación del modelo que ha seleccionado.

En la tabla anterior, anote la opción Table API. Esta API es una evolución de Table Storage de Azure. Las dos comparten el mismo modelo de tabla subyacente, pero la Table API de Cosmos DB agrega mejoras premium que no incluye la API de Azure Storage. En la tabla siguiente se comparan las características.

Característica	Azure Table Storage	Azure Cosmos DB
Latencia	Rápido	La latencia de milisegundos de un solo dígito para lecturas y escrituras en cualquier parte del mundo
Throughput	Límite de 20 000 operaciones por tabla	Operaciones ilimitadas por tabla
Distribución global	Región única con una única región de lectura secundaria	Distribuciones de llave en mano a todas las regiones con conmutación por error automática
Indización	Solo está disponible para las propiedades de partición y clave de fila	Indexación automática de todas las propiedades
Precios	Optimizados por cargas de trabajo inactivas (bajo rendimiento: proporción de almacenamiento)	Optimizados para cargas de trabajo activas (alto rendimiento: proporción de almacenamiento)

Los microservicios que consumen almacenamiento de las tablas de Azure pueden migrar a Table API de Cosmos DB sin problemas. No se requiere ningún cambio de código.

Coherencia optimizable

Anteriormente, en el apartado Soluciones relacionales y datos NoSQL se explica el asunto de la coherencia de los datos. La coherencia de los datos hace referencia a la integridad de los datos. Los servicios nativos de nube con datos distribuidos dependen de la réplica y deben adoptar una solución de compromiso y elegir entre coherencia, la disponibilidad y la latencia de lectura.

La mayoría de las bases de datos distribuidas permiten a los desarrolladores elegir entre dos modelos de coherencia: coherencia fuerte y coherencia final. La coherencia fuerte es el estándar de oro de la programación de datos. Garantiza que la consulta siempre devolverá los datos más actuales, incluso si el sistema deben incurrir en latencia esperando una actualización que se replique en todas las copias de bases de datos. Una base de datos configurada para la coherencia final devolverá datos inmediatamente, incluso si los datos no son la copia más actual. Esta última opción permite una disponibilidad más alta, una mayor escala y un rendimiento aumentado.

Azure Cosmos DB ofrece cinco modelos de coherencia bien definidos que se muestran en la figura 5-13.

Figura 5-13: niveles de coherencia de Cosmos DB

Con estas opciones, puede tomar decisiones precisas y soluciones de compromiso granulares para la coherencia, la disponibilidad y el rendimiento de los datos. En la siguiente tabla se presentan los niveles.

Nivel de coherencia	Descripción
Ocasional	No existen garantías de ordenación para las operaciones de lectura. Las réplicas convergirán en última instancia.
Prefijo constante	Las operaciones de lectura siguen siendo finales, pero se devuelven los datos en el mismo de orden en el que se escriben.
Sesión	Garantiza las operaciones de la lectura y la escritura de cualquier dato durante la sesión actual. Es el nivel de coherencia predeterminada.
De obsolescencia entrelazada	Lee las operaciones de escritura finales por el intervalo que especifica.
Alta	Se garantiza que las operaciones de las lecturas devolverán la versión confirmada más reciente de un elemento. Un cliente nunca ve una operación de lectura no confirmada ni parcial.

En el artículo Getting Behind the 9-Ball: Cosmos DB Consistency Levels Explained, (Introducción a la 9-Ball: explicación de los niveles de coherencia de la base de datos de Cosmos DB), Jeremy Likness, administrado de programas de Microsoft, ofrece una explicación excelente de los cinco modelos.

Creación de particiones

Azure Cosmos DB adopta la creación de particiones automáticamente para escalar una base de datos para satisfacer las necesidades de rendimiento de los servicios nativos de nube.

Los datos de Cosmos DB se administran al crear bases de datos, contenedores y elementos.

Los contenedores residen en una base de datos de Cosmos DB y representan una agrupación de elementos independiente al esquema. Los elementos son los datos que agrega al contenedor. Están representados como documentos, filas, nodos o bordes. Todos los elementos que se agregan a un contenedor se indexan automáticamente.

Para obtener la partición del contenedor, los elementos se dividen en subconjuntos distintos denominados particiones lógicas. Las particiones lógicas se rellenan en función del valor de una clave de partición que está asociada con cada elemento de un contenedor. En la figura 5-14 aparecen dos contenedores cada uno con una partición lógica basada en un valor de clave de partición.

Figura 5-14: mecanismos de partición de Cosmos DB

En la anterior figura, preste atención a cómo cada elemento incluye una clave de partición de «ciudad» o «aeropuerto». La clave determina la partición lógica del elemento. Los elementos con un código de ciudad se asignan al contenedor de la izquierda y los que tienen un código de aeropuerto, al contenedor de la derecha. Al combinar el valor de clave de partición con el valor de id. se crea un índice de elemento, que identifica de forma única el elemento.

De forma interna, Cosmos DB administra automáticamente la ubicación de las particiones lógicas en particiones físicas para satisfacer las necesidades de escalabilidad y rendimiento del contenedor. Dato que los requisitos de almacenamiento y rendimiento aumentan, Azure Cosmos DB redistribuyen las particiones lógicas en un mayor de número de servidores. Cosmos DB administra las operaciones de redistribución y se invocan sin interrupciones ni tiempo de inactividad.

Bases de datos NewSQL

NewSQL es una tecnología de bases de datos emergente que combina la escalabilidad distribuida de NoSQL con las garantías ACID de una base de datos relacional. Las bases de datos de NewSQL son importantes para sistemas empresariales que tienen que procesar grandes volúmenes de datos, en entornos distribuidos, con compatibilidad transaccional completa y con ACID. Una base de datos NoSQL puede proporcionar escalabilidad masiva, pero no garantiza la coherencia de datos. Los problemas intermitentes de los datos incoherentes pueden suponer una carga en el equipo de desarrollo. Los desarrolladores deben crear medidas de seguridad en el código de microservicios para administrar problemas que causan los datos incoherentes.

La Cloud Native Computing Foundation (CNCF) (Fundación de Informática Nativa de Nube) cuenta con varios proyectos de bases de datos NewSQL.

Project	Características
CockroachDB	Una base de datos relacional compatible con ACID que se escala de forma universal. Si se agrega un nodo nuevo a un clúster, CockroachDB equilibrará los datos entre instancias y zonas geográficas. Crea, administra y distribuye réplicas para garantizar la confiabilidad. Es de código abierto y gratis.
TiDB	Una base de datos de código abierto que admite cargas de trabajo de procesamiento analítico y transaccional híbrido (HTAP). Es compatible con MySQL y cuenta con escalabilidad horizontal, coherencia fuerte y alta disponibilidad. TiDB se comporta como servidor MySQL. Es posible usar las bibliotecas de cliente MySQL existentes, sin hacer cambios radicales de código en la aplicación.
YugabyteDB	Una base de datos SQL distribuida, de código abierto y alto rendimiento. Admite latencia de consulta baja, resistencia frente a errores y distribución de datos global. YugabyteDB es compatible con PostgreSQL y controla las cargas de trabajo de RDBMS de escalabilidad horizontal y OLTP a escala de Internet. El producto también admite NoSQL y es compatible con Cassandra.
Vitess	Vitess es una solución de bases de datos para la implementación, el escalado y la administración de clústeres amplios de las instancias MySQL. Se puede ejecutar en una arquitectura de nube privada o pública. Vitess combina y amplía muchas características importantes de MySQL y es compatible con particionamiento horizontal y verticales. Creado por YouTube, Vitess ha atendiendo todo el tráfico de base de datos de YouTube desde 2011.

Los proyectos de código abierto de la figura anterior están disponibles en la Cloud Native Computing Foundation. Tres de las ofertas son productos completos de base de datos, que incluyen compatibilidad con .NET. La otra, Vitess, es un sistema de agrupación en clústeres de base de datos que escala horizontalmente grandes clústeres de instancias de MySQL.

Las bases de datos NewSQL tienen como uno de sus objetivos clave de diseño operar de forma nativa en Kubernetes, aprovechando las ventajas de la resistencia y escalabilidad de la plataforma.

Las bases de datos NewSQL están pensadas para desarrollarse en entornos de nube efímeros en los que se pueden reiniciar máquinas virtuales subyacentes o se pueden programar en un momento dato sin previo aviso. Las bases de datos están pensadas para sobrevivir a errores de nodos sin perder datos ni tiempo de inactividad. CockroachDB, por ejemplo, puede sobrevivir a una pérdida de máquina al mantener tres réplicas coherentes de cualquier dato en los nodos en un clúster.

Kubernetes usa una construcción de servicios para permitir que un cliente aborde un grupo de procesos NewSQL idénticos desde una única entrada DNS. Al desacoplar las instancias de bases de datos desde la dirección del servicio al que se asocia, se puede escalar sin interrumpir las instancias de aplicación existentes. Al enviar una solicitud a cualquier servicio en un momento dato, siempre se obtendrá el mismo resultado.

En este escenario, todas las instancias de bases de datos son iguales. No hay relaciones principales ni secundarias. Mediante las técnicas como la réplica de consenso que se encuentran en CockroachDB, cualquier modo de base de datos puede controlar cualquier solicitud. Si el nodo que recibe una solicitud de carga equilibrada tiene los datos que necesita localmente, responde inmediatamente. De lo contrario, el nodo se convierte en una puerta de enlace y reenvía la solicitud a los nodos adecuados para obtener la respuesta correcta. Desde la perspectiva del cliente, cada nodo de base de datos es igual: aparecen como una base de datos lógica única con las garantías de coherencia de un sistema de una única máquina, a pesar de tener docenas o incluso cientos de nodos activos en segundo plano.

Consulte el artículo DASH: Four Properties of Kubernetes-Native Databases, (DASH: cuatro propiedades de las bases de datos nativas de Kubernetes), para obtener una visión detallada de los mecanismos detrás de las bases de datos NewSQL.

Migración de datos a la nube

Una de las tareas más lentas es migrar datos de una plataforma de datos a otra. Con Azure Data Migration Service se pueden acelerar estas tareas. Puede migrar datos de varios orígenes de bases de datos externos a las plataformas de Azure Data con tiempo de inactividad mínimo. Entre las plataformas de destino se incluyen los siguientes servicios:

• Azure SQL Database
• Azure Database for MySQL
• Azure Database for MariaDB
• Azure Database for PostgreSQL
• Azure Cosmos DB

El servicio proporciona recomendaciones para servirle de orientación por los cambios necesarios para ejecutar una migración pequeña o grande.

AnteriorSiguiente