Choosing the right Consistency Level in Azure Cosmos DB
In this tutorial, we will learn and understand the process of choosing the right consistency level in Azure DB.
However, the Distributed databases relying on replication for high availability, low latency, or both, makes the fundamental tradeoff between the read consistency vs. availability, latency, and throughput. For this, Azure Cosmos DB allows developers to choose among the five well-defined consistency models. This includes strong, bounded staleness, session, consistent prefix, and eventual. And, each of these consistency models is intuitive and can be useful for specific real-world scenarios. Further, they provide precise availability and performance tradeoffs that have the support of comprehensive SLAs. Moreover, you can configure a default consistency at the account level and override it at the request level. The simple considerations will help you make the right choice in many common scenarios.
SQL API and Table API
If your application creates using SQL API or Table API then check the below points:
- Firstly, or many real-world scenarios, session consistency is optimal and it’s the recommended option.
- Secondly, if your application requires strong consistency, then it is recommended that you use a bounded staleness consistency level.
- Thirdly, if you need stricter consistency guarantees than the ones session consistency provides and single-digit-millisecond latency for writes. Then, the recommendation if for using a confine staleness consistency level.
- Fourthly, if your application needs eventual consistency. Then, the recommendation is of using a consistent prefix consistency level.
- Next, if you require less strict consistency guarantees than the ones session consistency provides. Then, the recommendation is for using a consistent prefix consistency level.
- After that, if you need the highest availability and the lowest latency, then use eventual consistency level.
- Lastly, if you require even higher data durability without sacrificing performance, then you can create a custom consistency level at the application layer.
Consistency guarantees in practice
You should know that in practice, you may often get stronger consistency guarantees. However, this is for a read operation corresponding to the freshness and ordering of the database state that you request. As read-consistency ties to the ordering and propagation of the write/update operations.
- Firstly, when the level of consistency is set to bounded staleness, then Cosmos DB guarantees that the clients always read the value of a previous write, with a lag bounded by the staleness window.
- Secondly, when the level is set to strong, then the staleness window is equivalent to zero. Then, the clients guarantee to read the latest committed value of the write operation.
- After that, for the remaining three consistency levels, the staleness window is largely dependent on your workload. For example, if there are no write operations available on the database. Then, a read operation with an eventual, session or consistent prefix consistency levels is likely to yield the same results as a read operation with a strong consistency level.
However, if your Azure Cosmos account configuration is with a consistency level other than the strong consistency. Then, you can find out the probability that your clients may get strong and consistent reads for your workloads by looking at the Probabilistically Bounded Staleness (PBS) metric.
Probabilistic bounded staleness displays how eventual is your eventual consistency. However, this metric offers an insight into how often you can get a stronger consistency than the consistency level that you currently configure on your Azure Cosmos account. That is to say, you can view the probability of getting strongly consistent reads for a combination of write and read regions.
Reference: Microsoft Documentation