Post
Ask Question

Useful Consistency Model Of Azure Cosmos DB

Introduction

In this article, I am going to explain the different types of consistency models, provided by cosmos DB. After finishing this article you can choose the appropriate consistency model for your requirements. Before reading this article, please read basics of Cosmos DB and how global distribution works for better understanding.

What is Data Consistency

Consistency in general means to get similar returns for each run of an action. Let me explain with a scenario: In an online store, the user's address may be part of their signup information, but it also needs to appear on delivery information. If there is a mismatch between signup information and delivery information, it is called data inconsistency.

Inconsistency data leads to duplication or loss of data, due to which people will lose faith in prediction. A report based on inconsistency data makes things worse.

Consistency Scope

The scale of consistency has a scope limited to a single user request. A write request corresponds to any transaction of an insert, replace or delete. A read and write request both are limited to the scope of a single user request. The request is required to read larger result-sets or travel to multiple partitions. However, because of the limitation of the scope, each request is confined to a single page and served in a single partition.

Cosmos DB Consistency Models

There is always a trade-off between availability and consistency in a distributed system. We can expect consistency in RDBMS. But a distributed system chooses availability over consistency. To support consistency, Cosmos DB provides five different type of consistency models. Based on business requirements, the consistency model needs to be chosen. Let me explain one by one:

Strong

  • Strong consistency is more focused on data consistency, it’s like a SQL commit statement. So, the data latency is high and the performance is too low.
  • Strong consistency is scoped to only one region: explained in the image below.
  • A read is always acknowledged by the majority read quorum, a client can never see an uncommitted or partial write and is always guaranteed to read the latest acknowledged write.
  • The cost of reading operation is higher in Strong consistency than the session and eventual ones. Here the cost is calculated based on the RU (Request Unit).

    Azure 

Bounded-staleness

  • With the bounded-staleness consistency model, we can set periods to replica data to read. So, there is a lag between writing and reading database’s data.
  • We can choose bounded staleness in two ways -- the number of version items and time interval.
  • If we set time to Zero then it acts as strong consistency.
  • We can configure Bounded staleness in more than one region.
  • We can choose Bounded staleness where we need consistency and availability to have the same priority
Azure 

Session

  • Session consistency is the default consistency: It is also popular because of its consistency and better throughput.
  • Write region user can read the latest data but read region users can read only lag data.
  • The client can change the default consistency on a per-request basis level.

Consistency Prefix

  • With Consistency prefix, we can maintain a sequence to replicate the data to replicas.
  • If writes were performed in the order, A, B, C then a client sees either, AA,B or,A,B,C but never out of order like A,C or B,A,C

Eventual

  • Eventual consistency performance is good because it doesn’t wait for data commit to the reading time.
  • It is just opposed to strong consistency. The problem is because of irregular data consistency.
  • Eventual consistency is the weakest consistency but it has the highest latency.
  • The cost of a read operation in Eventual consistency is low.

How to Configure Default Consistency

As I explained, a user can set any consistency level as a default based on their need. Here see how to set default consistency in the portal.

  1. Open Azure portal using portal.azure.com, search cosmos DB.
  2. Select Azure cosmos DB, click your already-created cosmos DB service.
  3. In feature menu, click Default consistency
  4. It will show five types of consistency levels and save.
Azure 

How Consistency Levels Support Query

Based on our selected consistency, the selectws query will perform the required action. The consistency level for a query is the same as the consistency level for reads. If we select strong consistency query response is high because strong consistency is more focused on consistency of data and ensures the consistency. If we select Eventual query performance is high but it is based on the availability of data.

Basically, queries perform based on indexing. Cosmos DB automatically sets index; also, we can configure certain collection to update their index in a slow manner. Lazy index boosts out write performance where we need bulk insert but primary data center read is heavy.


Similar Articles