Azure Cosmos DB

What it is

Azure Cosmos DB is a fully managed, globally distributed NoSQL database. It is built for applications that need very fast responses, flexible data shapes and the ability to scale out, with data replicated close to users around the world.

It stores data as items in containers, and the API you choose decides the data model you use.

How it works

Use cases

Cosmos DB suits workloads where speed, scale and flexibility matter more than joins across many tables.

• Web, mobile and gaming back ends with many users in many regions.
• Internet of Things telemetry and device data.
• Retail catalogues where each product has different attributes.
• Personalisation and real time recommendations.
• Social networks and relationship data, using the graph API.

Items, containers and request units

You create an account, then databases, then containers. The items in a container are your data, such as JSON documents. Every property is indexed automatically by default, so queries are fast without index design.

The cost of every operation is measured in request units, or RUs. An RU is a blended measure of the CPU, memory and input and output that a read, write or query uses. A small read costs few RUs, and a large query costs more.

Throughput and capacity modes

Partitioning

Cosmos DB scales by splitting data into partitions. You choose a partition key, a property such as customerId. Items that share a partition key value belong to the same logical partition. Azure places logical partitions on physical partitions and manages that for you, so one physical partition can host several logical ones. A good partition key spreads data and requests evenly.

Global distribution and consistency

You can add Azure regions to an account with a few clicks. Data is replicated automatically, and an account can accept writes in more than one region. Reads are served from the region nearest the user, which keeps latency low.

When data is copied between regions, you decide how fresh a read must be. Cosmos DB offers five consistency levels, from strongest to weakest.

Stronger consistency costs more latency across regions. Weaker consistency is faster.

The APIs

The API decides the data model and the way you talk to the database.

A worked scenario

A mobile game has players in Europe, Asia and North America, and each player profile is a small JSON document with different fields. The team picks the NoSQL API, uses playerId as the partition key, and replicates to all three regions so each player reads from a nearby copy. They keep the default session consistency, because a player must always see their own latest score. Because traffic peaks in the evening, they use autoscale throughput.

An item and a query

An item in the NoSQL API is a JSON document. The container's partition key could be /city.

{
  "id": "p-1021",
  "city": "Lisbon",
  "name": "Ana Silva",
  "tags": ["gold", "newsletter"]
}

You read it with a query that looks like SQL, where c stands for each item in the container.

SELECT c.name FROM c WHERE c.city = "Lisbon"

A query that includes the partition key value goes to one partition and costs fewer request units than one that must look in all of them.

Matching consistency to the need

Availability and failover

Cosmos DB replicates data inside a region and across the regions you add. If a region becomes unavailable, service managed failover can move the write role to another region automatically, so the application keeps working. Adding availability zones within a region gives extra protection against a datacenter failure. Multi region writes let users write to the nearest copy, with conflict resolution handled by the service.

Cosmos DB compared with Azure SQL Database