DP-420 · Question #15
You have a container in an Azure Cosmos DB for NoSQL account. The container stores telemetry data from IoT devices. The container uses telemetryId as the partition key and has a throughput of 1,000…
The correct answer is C. Move the data to a new container that has a partition key of deviceId. The root cause is a hot partition. All 5,000 devices submit data using the same 'telemetryId' value as the partition key, which forces all writes and reads into a single logical partition, wasting the remaining throughput across other partitions. The analytics application reads…
Question
You have a container in an Azure Cosmos DB for NoSQL account. The container stores telemetry data from IoT devices. The container uses telemetryId as the partition key and has a throughput of 1,000 request units per second (RU/s). Approximately 5,000 IoT devices submit data every five minutes by using the same telemetryId value. You have an application that performs analytics on the data and frequently reads telemetry data for a single IoT device to perform trend analysis. The following is a sample of a document in the container. You need to reduce the amount of request units (RUs) consumed by the analytics application. What should you do?
Exhibit
Options
- ADecrease the offerThroughput value for the container.
- BIncrease the offerThroughput value for the container.
- CMove the data to a new container that has a partition key of deviceId.
- DMove the data to a new container that uses a partition key of date.
How the community answered
(48 responses)- A6% (3)
- B8% (4)
- C71% (34)
- D15% (7)
Explanation
The root cause is a hot partition. All 5,000 devices submit data using the same 'telemetryId' value as the partition key, which forces all writes and reads into a single logical partition, wasting the remaining throughput across other partitions. The analytics application reads data for a single IoT device, which is identified by 'deviceId'. By moving data to a new container with 'deviceId' as the partition key, each device's data is stored in its own logical partition. Reads for trend analysis on a single device become single-partition (in-partition) queries, which are far cheaper in RU/s than cross-partition queries. Changing the offer throughput (options A or B) does not fix the partition design problem, and using 'date' (option D) does not align with the analytics access pattern of querying by device.
Topics
Community Discussion
No community discussion yet for this question.