Branded as Microsoft’s “planetary scale database,” Cosmos DB is one among Azure’s foundational companies, powering its personal functions in addition to yours. Designed for distributed software improvement, Cosmos DB affords a spread of consistency fashions and, extra curiously, a collection of various personalities that help you use it like all one among a set of acquainted databases.
These embrace a PostgreSQL-compatible API, a graph database like Neo4j, and its personal doc database mannequin, in addition to help for the acquainted Apache Cassandra distributed database. One of the extra standard personalities is a set of APIs that goal to supply many of the options of the favored MongoDB NoSQL database. This final choice is an attention-grabbing one, because it means that you can shortly take present on-premises fashionable functions and shortly carry them to the cloud, prepared for re-architecting on a worldwide scale.
Jump to:
Understanding Request Units billing prices in Cosmos DB
There’s one challenge that always confuses builders coming from a extra conventional improvement setting: Cosmos DB makes use of the idea of Request Units to deal with billing, along with Azure’s commonplace storage expenses.
An RU is a approach of describing and charging for the way a database like Cosmos DB makes use of Azure sources. It brings collectively compute, I/O and reminiscence, utilizing the sources to make a 1KB learn of a single merchandise as the bottom of what can greatest be considered Cosmos DB’s personal inside foreign money.
With a single learn of a single merchandise measured as 1 RU, all different operations are billed in an identical approach, bundling their actions and useful resource utilization as a price in RU. You buy bundles of RU which are then spent in database operations, very like shopping for tokens for a recreation like Roblox. RU can be utilized to handle operations, with a set quantity per second out there to your operations or used to pay for serverless operations. You also can use RUs to permit your database to scale as wanted, although this does imply a very busy software can all of the sudden grow to be very costly to run.
The RU mannequin, whereas logical for a cloud-native service, makes it arduous so that you can predict the price of operating Cosmos DB if you happen to’re used to conventional costing fashions. While it’s potential to construct instruments to assist predict prices, it’s essential to account for extra than simply the operations your database makes use of, as the kind of consistency mannequin you select will have an effect on the out there throughput.
Introducing vCores to Cosmos DB
Microsoft is now providing an various to the RU mannequin for builders bringing their MongoDB-based functions to Cosmos DB. Instead of paying for RUs and storage, now you can select to deal with the extra acquainted mixture of software cases and assigned disks. This offers you entry to a mannequin that’s loads nearer to MongoDB’s managed Atlas cloud service, permitting a extra predictable migration from on premises or different clouds.
Available as Azure Cosmos DB for MongoDB vCore, this new launch of Microsoft’s NoSQL database is a full-fledged a part of your Azure infrastructure that offers you automated sharding and integration with Azure’s Command-Line Interface and different administration tooling.
Microsoft describes it as a technique to “modernize MongoDB with a familiar architecture.” The goal is to ship as shut as potential a set of appropriate APIs, whereas nonetheless providing scalability. For instance, Microsoft instructed us,
“Azure Cosmos DB for MongoDB vCore enables richer, more complex database queries such as the full-text searches that power cloud-based chatbots.”
Moving functions from MongoDB to Cosmos DB
If you’ve gotten code utilizing MongoDB’s question language to work together with your knowledge, it ought to work as earlier than, with the principle requirement being to alter any endpoints to the suitable Azure handle.
However, not all instructions can be found on Cosmos DB, because the underlying options don’t map between the 2 databases. It’s price listening to the listing of supported instructions, particularly if you happen to’re counting on MongoDB’s session management tooling, as a lot of this isn’t at the moment out there in Cosmos DB. You’ll even have to modify any authentication to Azure’s native tooling.
Moving knowledge between the 2 needs to be simple sufficient, as MongoDB’s export and import instruments help you save knowledge as both JSON for partial exports or the extra compact BSON for a full database. If you’re shifting numerous knowledge as JSON, this may be costly, as you’ll be charged for knowledge transfers.
Pricing relies on commonplace Azure digital infrastructure, utilizing both excessive availability or decrease availability programs. If you don’t want an HA system, then it can save you as much as 50% on the HA pricing. Base storage for a vCore Cosmos DB system is 128GB, which needs to be appropriate for a lot of widespread workloads. You can select to start out with two vCPUs and 8GB of RAM and scale as much as 32 with 128GB of RAM.
While most functions will work with little modification, just like the RU model, the vCore launch of Cosmos DB’s MongoDB help does have some variations from the official APIs. We requested Microsoft if there have been plans so as to add extra protection in future releases, past the shift to vCore over serverless.
“In most scenarios, this makes the two technologies entirely compatible. Based on customer feedback, one of the larger pain points regarding compatibility between MongoDB and Azure Cosmos DB was the need to re-engineer and reshape their MongoDB databases to fit with how Azure Cosmos DB is architected. This release eliminates that pain point as the two databases are now essentially the same ‘shape.’ In addition, we have strong feature compatibility between the two and will continue to roll out more features as this moves out of preview and into general availability,” a spokesperson responded.
This new MongoDB choice ought to make it simpler to carry a MongoDB workload you’ve already written to Cosmos DB and thereby free your self from having to run your personal MongoDB infrastructure — or allow you to consolidate on utilizing Cosmos DB as your cloud database, bringing databases from different cloud suppliers to Azure, the place you should utilize all the opposite Azure sources and companies that smaller suppliers like MongoDB don’t supply.