Examkin

Soru

Zorluk: OrtaConfigure Partition Keys and Partitioning Strategies in Azure Cosmos DB

You are designing an Azure Cosmos DB container for a smart home energy monitoring platform that receives real-time telemetry from 50,00050,000 active devices. The workload has the following characteristics:

* Write profile: High-volume write ingestion of hourly usage metrics (10,00010,000 writes/sec).
* Read profile: Frequent read queries searching for telemetry by device ID and a specific date range.
* Transactional boundary: The platform must run ACID transactions using transactional batches to calculate and update daily summary aggregates for a device on a specific day.
* Storage profile: Individual devices generate a high volume of data that must be retained indefinitely.

You need to configure the partitioning strategy to support the transactional requirements, avoid the hot partition problem, and prevent logical partitions from exceeding the 20 GB20\text{ GB} limit.

Which two strategies should you implement?

  1. Create a synthetic partition key by concatenating the device ID and the date (such as `deviceId_date`) for each telemetry record.Cevap
  2. Execute the transactional batches with the partition key value set to the concatenated device ID and date of the target day.Cevap
  3. C
    Use the device ID as the partition key and configure session consistency to guarantee multi-document transaction isolation across the container.
  4. D
    Use the date as the partition key to group all device telemetry for a single day into the same logical partition.

Cevap

Create a synthetic partition key by concatenating the device ID and the date (such as `deviceId_date`) and execute the transactional batches with the partition key value set to the concatenated device ID and date of the target day.
To support transactional batches, all documents in the transaction must share the same partition key value because transactions in Azure Cosmos DB are scoped to a single logical partition. Concatenating the device ID and the date (e.g., `deviceId_date`) forms a synthetic partition key that ensures all telemetry records for a specific device on a given day reside in the same logical partition, allowing transactional batches to succeed. Additionally, this synthetic key prevents logical partitions from exceeding the 20 GB20\text{ GB} limit over time by scoping the partition to a single day per device, and it distributes the write throughput (10,00010,000 writes/second) evenly across a high cardinality of partitions (different devices).

Adım Adım Çözüm

1
Analyze the transactional boundary and logical partition size limits.
Identify that transactions must be scoped to a single logical partition and that a single device's historical data will exceed the 20 GB20\text{ GB} limit over time if partitioned by device ID alone.
This establishes the need to partition by a combination of device and time to restrict partition growth.
2
Evaluate write throughput distribution to avoid hot partitions.
Determine that partitioning by date alone concentrates all 10,00010,000 writes/sec on one logical partition, leading to rate-limiting.
This rules out simple date-based partitioning due to throughput hotspots.
3
Design a synthetic partition key that satisfies both transaction boundaries and scaling.
Combine the device ID and date to form a synthetic key, and ensure transactional batches target this specific partition key value.
This keeps partitions small, distributes writes evenly, and permits transactional batches for the device-day aggregation.

Anahtar Kavram

Selecting a partition key that balances transactional scope, limits partition growth, and distributes throughput to prevent hot partitions.
Bu soruyu puanla

Konular

Configure Partition Keys and Partitioning Strategies in Azure Cosmos DB

Bu konudan daha fazla soru