Just a few weeks ago at the Microsoft Build conference, Microsoft announced that users of their serverless DocumentDB would soon receive a massive new update in the form of a replacement product Microsoft calls Cosmos DB. Today, as I was working on my Azure portal, a little notification popped up letting me know Cosmos DB is up and running on my tenant, so I thought it would be worth taking it for a spin. Here are some of the key takeaways from my whirlwind tour of the product.
A little experiment
This article contains animated gifs to preview various Cosmos DB features. Please leave a comment and let me know if you like the animations or if they just give you a headache. I look forward to your feedback!
What is Cosmos DB?
Cosmos DB is Microsoft's globally distributed, multi-model database. It is designed with performance in mind, offering blazingly fast data speeds and the ability to scale out to multiple regions. Of course, Cosmos DB provides your standard SQL-style tables and data retrieval methods, but there is much more under the hood. For example, you can also create content, graph, and MongoDB databases.
Cloud providers must offer database solutions that are easy to create, manage and scale, so Microsoft knows Cosmos DB is important for Azure's future. Microsoft offers some industry-leading service level guarantees. As of this writing, here are just a few*:
- Availability: 99.99% uptime availability SLA for each of the data and control plane operations.
- Throughput: 99.99% of requests complete successfully
- Latency: 99.99% of <10 ms latencies at the 99th percentile
- Consistency: 100% of read requests will meet the consistency guarantee for the consistency level requested by you.
*The above numbers are from the Microsoft Azure Cosmos website.
Since Cosmos DB is still very new, the documentation is still clearly a work in progress. You can access the documentation here and will probably notice lots of comments from me making improvement suggestions 🙂
Here are some terms I learned along the way that will hopefully help you get up to speed:
- Database account = database: Throughout the Cosmos DB documentation, you will see instructions to create a database account but will find no mention of such a thing on the Azure portal. When Microsoft tells you to create a database account what they mean is create a database.
- Entity = table row: Since a database can be columnar, graph, or document, Microsoft calls these items entities. I have taken to likening an entity to a row of data in a table, even though it might also be a document or some other set of data.
- Locations/regions = physical data center locations: Microsoft has data centers located around the world. You can select a region to store your database, like US West. While this might be obvious at first, I point it out because you can replicate it to multiple regions after the fact (more on that later).
There is a lot more to learn, but those are the big ticket items you should be aware of when just getting started.
Database account creation
You can create a database using the Azure portal, via the CLI, using PowerShell, or programmatically. When you create the database account, you will need to give it a unique id (the database name), select the API (the type of database), select your subscription, create or select a resource group, and then pick a location.
A welcome feature in Cosmos DB is the ability to create sample data and download a lightweight Visual Studio project that helps you connect to the database and before CRUD (create, read, update, delete) operations. After you download the file, there are links to tutorials that walk you through using the project.
Do keep in mind the documentation in the tutorials and samples is pretty slim right now, so you will want to walk through the code bit-by-bit to learn how exactly it works.
Scale out replication
Microsoft touts Cosmos DB as being globally distributed. Long the dream of many IT professionals, Cosmos DB allows you to select a database and replicate it to additional regions with a few mouse clicks. While you will need to consider how exactly you define your application, Microsoft wants to make it very easy for you to scale out your application.
Let's say your database resides in the US West region but your app suddenly takes off in Brazil and after reviewing performance logs, you notice the app is taking too long to load data in that region. All you need do is head over to the Azure portal, open the database, click the regions map, and add the Brazil region. Azure will handle all the work of replicating your database so you can focus on adding features and not worry [as much] about the distributed nature of your database.
Stored procedures, triggers, and functions
Very often, your application will not perform certain business logic. There are plenty of reasons for that as the business logic is unique for only a small subset of use cases--or the logic requires too much network traffic.
Cosmos DB allows you to create functions, triggers, and stored procedures that will run within the database. Here is a simple example: your code is an API that accepts a person's full name, like Bill Raymond. After the database stores that name, you might want the database to read that entry and populate the first name column with Bill and the last name column with Raymond. Writing a little custom code is straightforward in Azure and you can do so directly from the Azure portal.
As of this writing, Cosmos DB is in production, but the Data Explorer is still in preview (meaning, it is still a big buggy). Nevertheless, it does come with the ability to add triggers, functions, and stored procedures. To do this, go to an Azure database account, select the table (or collection), and then add the trigger, function, or stored procedure.
There are many other new or improved features in Azure Cosmos DB and I expect there will be more to come over the next months. If you are a developer working with tables, then I strongly recommend you learn the Table API. You can find a link here.