If Azure is the color of the sky, then Cosmos is very much an appropriate name for its planet-scale database. It is a globally-distributed, schema-agnostic, and multi-model database offered by Microsoft, in contrast to its very familiar, decades-old, relational SQL Server database. In this blog series, we will explain the schema-agnostic and multi-model characteristics of Cosmos DB in further articles. As an introductory article, let’s first go through a chapter in Cosmos DB’s short but remarkable history.
How, When, Why?
Developing a globally distributed application certainly comes with complications of similar magnitude. Let’s take the example of a hypothetical sports channel XYZ that gives live updates for football matches. Its user base is scattered across 50+ countries spanning over 5 continents. Users from all over the world can tune in to the channel and watch live updates for their favorite fixtures. The company is operating out of North America and has its servers deployed there. On the surface, it sounds very simple, but the devil is in the details.
Let’s say that a football match is currently going on. User A from North America opens the channel and starts to get live updates. They will face little or no latency because the servers are also deployed there. However, another user B from Australia wants the live updates, they may have to face longer amount of delays depending upon the network and the traffic. Consequently, the overall user experience of one country will be vastly different from the other. To counter this problem, the sports channel decides to replicate its servers all over the globe to reduce latency to its users and boost their user experience.
Apart from the administrative effort of replicating these servers, it also comes with its own set of problems which are intrinsic to any replication problem. Specifically, we need to answer one question: How soon should the data be replicated? If your answer is ‘Immediately’, you may want to think again. Let’s say that the channel has 60 servers scattered around the globe. If we want to update the score on one of these servers, we will have to update it on all 60 of them. To achieve this replication immediately, or as we say, ‘in real-time’, we will have to write to those 60 servers immediately. And just like that, our cost to write multiplied by 60. If we translate this cost into throughput, we will now need much more system resources than before.
However, if we can afford a little delay in replication, we can save this cost. For example, we don’t need to write to all servers immediately. We can replicate data one by one, which will again reduce the cost to replicate. However, this approach will risk exposing out-of-date data to some users because the replication now happens one by one. This balancing act is the age-old tradeoff between latency and throughput.
To answer these difficult questions, Microsoft started working on what they called the ‘Florence Project’ back in 2010. They launched their first globally distributed Azure service in 2015 named DocumentDB, which is still supported as a SQL API in the current infrastructure of Cosmos DB. At the time, it only supported the document data-model. Later in 2017, Microsoft announced support for MongoDB, Cassandra, Azure Tables, and Graph API, and encapsulated them in one service, which we now refer to as Azure Cosmos DB.
The major features of Azure Cosmos DB are:
- Multi-model API Support:
Cosmos DB supports five of the most popular types of APIs to store and process data, which really fits in with its planet-scale approach to solve problems.
- High Availability:
It offers financially-backed SLAs to provide availability of resources up to the 99th
- Spectrum of Consistency Models:
As we discussed above in the history lesson, we have immediate or delayed replication. However, Cosmos DB also enables us to choose between these two extremes of the consistency spectrum.
- Near-zero Replication Effort:
Developers and users can replicate the database to other regions with a single-click. Cosmos DB takes care of the rest.
Cosmos DB is highly effective in applications where the data is dispersed, and lower latency is crucial. This includes:
- IoT devices
- Social Applications
Microsoft has been using Azure Cosmos DB for many of its products including:
- Office 365
In this introduction to Azure Cosmos DB, we looked at why and how Azure Cosmos DB was developed, and how it evolved from DocumentDB to the Cosmos DB we know now. Also, we looked at the use cases and features of the service.
In the next article, we will look at the Consistency Model of Azure Cosmos DB, which is one of its most important aspects.
If you have any question or queries, do not hesitate to reach out to us!