Azure Documentation

Microsoft Azure Services

Cosmos DB Performance Tips

This document provides key performance optimization strategies for Azure Cosmos DB to ensure your applications are fast, scalable, and cost-effective.

1. Optimize Request Units (RUs)

Understand RU Consumption: Every operation in Cosmos DB consumes Request Units (RUs). Larger items, more complex queries, and higher consistency levels consume more RUs.

Efficient Queries: Write queries that select only the necessary fields and filter data effectively. Use stored procedures and User-Defined Functions (UDFs) for server-side logic to reduce client-side overhead.

Partitioning: Choose a good partition key that distributes request and storage volume evenly across partitions. Avoid hot partitions.

Batching: For multiple small operations, consider batching them into a single request to reduce the number of network round trips and RU consumption.

2. Improve Query Performance

Index Optimization: Cosmos DB automatically indexes data. Understand the indexing policy and customize it if necessary (e.g., include/exclude paths, indexing modes) to reduce index storage and improve query speed.

Avoid `SELECT *`: Always specify the fields you need in your queries. `SELECT *` reads all fields and increases RU consumption.

Use `TOP` and `ORDER BY` Wisely: Queries with `ORDER BY` on non-indexed properties or across many partitions can be expensive. Ensure partition keys are used in `WHERE` clauses for efficient sorting.

Leverage `CONTINUE` for large results: For queries returning a large number of results, use the `CONTINUE` keyword to process results in batches, reducing latency for the initial response.

Server-side programming: Use stored procedures and triggers to execute complex logic directly on the server, minimizing network latency and RU overhead.

3. Efficient Data Modeling

Denormalization: For read-heavy workloads, consider denormalizing your data to reduce the need for joins and improve read performance. Embed related data within a single document.

Document Size: While Cosmos DB supports large documents (up to 2MB), very large documents can increase latency and RU consumption. Aim for reasonably sized documents.

Partition Key Choice: Select a partition key with high cardinality and even distribution of request and data. Avoid partition keys that lead to "hot partitions".

4. Connection Management

Use the SDK: Leverage the official Cosmos DB SDKs for your chosen language. They handle connection pooling, retries, and protocol optimizations.

Gateway vs. Direct Mode: Understand the differences. Direct mode generally offers lower latency but may require more management. Gateway mode is simpler to use.

Avoid Frequent Client Instantiation: Create and reuse a single instance of the Cosmos DB client for the lifetime of your application to benefit from connection pooling.

5. Throughput Provisioning

Autoscale Throughput: For variable workloads, use autoscale throughput to automatically scale RUs based on demand, optimizing cost and performance.

Manual Throughput: For predictable workloads, manual throughput offers the most cost-effective solution. Monitor RU usage and adjust as needed.

Shared vs. Dedicated Throughput: Understand when to use shared throughput for multiple databases/containers versus dedicated throughput for critical ones.

6. Monitoring and Diagnostics

Azure Monitor: Utilize Azure Monitor to track key metrics like RU consumption, latency, throttled requests, and storage usage.

Diagnostic Logs: Enable diagnostic logs for detailed operational insights and troubleshooting.

Application Insights: Integrate Application Insights for end-to-end monitoring of your application, including Cosmos DB interactions.

7. Caching Strategies

Client-side Caching: Implement caching mechanisms within your application for frequently accessed, infrequently changing data.

Leverage `If-None-Match` Header: For read operations, use the `If-None-Match` header with the `_etag` of the previously retrieved document. If the document hasn't changed, Cosmos DB will return a `304 Not Modified` status, saving RUs.