High Availability – Nonrelational Databases in Azure

High Availability

High availability is a foundational component of Azure Cosmos DB. Global distribution in Azure Cosmos DB allows users to easily replicate data to multiple regions by associating one or more additional regions to an Azure Cosmos DB account. Adding new regions can be done through the Azure Portal or programmatically.

New regions can be configured to be read-only or to allow both reads and writes. Read-only workloads such as those produced from reporting applications can be offloaded to the read-only replicas, resulting in better performance for these workloads and those performing write operations. It is recommended to configure at least two different regions to allow writes in case of regional failure. This guarantees that if the primary region goes down, then write operations will automatically be routed to another region.

In addition to global distribution, Azure Cosmos DB maintains four replicas of the data within each region. For example, if you define an Azure Cosmos DB account to use two regions, then eight copies of the data will be maintained. Data resiliency within regions can also be guaranteed by enabling availability zone support. Availability zones ensure that replicas are placed in different zones of a given region, protecting data from in-region zonal failures.

Consistency Levels

Distributed databases such as Azure Cosmos DB that manage multiple write copies across different regions requires a trade-off between data consistency, availability, and performance. Using a strong consistency model results in the most updated data being read by applications but can result in slower performance since data has to replicate and be committed to each associated region before an application is allowed to read data. While eventual consistency offers better performance, applications reading data are at risk of returning dirty data.

Azure Cosmos DB offers five well-defined consistency levels to balance the trade-off between consistency, availability, and performance. The following list describes each consistency level, starting with the strictest level of consistency and finishing with the most relaxed:

• Strong—This consistency level guarantees that reads return the most recent version of data, regardless of what region an application is reading data from. There is a possibility of slower performance as application connections may experience delays until transactions are committed across every associated region.
• Bounded staleness—With this consistency level, applications reading data from the same region that it was written to use strong consistency. For applications reading data from regions outside of where data was written, there is a set “staleness window” for data. This means that data is committed asynchronously to other associated regions in the Azure Cosmos DB account. The staleness window can be configured one of two ways:
  • The number of versions of a record
  • A set time interval between writes Whenever either of these two limits is reached, connections are paused, and data is committed to the outside regions. Bounded staleness is a good choice for applications that require low write latency and guaranteed local consistency.
• Session—This is the most widely used consistency level for single region and globally distributed accounts. It grants a session token to the application writing data and guarantees that it and any other application sharing the same session token see the most recent version of data. All other reads use eventual consistency.
• Consistent prefix—Data is eventually replicated across regions but this level does not provide any guarantees on how long it will take for data to be replicated. However, it does guarantee that applications reading data will read data in order. For example, if an application writes records 100, 101, and 102 to a database in that order, then an application reading the data will see either 100, [100, 101], [101, 102] or [100, 101, 102], but never out-of-order combinations like [100, 102].
• Eventual—Much like the consistent prefix consistency level, eventual consistency guarantees that data will eventually be replicated across regions but does not provide any guarantees on how long it will take for data to be replicated. There is also no guarantee that data will not be replicated out of order. While it is the most performant consistency level in terms of read and write latency, it is the least likely to guarantee consistency.

Session consistency is the default consistency level for Azure Cosmos DB. You can change the consistency to be more consistent or more performant with a sliding scale in the Azure Portal or with a deployment script.

Request Units

As with any PaaS offering in Azure, Azure Cosmos DB abstracts compute resources from the end users. Instead, resources such as CPU, IOPS, and memory are bundled into units of measure called Request Units.

Request Units (RUs) represent the throughput required to read and write data in Azure Cosmos DB. One general rule of thumb is that the cost to read and write a 1 KB item is approximately 1 RU and 5 RUs respectively. This is true regardless of what type of Azure Cosmos DB API you are interacting with. Of course, the number of RUs that are required for a given query are going to vary based on the volume of data read or written, how well the data is indexed, the consistency model choice, and the complexity of the query. More information on RU considerations can be found at https://docs.microsoft.com/en-us/azure/cosmos-db/request-units#request-unit-considerations.