Editor Top
Con la marca de «base de datos a escala planetaria» de Microsoft, Cosmos DB es uno de los servicios básicos de Azure, que impulsa sus propias aplicaciones y las suyas. Diseñado para el desarrollo de aplicaciones distribuidas, Cosmos DB ofrece una gama de modelos de coherencia y, lo que es más interesante, una serie de personalidades diferentes que le permiten utilizarlo como cualquier otro conjunto de bases de datos conocidas.
Estos incluyen una API compatible con PostgreSQL, una base de datos gráfica como Neo4j y su propio modelo de base de datos de documentos, así como soporte para la conocida base de datos distribuida Apache Cassandra. Una de las personalidades más populares es un conjunto de API que tienen como objetivo ofrecer la mayoría de las funciones de la popular base de datos MongoDB NoSQL. Esta última opción es interesante, ya que le permite tomar rápidamente las aplicaciones modernas existentes en las instalaciones y llevarlas rápidamente a la nube, listas para rediseñar a escala global.
Salta a:
Descripción de los costos de facturación de las unidades de solicitud en Cosmos DB
Hay un problema que a menudo confunde a los desarrolladores que provienen de un entorno de desarrollo más tradicional: Cosmos DB utiliza el concepto de Unidades de solicitud para gestionar la facturaciónademás de los cargos de almacenamiento estándar de Azure.
Una RU es una forma de describir y cobrar por cómo una base de datos como Cosmos DB usa los recursos de Azure. Reúne cómputo, E/S y memoria, utilizando los recursos para hacer una lectura de 1 KB de un solo elemento como base de lo que se puede considerar mejor como la moneda interna propia de Cosmos DB.
Con una sola lectura de un solo elemento medido como 1 RU, todas las demás operaciones se facturan de manera similar, agrupando sus acciones y el uso de recursos como un valor en RU. Compra paquetes de RU que luego se gastan en operaciones de base de datos, como comprar tokens para un juego como Roblox. RU se puede usar para administrar operaciones, con un número fijo por segundo disponible para sus operaciones o se puede usar para pagar operaciones sin servidor. También puede usar RU para permitir que su base de datos se escale según sea necesario, aunque esto significa que una aplicación particularmente ocupada puede volverse muy costosa de ejecutar de repente.
El modelo RU, si bien es lógico para un servicio nativo de la nube, le dificulta predecir el costo de ejecutar Cosmos DB si está acostumbrado a los modelos de costos tradicionales. Si bien es posible crear herramientas para ayudar a predecir los costos, debe tener en cuenta más que solo las operaciones que utiliza su base de datos, ya que el tipo de modelo de consistencia que elija afectará el rendimiento disponible.
Presentación de núcleos virtuales en Cosmos DB
Microsoft ahora ofrece una alternativa al modelo RU para desarrolladores que traen sus aplicaciones basadas en MongoDB a Cosmos DB. En lugar de pagar por RU y almacenamiento, ahora puede optar por centrarse en la combinación más familiar de instancias de aplicaciones y discos asignados. Esto le da acceso a un modelo mucho más cercano a Servicio de nube Atlas administrado de MongoDBlo que permite una migración más predecible desde las instalaciones u otras nubes.
Disponible como Azure Cosmos DB para MongoDB vCore, esta nueva versión de la base de datos NoSQL de Microsoft es una parte completa de su infraestructura de Azure que le brinda fragmentación automatizada e integración con la interfaz de línea de comandos de Azure y otras herramientas de administración.
Microsoft lo describe como una forma de «modernizar MongoDB con una arquitectura familiar». El objetivo es ofrecer lo más cerca posible de un conjunto de API compatibles, sin dejar de ofrecer escalabilidad. Por ejemplo, Microsoft nos dijo,
“Azure Cosmos DB para MongoDB vCore permite consultas de bases de datos más ricas y complejas, como las búsquedas de texto completo que impulsan los chatbots basados en la nube”.
Mover aplicaciones de MongoDB a Cosmos DB
Si tiene un código que usa el lenguaje de consulta de MongoDB para trabajar con sus datos, debería funcionar como antes, y el requisito principal es cambiar cualquier punto de conexión a la dirección de Azure adecuada.
Sin embargo, no todos los comandos están disponibles en Cosmos DB, ya que las funciones subyacentes no se asignan entre las dos bases de datos. Vale la pena prestar atención a la lista de comandos admitidos, especialmente si confía en las herramientas de control de sesión de MongoDB, ya que gran parte de esto no está disponible actualmente en Cosmos DB. También tendrá que cambiar cualquier autenticación a las herramientas nativas de Azure.
Mover datos entre los dos debería ser lo suficientemente fácil, ya que las herramientas de exportación e importación de MongoDB le permiten guardar datos como JSON para exportaciones parciales o como BSON más compacto para una base de datos completa. Si está moviendo una gran cantidad de datos como JSON, esto puede ser costoso, ya que se le cobrará por las transferencias de datos.
Los precios se basan en la infraestructura virtual estándar de Azure, utilizando sistemas de alta o baja disponibilidad. Si no necesita un sistema HA, puede ahorrar hasta un 50 % en el precio de HA. El almacenamiento base para un sistema vCore Cosmos DB es de 128 GB, lo que debería ser adecuado para muchas cargas de trabajo comunes. Puede elegir comenzar con dos vCPU y 8 GB de RAM y escalar hasta 32 con 128 GB de RAM.
Si bien la mayoría de las aplicaciones funcionarán con pocas modificaciones, como la versión RU, la versión vCore de la compatibilidad con MongoDB de Cosmos DB tiene algunas diferencias con las API oficiales. Le preguntamos a Microsoft si había planes para agregar más cobertura en versiones futuras, más allá del cambio a vCore en lugar de sin servidor.
“En la mayoría de los escenarios, esto hace que las dos tecnologías sean totalmente compatibles. En función de los comentarios de los clientes, uno de los mayores puntos débiles con respecto a la compatibilidad entre MongoDB y Azure Cosmos DB fue la necesidad de rediseñar y remodelar sus bases de datos de MongoDB para que se ajusten a la arquitectura de Azure Cosmos DB. Esta versión elimina ese problema ya que las dos bases de datos ahora tienen esencialmente la misma ‘forma’. Además, tenemos una gran compatibilidad de funciones entre los dos y continuaremos implementando más funciones a medida que pase de la versión preliminar a la disponibilidad general”, respondió un portavoz.
Esta nueva opción de MongoDB debería facilitar la transferencia de una carga de trabajo de MongoDB que ya ha escrito a Cosmos DB y, por lo tanto, liberarse de tener que ejecutar su propia infraestructura de MongoDB, o permitirle consolidar el uso de Cosmos DB como su base de datos en la nube, trayendo bases de datos de otros proveedores de la nube a Azure, donde puede usar todos los demás recursos y servicios de Azure que los proveedores más pequeños como MongoDB no ofrecen.
