What's changed: Created DP-420 Chapter 4 (Domain 4: query optimization and indexing (indexing policy included/excluded paths, write-heavy vs read-heavy, composite index, range/spatial, integrated cache via dedicated gateway, RU cost via request charge/query metrics); change feed (Azure Functions trigger/SDK change feed processor with lease/change feed estimator backlog/denormalize update-referential enforcement-aggregation persistence-archiving)).
4.1Query optimization and indexing
Understand index tuning, calculating/retrieving query RU cost, the integrated cache, read-heavy vs write-heavy index strategy, composite indexes, and custom indexing policies.
Cosmos DB indexes all properties by default. Tuning the indexing policy to the workload is the core of optimizing query performance and RU cost.
4.1.1Index strategy and composite indexes
A custom indexing policy specifies included paths (to index) and excluded paths (to exclude). Write-heavy workloads exclude unneeded paths to lower index-update RU (fewer indexes = cheaper writes). Read-heavy workloads index the paths used to filter queries. A composite index optimizes ORDER BY on multiple properties and multi-filter queries (for queries a single index cannot serve). Use a spatial index for geospatial data and a range index for range/equality, by purpose.
4.1.2Understanding RU cost and the integrated cache
Get RU consumption of queries/point operations from response headers (x-ms-request-charge) or query metrics to find and optimize expensive queries. For very read-heavy, slowly-changing workloads, use the Cosmos DB integrated cache, which caches point reads and query results via a dedicated gateway to greatly reduce RU (accepting eventual freshness). For "read-heavy, lower RU," use the integrated cache; for "know a query’s cost," use request charge/query metrics.
Cues: "write-heavy → trim indexes (excluded paths)," "read-heavy → index filter paths." "ORDER BY on multiple properties / multi-filter" = composite index. "read-heavy, big RU cut" = integrated cache (via dedicated gateway). "know query cost" = request charge/query metrics.
Watch the mix-ups: (1) Integrated cache (RU cut for reads, dedicated gateway, results may be stale) vs indexing (query efficiency). (2) Full indexing on write-heavy wastes write RU—trim with excluded paths. (3) A composite index must match the query’s property order/direction. (4) Indexing-policy changes rebuild in the background.
4.1.3Section summary
- Tune the indexing policy—write-heavy trims via excluded paths; read-heavy indexes filter paths
- Composite index = optimize ORDER BY on multiple properties / multi-filter
- Integrated cache (dedicated gateway) greatly cuts read-heavy RU; gauge RU via request charge
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Writes are very heavy and you want to lower index-update cost for properties not used in queries. Best?
Q2. You want to optimize queries with ORDER BY on multiple properties or multiple filters. Best?
Q3. For a very read-heavy, slowly-changing workload, you want to greatly reduce RU. Best?
Q4. You want to know how much RU a specific query consumes. Best?
Q5. Which correctly distinguishes the integrated cache from indexing?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.