La belleza de Cosmos DB, el servicio de base de datos distribuido globalmente y de baja latencia de Microsoft, siempre ha sido la cantidad de cosas diferentes que reúne. Una combinación de diferentes modelos de datos y API de consulta de base de datos ofrece la escala elástica de la nube y NoSQL, mientras que las ricas opciones de consulta de esquema de base de datos SQL y una selección de modelos de coherencia hacen que la creación de un sistema distribuido sea flexible y simple.

Raghu Ramakrishnan, CTO de Azure Data: "Tuvimos un momento de iluminación... tenemos la infraestructura para conectar los aspectos operativos y analíticos".
Imagen: Microsoft

Ahora también puede combinar análisis, procesar datos operativos y transaccionales en tiempo real, sin ralentizar las bases de datos operativas ni tener que pasar por procesos ETL complejos y lentos para obtener una copia de los datos con los que trabajar.

"Puedes tener tu pastel y comértelo también", dijo a TechRepublic Raghu Ramakrishnan, director de tecnología de Azure Data.

Índice

Alimentar de ida y vuelta

El nuevo vínculo de Azure Synapse para Cosmos DB fue en realidad un efecto secundario conveniente de crear el flujo de cambios que se usó para la nueva característica de copia de seguridad continua y recuperación en un momento dado (actualmente en versión preliminar).

El uso de una base de datos en la nube evita muchas de las razones tradicionales para realizar copias de seguridad: los servicios en la nube rara vez experimentan interrupciones catastróficas hasta el punto de perder datos, y si está realizando una copia de seguridad para usar si el servicio en la nube no está disponible, aún necesita una infraestructura en el que utilizar esta copia de seguridad.

Pero aún puedes cometer un error o implementar un cambio que resulte ser una mala idea, por lo que la opción de retroceder 30 días en el tiempo puede ser útil. Cosmos DB permite esto al mantener un registro permanente de cada cambio realizado en cada contenedor en su base de datos, en el orden en que ocurren. Si desea volver a una hora específica, el sistema puede usar esta fuente de cambios para determinar qué cambió y revertirlo.

Los desarrolladores pueden usar el flujo de cambios para desencadenar acciones para herramientas basadas en eventos como Azure Functions, o para experimentar cuál de las diferentes propiedades de datos es más útil para particionar datos: configure dos contenedores, cada uno con una propiedad de datos diferente como clave para las particiones, y reproduzca los cambios del primer contenedor al segundo y podrá ver qué propiedad funciona mejor en los datos en vivo sin tener que retrasar todo el proyecto mientras decide. Algunos desarrolladores usan el flujo de cambios como un mecanismo de replicación para archivar datos más antiguos, porque todo pasa por el flujo de cambios. Esta fue la forma obvia de crear la función de guardar.

"En el camino, tuvimos un momento de bombilla", dijo Ramakrishnan a TechRepublic. "Dijimos 'espera un minuto, tenemos la infraestructura para conectar los lados operativo y analítico juntos'".

“Cada cambio se registra atómica y sincrónicamente. Continuamente olfateamos el flujo de cambio y lo reproducimos mientras mantenemos gradualmente una versión en columnas de los datos en el lado de Synapse.

VER: Kit de contratación: ingeniero de aplicaciones (Premium de TechRepublic)

El uso de la fuente de cambios existente significa que la importación de datos a Synapse no ralentiza Cosmos DB; esto es importante porque se usa ampliamente para sitios de comercio electrónico como Asos. Cuando observa la pantalla del menú en cualquier tienda de Chipotle en todo el mundo, proviene directamente de Cosmos DB, al igual que en su aplicación móvil.

Columnas y árboles

El noventa por ciento de las veces, estima Ramakrishnan, los desarrolladores quieren trabajar con datos de Cosmos DB de manera transaccional. "No quieren comprometer sus garantías de rendimiento transaccional, pero de vez en cuando quieren emitir estas grandes consultas".

Esto significa que los datos almacenados en Synapse no se pueden estructurar de la misma manera que en Cosmos DB, porque el uso de datos en las cargas de trabajo varía enormemente.

“Si tiene datos de inventario en Cosmos DB, los usa para la gestión de inventario y el procesamiento de solicitudes, pero también tiene su centro de análisis y desea que sus análisis reflejen su inventario en tiempo real”, dijo Ramakrishnan. "En Cosmos DB, realizo un cambio en un elemento del inventario, busco algo para un carrito de compras. Por lo general, estas son recuperaciones muy específicas y los requisitos de latencia son altos. En análisis, digo "Dame la desviación estándar promedio". de esta tabla de petabytes. Estos son patrones de acceso muy diferentes. Debajo de estas clases de sistemas hacen cosas muy diferentes y, sin embargo, cada vez más personas quieren análisis operativos en tiempo real, y queremos que pueda hacerlo sin ejecutar su propio ETL , que es un verdadero dolor.

Para habilitar esto, el formato en el que se almacenan los datos con Azure Synapse está optimizado para el rendimiento analítico. Cuando vincula tablas de inventario a Synapse con Synapse Link, el servicio crea automáticamente un índice btree, que es la forma en que las bases de datos relacionales almacenan datos ordenados de manera eficiente. “Es una estructura auxiliar que te permite obtener datos ordenados. Supongamos que tiene una tabla de empleados y desea realizar consultas de rango sobre el salario. Si ha ordenado el acceso a estos datos, puede hacerlo de manera mucho más eficiente”, explicó Ramakrishnan.

"Pero lo bueno de todo es que el mantenimiento de la estructura auxiliar está en la base de datos, no en usted. Desde su punto de vista, le ha dado a la base de datos una pequeña pista sobre cómo planea usarla y, a partir de ahí, mantenerla". transacciones actualizadas, manejar fallas y todas esas tonterías: eso lo decide la base de datos, básicamente usted mantiene una versión en columnas de sus datos de Cosmos DB de manera que Synapse pueda acceder, por lo que es un índice de servicio cruzado, uno de los primero en su tipo, y nos encargamos de administrarlo de manera completamente transparente bajo el capó, detrás de escena, de una manera que no infrinja Cosmos DB.

De hecho, dada la forma en que funciona el almacenamiento en la nube, las máquinas virtuales en las que residen los datos para Cosmos DB o Synapse y el cómputo que lo alimenta podrían estar en el mismo rack físico de todos modos, señala Ramakrishnan. “Todas las distinciones son cómo las absorbemos e interpretamos; podemos hacerlos fácilmente transparentes para el usuario final.

Convergencia e integración

En los últimos dos años, Microsoft ha acercado gradualmente los grandes datos y los almacenes de datos. “Si toma Big Data, los lagos de datos en Hadoop y Spark y este mundo, los datos y archivos almacenados tienen una variedad de motores. Si toma almacenes de datos, los datos almacenados en almacenes de datos administrados tienen SQL. Estos dos mundos están convergiendo”, dijo Ramakrishnan. "Le brindamos un inicio de sesión único en un espacio de trabajo seguro donde puede usar [Jupyter] Notebooks, puede usar Azure Data Studio, SQL Studio. Puede usar SQL o Spark en cualquiera de sus datos. Microsoft agregará más opciones de almacenamiento y consulta a esta lista en el futuro, agregó.

“Así es como unimos el mundo de las bases de datos operativas y las bases de datos analíticas. Y también haremos esto para todas las demás tiendas operativas. »

Los servicios en la nube se han vuelto mucho más poderosos, pero conectarlos para hacer lo que uno quiere sigue siendo demasiado trabajo, admitió Ramakrishnan. Reunir los servicios operativos y analíticos es un intento de ayudar con esto, como lo es el nuevo servicio Azure Purview para administrar el cumplimiento y la gobernanza de todas sus bases de datos, almacenamiento y servicios en la nube, que incluye Cosmos DB, y el nuevo servicio administrado Cassandra, que puede ráfaga a Cosmos DB.

"A los clientes todavía les cuesta hacer las cosas de un extremo a otro porque, literalmente, todo lo que quieren hacer implica unir muchos servicios. Con el nivel de privacidad y seguridad cada vez más alto, reunir todo esto, dentro de una red virtual, de manera compatible, lidiar con todos los desafíos de interoperabilidad de formatos y metadatos está demostrando ser un gran desafío Creemos que el futuro consistirá en encontrar el equilibrio adecuado entre tener estándares abiertos, crear un ecosistema abierto, pero al mismo tiempo, como un Lego, enchufándolos a los enchufes, preintegrándolos, para que el cliente no hiciera la última milla.

“Estas plataformas convergentes son clave para ofrecer una experiencia llave en mano de nivel empresarial [in the cloud]concluyó Ramakrishnan.