Question

Difficulty: MediumConfigure Partition Keys and Partitioning Strategies in Azure Cosmos DB

A public transit agency is designing an Azure Cosmos DB for NoSQL database to store real-time telemetry from a fleet of 5,000 buses. The system ingests 10 million location updates daily. The database must optimize for high-throughput write ingestions while ensuring fleet managers can perform ACID-compliant transactional batch updates to modify the status of a specific bus on a given calendar day. Using the bus ID alone as the partition key would optimize reads for individual buses but will eventually exceed the 20 GB logical partition storage limit due to historical accumulation. Which two of the following design decisions should you make to satisfy these requirements?

  1. Configure a synthetic partition key by concatenating the bus ID and the date portion of the timestamp (for example, busID_YYYYMMDD) to define the partition key for the container.Answer
  2. Execute the status updates using the TransactionalBatch class in the SDK, ensuring all operations in the batch target the same synthetic partition key value.Answer
  3. C
    Use the bus ID as the container partition key and rely on Cosmos DB to automatically split the logical partition when the historical data size exceeds 20 GB.
  4. D
    Set the database consistency level to Session to guarantee ACID transactional boundaries across multiple independent client sessions without sharing session tokens.

Answer

To satisfy these requirements, you must configure a synthetic partition key by concatenating the bus ID and the date portion of the timestamp (for example, busID_YYYYMMDD) to define the partition key, and execute the status updates using the TransactionalBatch class in the SDK, ensuring all operations in the batch target the same synthetic partition key value.
Concatenating the bus ID with the date creates a synthetic partition key that guarantees a high cardinality distribution while keeping the size of each logical partition well under the 20 GB storage limit, as data is divided into daily chunks. Since all status documents for a specific bus on a given day share this key, they can be updated atomically using the TransactionalBatch class in the SDK.

Step-by-Step Solution

1
Evaluate the partition size constraints and query scope.
Using the bus ID alone as the partition key will lead to an unbounded partition size over time, which will eventually exceed the 20 GB logical partition limit. A synthetic partition key combining the bus ID and date is necessary to keep partition sizes within bounds.
Azure Cosmos DB restricts each logical partition to a maximum size of 20 GB.
2
Determine the transactional scope requirements.
ACID transactions using TransactionalBatch require all items in the batch to share the same partition key value.
TransactionalBatch transactions cannot span multiple logical partitions.
3
Evaluate the feasibility of consistency levels for transactional boundaries.
Consistency levels like Session do not govern transaction boundaries across independent client sessions.
Session consistency only guarantees read-your-writes behavior for the client executing the writes.

Key Concept

Synthetic partition keys and TransactionalBatch boundaries in Azure Cosmos DB
Rate this question