Cosmos DB consistency models – SQL on the edge episode 16

May 3, 2018

Tags: Oracle, Oracle Enterprise Manager, Technical Track, Cdb, Oms

We're back with a new video blog to discuss yet another interesting facet of Cosmos DB! For those who are not familiar with the service, Cosmos DB is Microsoft Azure's NoSQL Database as a Service offering. Cosmos DB has many interesting properties including native geo-replication, multi-model API support and multiple consistency models. This time we are going to focus on this last property.

The consistency dilemma

NoSQL databases popularized the term of 'eventual consistency' as opposed to the usual 'strong consistency' that is more commonly used on relational database systems. Eventual consistency was seen as a reasonable trade-off on distributed databases in exchange of easier and linear scalability. The main trade-off is summed up by this question: do I want the most truthful data I can get or do I want the data as fast as possible even if it's not the latest? In a single data center or close geographic proximity this is usually not a large trade-off, since modern connections can have multiple nodes sync and converge on the same value in a matter of milliseconds. However, as we move towards build global "planet-scale" databases, it becomes more interesting to consider consistency models live "in-between" the full strong guarantee and the very loose "eventual consistency".

Cosmos DB consistency models

Because Cosmos DB was built with geographical replication as a core feature, the Microsoft team decided to implement multiple consistency models, that could provide more controlled behaviors and trade-offs for developers than simply "eventual consistency". Let's see all the consistency options provided by Cosmos DB:

Strong: Cosmos will provide the latest value of the record.
Bounded staleness: Cosmos will provide a value up to a certain specified lag of time or versions.
Session: Cosmos will allow a session to always read it's own writes, for other sessions it provides consistent prefix.
Consistent prefix: Cosmos will provide monotonic reads and always respect ordering.
Eventual: no guarantee other than if a value stops being updated, eventually all copies will be the same.

According to Microsoft, the majority of their Cosmos databases are set to Session consistency by default. The cool thing is that you don't have to stick to the default, you can override this setting at the client and event at the individual query level. There is one caveat though, you can only override towards a "looser" consistency model, not to a stronger one. For example, if you select Session as your default then you can override it to Consistent Prefix or Eventual but not to Bounded Staleness.

Impact on performance

The goal of manipulating these consistency models is to get the best performance for your application by having the lowest tolerable latency for a particular operation. Cosmos DB also introduces another incentive: some consistency models consume more Request Units than others. Request Units are Cosmos DB throughput reservations and doing Strong or Bounded Staleness operations consumes double the amount of the other consistency levels. This means that if you can live with the guarantees provided by Session, Consistent Prefix or Eventual, then you will be able to push twice the amount of operations per second through your Cosmos DB container.

Future development

At this point in time there are a couple of limitations that I'm hopeful the Microsoft team will resolve in the near future. For example, strong consistency is not allowed on a multi-region database. As well, I hope that Microsoft will develop global consistency on a full multi-master model to enable true global read-write anywhere databases.

Demo time!

Alright, let's jump into the demo now, and let's check out the impact of the different consistency models on the Request Unit consumption of a Cosmos DB workload. Enjoy!