Examkin

Question

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

You are designing an Azure Cosmos DB Core (SQL) API container for a health technology platform that tracks daily patient health metrics during clinical trials.

Each document in the container contains the following fields:
- `tenantId`: A unique identifier for the pharmaceutical sponsor
- `trialId`: A unique identifier for the clinical trial
- `patientId`: A unique identifier for the patient
- `recordDate`: The date of the measurement in `YYYY-MM-DD` format
- `heartRate`: The patient's heart rate value

The database solution must meet the following requirements:
- Write Ingestion: High-frequency writes from thousands of patient devices uploading metrics concurrently. Write operations for a single patient's daily metrics must be executed as a transactional batch to ensure atomicity.
- Read Queries: Clinical researchers frequently query all metrics for a specific clinical trial (`trialId`) within a date range of 33 to 77 days.
- Scalability: Individual logical partitions must not exceed the 20 GB20\text{ GB} storage limit, and write throughput (RUs) must be distributed evenly to avoid rate-limiting.

Which partition key strategy should you implement?

  1. A
    Set the partition key to the `patientId` field.
  2. B
    Set the partition key to the `trialId` field.
  3. Create a synthetic partition key by concatenating the `trialId` and `recordDate` fields.Answer
  4. D
    Set the partition key to the `tenantId` field.

Answer

Create a synthetic partition key by concatenating the trialId and recordDate fields.
Creating a synthetic partition key by combining the trial identifier and the record date restricts the size of each logical partition to a single day's worth of data for a specific trial. This ensures the 20 GB20\text{ GB} logical partition limit is not exceeded, even for large trials. Since a patient's daily metrics share the same trial identifier and date, they will also share the same partition key value, enabling transactional batch operations. Furthermore, queries from researchers looking for a trial's data over a 33 to 77 day period will target only a small, specific set of logical partitions (one for each day), preventing expensive container-wide fan-out queries.

Step-by-Step Solution

1
Analyze the transactional batch boundary requirement.
Cosmos DB transactional batches require all operations in the batch to share the same partition key. Since the requirement is to commit a single patient's daily metrics atomically, the partition key must remain constant for a given patient on a specific day.
Transactional batches cannot span multiple logical partitions.
2
Evaluate the scalability and storage constraints.
Partitioning by tenantId or trialId would aggregate too much data into single logical partitions, quickly exceeding the 20 GB20\text{ GB} logical partition limit and creating hot partitions. Partitioning by patientId or a synthetic key like trialId_recordDate avoids this by limiting the size of each logical partition.
Logical partitions in Azure Cosmos DB have a hard limit of 20 GB20\text{ GB} and a maximum throughput capacity.
3
Analyze the query pattern trade-offs.
Partitioning by patientId forces trial-wide queries to perform a costly container-wide fan-out. A synthetic key combining trialId and recordDate (trialId_recordDate) allows trial queries for a date range of 33 to 77 days to target only 33 to 77 specific logical partitions, optimizing read operations while maintaining write distribution.
Restricting query scope to a known subset of partition keys minimizes Request Unit (RU) consumption.

Key Concept

Selecting a partition key or designing a synthetic partition key to meet transactional, scalability, and query performance requirements in Azure Cosmos DB.
Rate this question

Topics

Configure Partition Keys and Partitioning Strategies in Azure Cosmos DB

More questions from this topic