24 Cosmos DB Interview Questions (EXPLAINED) For Azure Developers

For every container, a partition key must be pre-defined. The partition key is used to divide a container into many subsets, AKA logical partitions, and each logical partition is used to store items with the same partition key values.

• A container can have an unlimited number of logical partitions
• Each logical partition has a storage limit of 20G

Partitioning denotes how our data gets distributed. Mainly there are two types of partitions:

• Logical Partition is a virtual bucket where the data gets wrapped around based on the partition key we select.
• Physical partitions are the physical servers available in order to store our documents in azure cosmos db.

Azure Cosmos DB normalizes the cost of all database operations using Request Units (or RUs, for short). The request unit is a performance currency abstracting the system resources such as CPU, IOPS, and memory that are required to perform the database operations supported by Azure Cosmos DB.

The cost to do a point read (fetching a single item by its ID and partition key value) for a 1-KB item is one Request Unit (or one RU).

Partition key is not unique for each document as the primary key is unique for each record in relational databases. The partition key is unique for each logical partition. Accordingly, all the documents in a logical partition will have the same partition key.

Yes, you can. In some scenarios, you may want to mix different document types in the same collection; this is usually the case when you want multiple, related documents to sit in the same partition. An example can be

• customers and customer orders and partition container by customerId
• books and book reviews in the same container and partition it by bookId

Also, transactions are supported per partition key, which means you can insert, update, and delete different types of documents within that partition key, inside the transaction.

In such a situation, you usually want to add to your documents a field that identifies their type in order to differentiate them.

A point read is a key/value lookup on a single item ID and partition key.

When you read one item in Cosmos DB using the item’s partition key value and ID value, it is considered a point-read and is also the fastest and cheapest read request in Cosmos DB, since all the request need is to look up one specific item in one specific logical partition in the container.

ToDoActivity toDoActivity = await this.container.ReadItemAsync<ToDoActivity>(“id”, new PartitionKey(“partitionKey”));

CosmosDB only supports transactions within the same partition.

This means that you cannot have cross containers transactions and you also cannot have transactions between two documents with different partition key values.

If you need something to execute transactionally in Cosmos DB then you need to make sure it all lives in the same container and the same partition key value. In that case, you may want to mix different document types in the same collection; this is usually the case when you want multiple, related documents (like customers and customer orders) to sit in the same partition (customerId).

If a query has filters on two or more properties, it may be helpful to create a composite index for these properties.

This query will be more efficient, taking less time and consuming fewer RUs, if it's able to leverage a composite index on (name ASC, age ASC).

{  
    "automatic":true,
    "indexingMode":"Consistent",
    "includedPaths":[  
        {  
            "path":"/*"
        }
    ],
    "excludedPaths":[],
    "compositeIndexes":[  
        [  
            {  
                "path":"/name",
                "order":"ascending"
            },
            {  
                "path":"/age",
                "order":"ascending"
            }
        ]
    ]
}

For all containers, your partition key should:

• Be a property that has a value, which doesn't change. If a property is your partition key, you can't update that property's value.
• Should only contain String values - or numbers should ideally be converted into a String
• Have a high cardinality. In other words, the property should have a wide range of possible values.
• Spread request unit (RU) consumption and data storage evenly across all logical partitions
• Have values that are no larger than 2048 bytes typically, or 101 bytes if large partition keys aren't enabled.

For most containers, the above criteria are all you need to consider when picking a partition key.

Having the same partition key in multiple containers is an anti-pattern. Generally speaking, when designing for Cosmos DB, an objective is to store data in the same container when it shares the same partition key and is frequently accessed together.

Exceptions to this tend to include multi-tenant scenarios when trying to avoid noisy neighbor problems.

The type of Azure Cosmos DB account you're using determines the way consumed RUs get charged. There are three modes in which you can create an account:

1. Provisioned throughput mode: In this mode, you assign the number of RUs for your application on a per-second basis in increments of 100 RUs per second. To scale the provisioned throughput for your application, you can increase or decrease the number of RUs at any time in increments or decrements of 100 RUs

   You can assign throughput at two distinct granularities:

   • Containers
   • Databases

2. Serverless mode: In this mode, you don't have to assign any throughput when creating resources in your Azure Cosmos DB account. At the end of your billing period, you get billed for the number of Request Units consumed by your database operations.

3. Autoscale mode: In this mode, you can automatically and instantly scale the throughput (RU/s) of your database or container based on its usage. This scaling operation doesn't affect the availability, latency, throughput, or performance of the workload.

Azure Cosmos DB currently supports three types of indexes:

• Range Index. Range indexes can be used on scalar values (string or number). The default indexing policy for newly created containers enforces range indexes for any string or number.
• Spatial index. Spatial indices enable efficient queries on geospatial objects such as - points, lines, polygons, and multipolygon.
• Composite indexes. Composite indexes increase the efficiency when you're performing operations on multiple fields.

When you run a cross-partition query on a container, you're running one query per physical partition. Cross-partition queries (per physical partitions) are expensive in terms of RUs (cost) and latency. You are charged a minimum of about 2.5 RU's every time you check a physical partition's index for results, even if no items in the physical partition match the query's filter.

Even if we define our partition key considering all the factors we may run into cross-partition queries if data grows beyond a certain size spanning across multiple physical partitions. If we set a partition key that results in big partitions we need to be careful that all logical partitions should have unique division of data. Meaning a few logical partitions should not contain the bulk of data while other partitions sit mostly empty(hot partitions).

Starting from Azure Cosmos DB SDKs 1.9.0 Azure Cosmos DB is able to parallelize cross-partition queries, and query latency generally scales well as the system adds physical partitions. However, RUs charge increases significantly as the total number of physical partitions increases.

By default, Azure Cosmos DB automatically indexes every property for all items in your container without having to define any schema or configure secondary indexes.

Every time an item is stored in a container, its content is projected as a JSON document, then converted into a tree representation. This conversion means that every property of that item gets represented as a node in a tree.

This helps the high throughput of these queries in most cases but not all the query is covered by the default index settings.

Consider the document:

 {
 	"divisionid": "div001",
 	"divisioninfo": {
 		"membercount": 5,
 		"name": "engineering"
 	},
 	"divisionloc": "Japan"
 }

From it the 3 indexes will be created:

• /divisionid,
• /divisioninfo/membercount,
• /divisioninfo/name.

When you search documents with these properties, these indexes are used and improve the query performance.

You can form a partition key by concatenating multiple property values into a single artificial (synthetic) partitionKey property. These keys are referred to as synthetic keys.

{
  "deviceId": "abc-123",
  "date": 2018,
  "partitionKey": "abc-123-2018" // <-- synthetic partition key
}

A logical partition consists of a set of items that have the same partition key. Selecting a partition key with a wide range of possible values ensures that the container is able to scale.

Cosmos DB is designed to scale horizontally based on the distribution of data between Physical Partitions (PP) (think of it as separately deployable underlaying self-sufficient nodes) and logical partition - a bucket of documents with the same characteristic (partition key) which is supposed to be stored fully on the same PP. So LP can't have part of the data on PP1 and another on PP2.

A logical partition also defines the scope of database transactions. You can update items within a logical partition by using a transaction with snapshot isolation.

• Physical partitions are partitions that our logical partitions map to. This sits within a replica set and each replica set hosts an instance of the Cosmos DB Engine. This ensures that the data stored within each physical partition is durable, consistent, and highly available. Unlike logical partitions, physical partitions are an internal implementation of the system and Azure Cosmos DB entirely manages physical partitions.

• Logical partitions are partitions that consist of a set of items that have the same partition key. Say if all our items have a “Category” property, we can use that as the partition key. Say if we have values for “Sport”, “Tech” and “Financial” categories, these group of items will form their own distinct logical partitions. Internally, one or more logical partitions are mapped to a single physical partition.

Unique keys add a layer of data integrity to an Azure Cosmos DB container. With unique keys, you make sure that one or more values within a logical partition are unique.

After you create a container with a unique key policy, the creation of a new or an update of an existing item resulting in a duplicate within a logical partition is prevented, as specified by the unique key constraint. The partition key combined with the unique key guarantees the uniqueness of an item within the scope of the container.

...
"uniqueKeyPolicy": {
    "uniqueKeys": [
      {
        "paths": [
          "/name",
          "/country"
        ]
      },
      {
        "paths": [
          "/users/title"
        ]
      }
    ]
...

You’ll have to check for conflict exceptions in your code. If you’re violating the unique key policy then a Microsoft.Azure.Documents.DocumentClientException is thrown.