In my first article in Azure Cosmos DB, we talked about What is Cosmos DB and How to provisions it, then in the Second article we talked about Partitioning Architecture in Azure Cosmos DB, then in third Article we talked about Azure Cosmos DB Global data distribution Architecture, today we will complete our series to talk about Consistency Architecture in Azure Cosmos DB For more information about my Azure articles check this link, Keep Following to learn More about Azure and Cosmos DB
Introduction
Microsoft Azure Cosmos DB Provide 5 level of Consistency (Strong, Bounded staleness, Session, Consistency prefix, Eventual) Before Explaining What is Consistency, Why I should take care about Consistency, Which Consistency is best for my APP design before all of that let us talk first about CAP Theorem
CAP Theorem
When we talk about managing big data and increasing in the process, most of us consider the common solution to Scale-up vertically by adding more machines to support this process increases, but with advanced parallel processing, we should expand horizontally. And this working with, CAP Theorem is a concept for a Database system that we can have 2 of 3 levels Consistency, Availability, and Partition Tolerance
One of the common Statements about CAP Theorem by Eric Brewer (Of three properties of shared-data systems (Consistency, Availability, and tolerance to network Partitions) only two can be achieved at any given moment in time) it is impossible to provide all three.
- Consistency: Every write will match Every read; mean at any time we need to read we will get the data based on the last right.
- Availability: Mean Every time we do a request or do a read, we should get a response
- Partitions Tolerance: Mean In case if you have delayed response or delayed massage or massages dropped the system still able to continues to operate
For more information about CAP Theorem Check this Wikipedia
Azure Cosmos DB Consistency
AS I mentioned Microsoft Azure Cosmos DB Provide 5 level of Consistency (Strong, Bounded staleness, Session, Consistency prefix, Eventual) based on our Choice we affect on the cost and the availability of the system, most interested is most of the database system not provide this 5 levels of Consistency only Cosmos DB can provide it.
- What is Strong Consistency is: Any Update or write on DB level will be replicated immediately to the other nodes and regions so Every write will match Every read. And this is the highest Consistency but it’s the lowest performance because on every change the APP will wait till the DB commit this transaction update or change on all nodes and Regions As you can see below data are matched on all regions on the same time So this will be a high cost. For Example, who can use this Consistency level (financial Sectors banking)
- What is Bounded staleness Consistency is: is lower level than Strong Consistency level,it is the same concept of the Strong Consistency but with lag, Yes lag we can configure a specified lag based on configured maximum lag time or the maximum operation for example 10 second so once the changes happened on the master node, the new changes will be available on the other nodes or regions after 10 seconds. Like some Dashboard updates, read the changes after some of time-based on the configuration. So Bounded Staleness Consistency Is not real-time, but it’s pretty close to real-time, and this will give us better performance than strong consistency and this again depend on the lag configuration on Azure Cosmos DB
- What is Session Consistency is: Session Consistency is the default Consistency for all Cosmos DB, the reason for that because it is reduced the cost by half compared by Strong Consistency and it will be a good mix between performance and availability, and the Session Consistency that and read and write for certain session will be Consistency but the other sessions will not be Consistency. And this configuration can be done by defining a unique session key and any read or write used this session key will be Consistency other sessions used another Session key will not be Consistency
- What is Consistent prefix Consistency is: Dirty read Yes you never read the new updates until it is replicated so for example APP inserted new record as record one, then updated the record to record two during the update the Record one Replicated and you try to select the data you will get Record one only until the record two replicated you will get record two and you will not see record one. I think it is something like with (Nolock) in SQL Server, So at this level, we have some delay but it is a fast delay but at the same time we don’t have real-time read of data.
- What is Eventual Consistency is: Eventual is weakest consistency level in the 5 levels and it is the best choice if you are targeting the cost (the most cost-effective) because in this level the database not Consuming more resources) So Eventual Consistency Mean that Eventual you will get the latest updates but this process will take some times and this level is very helpful when you have reported but it is not necessary to read real data on time So Eventual Consistency is the better Choice from Performance (extremely high performance) Because of the write operation will be very fast because the APP will not wait for the DB to replicate this data. And it is the better choice because of Cost (it’s extremely low cost) The system will be the highest availability, you will have written process on time, and the read is gonna take a while to catch up.
Resources
Keep Following
Cloud Tech Website blog survey
IF you found this blog is helpful and sharing useful content please take few second to do rate the website blog from here
DB Cloud TECH 