Soru

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

An agricultural technology system uses an Azure Cosmos DB Core (SQL) API container to store telemetry data from 10,00010,000 active IoT soil sensors. The system has the following workload characteristics:

- Sensor telemetry is ingested continuously with high-throughput writes.
- Queries frequently retrieve the telemetry history for a specific sensor over a single day to display daily graphs.
- The container uses stored procedures to perform atomic batch transactions that update daily average readings, requiring all telemetry items for a specific sensor on a specific day to reside in the same logical partition.
- Using either the sensor identifier (`SensorId`) or the date (`ReadingDate`) alone as the partition key would lead to hot partitions.

Which partition key strategy should you implement to satisfy these requirements while optimizing throughput and avoiding hot partitions?

  1. Create a synthetic partition key by concatenating the sensor identifier and the reading date.Cevap
  2. B
    Configure the partition key as the reading date and append a random suffix to the value.
  3. C
    Define a composite partition key using the sensor identifier and the sensor status.
  4. D
    Configure the partition key as the sensor identifier and enforce Session consistency for all client sessions.

Cevap

Create a synthetic partition key by concatenating the sensor identifier and the reading date.
Creating a synthetic partition key by concatenating the sensor identifier and the reading date ensures that writes are distributed across a wide space (10,00010,000 unique combinations per day), preventing hot partition issues. Concurrently, it groups all telemetry items for a specific sensor on a specific day under one partition key, satisfying the single-partition constraint required for stored procedure execution.

Adım Adım Çözüm

1
Identify the transactional boundaries.
Determine that stored procedures are scoped to a single logical partition key, requiring daily sensor telemetry to share the same partition key value.
Stored procedures in Azure Cosmos DB cannot run across multiple logical partitions.
2
Evaluate partitioning cardinality for ingestion scaling.
Recognize that partitioning by date alone causes a hot write partition on the current day, and partitioning by sensor identifier alone concentrates all history for a sensor in one partition.
High write volumes must be distributed across multiple physical partitions to avoid rate limiting.
3
Select a synthetic key strategy.
Combine the sensor identifier and date (e.g., SensorId_ReadingDate) to create a synthetic key.
This guarantees that all records for a specific sensor on a specific day are colocated, while spreading writes across up to 10,000 active partitions daily.

Anahtar Kavram

Azure Cosmos DB synthetic partition keys and transactional scoping
Tahmini Süre:1m 30s
Bu soruyu puanla