Introduction

In the realm of databases, Azure Cosmos DB stands out as a Microsoft-backed, fully managed NoSQL solution. Boasting an impressive single-digit millisecond response time, it seamlessly scales to meet the diverse needs of any business.

Ensuring uninterrupted business operations, Azure provides a rock-solid Service Level Agreement (SLA) for guaranteed business continuity.

What’s truly remarkable is Cosmos DB’s geographic flexibility. Tailor it to be in close proximity to your customer base or distribute it across multiple locations simultaneously. Azure takes the reins, ensuring a 99.999% update consistency across all regions—a level of reliability that businesses can depend on.

Understanding the Cosmos DB Nomenclature is crucial when configuring an account. Here’s a breakdown:

1. Databases:
   • Multiple databases can be created within a single Cosmos DB account.
2. Containers:
   • Think of containers as counterparts to tables in MS SQL Server within a database.
3. Items:
   • Within containers, items represent individual rows in a table.
4. Additional Functionalities:
   • Each container offers the flexibility to incorporate triggers, procedures, and user-defined functions for more tailored and intricate operations.

This clear delineation of terms ensures a structured and efficient approach when working with Cosmos DB, making it easier to manage and harness its full capabilities.

Advertisement

RU/s Scaling

Azure cosmosDb cost is calculated on how much resources per second are utilized to process 1 byte of request. It is called RU/s. i.e., Request Unit per Second.

Each cosmosDb container provides its own scaling option.

There are two types scaling options –

1. Manual
2. Auto Scale

Manual

Manual scaling is employed in case of exact size and quantity of maximum request is known. We can convert that number into RU/s using Microsoft capacity calculator

Example-

Assuming we have a cosmosDb configured with 400 RU/s. Our School api is having performing CRUD operation with following RU/s cost

• Get – 3 RUs
• Post – 10 RUs
• Put – 10 RUs
• Delete – 2 RUs

Considering above RU structure we can say, configured cosmos can supports

• 133 Get calls per second
• 40 Post and Put calls per second
• 200 Delete calls per second

What happens when this count is breached?

Once request count per second is greater than our desired limit cosmosDb will give a 429 Http status code in response. i.e., Too many requests

Auto Scale

Auto scaling is done when we expect ups and down in request pattern and we want our cosmosDb to scale according to number of request or memory usage. Through this approach RUs can be increased and decreased based on given counter to avoid 429 status code.

Consistency

Cosmos DB, a distributed database powerhouse, thrives on the trifecta of replication, low latency, and a spectrum of consistency levels—from the robust to the more relaxed.

In the consistency hierarchy, excluding the unwavering “strong” level, writes follow a fascinating journey. They echo into a minimum of 3 replicas within a 4-replica set in the local region, casting a local resilience spell. Beyond borders, this replication dance transcends regions with an asynchronous rhythm, ensuring a well-choreographed symphony of data distribution.

1. Strong
2. Bounded Staleness
3. Session
4. Consistent Prefix
5. Eventual

Strong

Strong consistency is most reliable consistency level. It means that reads are guaranteed to see the most recent write.

Bounded Staleness

Enter Bounded Staleness, the guardian of order in the Cosmos DB realm! Picture this: it ensures that the sequence of reads mirrors the dance of writes, holding true to the original choreography. However, here’s the twist—there might be a pause, a momentary delay of up to 100 versions of a record or 5 seconds, whichever is more humble.

Now, in the cosmic map of Cosmos DB, regions come into play. There’s the star region—the primary, the one bestowed with writing powers. And then, there are the supporting actors—the secondary regions, standing by as read-only spectators. The primary region graciously shares its data tale, replicating it to the secondary regions, creating a synchronized performance across the Cosmos DB stage.

Session

Session consistency—a favorite in the enterprise world, where precision matters. It’s the maestro orchestrating reads at the same time among clients within a shared session, ensuring harmony. Yet, it’s important to note that users in different sessions may read data in the same order, though a tad delayed.

This consistency dance promises to read your writes and lets writes gracefully follow reads. The catch? It assumes a solo writer session or the willingness to share the session token among multiple writers.

In the session tango, each write spins a new session token, a unique key to the data kingdom. The client clasps this token in its cache, presenting it with every read request. If the data in the first replica doesn’t waltz with the token, the client gracefully retries with a different partner—another replica in the same region. If needed, the client might even extend its dance card to extra regions until the data unveils itself for that token.

Think of the session token as a VIP pass—a minimum version barrier. Present an old one for a read, and the server gracefully escorts you to the latest data party, ensuring the freshest experience.

Consistent Prefix

This consistency works on batch operations only. This consistency makes sure that write operation on multiple documents that are part of a transaction are always visible together.

Eventual

This is weakest consistency level and does not guarantee data consistency or order.

Stored Procedure

Stored procedures in CosmosDB are like the scriptwriters of the database world, and they speak the language of JavaScript. However, they follow a strict director’s cut—no scene can run for more than 5 seconds, whether it’s played out from the Azure portal or the code backstage. This time limit is the guardian of SLA, ensuring a performance that keeps the audience engaged.

Now, to overcome this temporal challenge, enter the concept of continuation. It’s like hitting pause and then resuming the script from where it left off in the previous act. A clever workaround to keep the show running smoothly without breaching the Azure time constraints. Stay tuned for more insights into this cosmic continuation saga!

Benefits of Cosmos DB

Some key benefits are as below –

• CosmosDb provides SDK for various language like .Net, Java, Node.js and Python
• CosmosDb automatically indexes all data.
• Azure CosmosDb provides API guarentees 99.99% SLA for single region and 99.999% SLA for multi region database account.
• CosmosDb is a NO SQL database which store large amount of data without impacting performance.

For more posts like this

• Enhancing app security with Azure Managed Identities
• IL code performance of Generic List And Non Generic List
• How does a dictionary maintains data
• What is better between Enumerator or foreach
• How to access private member of class