The following is a sample of a document in orders. The orders container uses customerId as the partition key. You need to provide a report of the total items ordered per month by item type. The…

Question

Exhibit

Options

• AConfigure the report to query orders by using a SQL query.
• BConfigure the report to query a new aggregate container. Populate the aggregates by using the
• CConfigure the report to query orders by using a SQL query through a dedicated gateway.
• DConfigure the report to query a new aggregate container. Populate the aggregates by using SQL

• A
  6% (2)
• B
  80% (28)
• C
  11% (4)
• D
  3% (1)

Explanation

Running aggregation queries (total items per month by item type) directly against the raw 'orders' container requires scanning large volumes of documents across multiple partitions - especially since the partition key is 'customerId', not 'itemType' or 'date'. This is expensive in RU/s and slow. The optimal solution is to maintain a separate aggregate container pre-computed from the raw data. The Azure Cosmos DB change feed is ideal for populating this aggregate container in near real-time: every time an order document changes, a change feed processor updates the aggregate. When the report runs, it queries the small, pre-aggregated container, resulting in minimal RU consumption and maximum speed. Option D (SQL queries) cannot produce continuous, incremental aggregates the way the change feed can.

No community discussion yet for this question.