Question

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

A company is developing a centralized logging service that stores application log messages in Azure Cosmos DB.

The workload has the following characteristics:
- Throughput Profile: High-volume write ingestion of up to 20,00020,000 writes per second, with occasional read queries by administrators.
- Transactional Boundaries: There are no transactional requirements across different log entries; each log document is written independently.
- Read/Write Trade-off: The partitioning strategy must be optimized to maximize write throughput and avoid bottlenecks, even if it requires read queries for a specific day to span multiple partitions.

The log documents contain a `logDate` property (formatted as `YYYY-MM-DD`) and a `serviceName` property. Using `logDate` directly as the partition key would direct all writes for the current day to a single partition, causing a hot partition.

You need to select a partitioning strategy that distributes the write throughput evenly.

Which strategy should you use?

  1. Create a synthetic partition key by appending a random integer suffix to the `logDate` value.Answer
  2. B
    Use the `serviceName` property as the partition key.
  3. C
    Use the unmodified `logDate` property as the partition key.
  4. D
    Set the partition key to the client's Cosmos DB session consistency token.

Answer

Create a synthetic partition key by appending a random integer suffix to the `logDate` value.
Appending a random integer suffix to the `logDate` creates a synthetic partition key with higher cardinality. This distributes the write operations of a single day across multiple logical partitions (e.g., from suffix 11 to 1010), preventing any single partition from being overwhelmed by the high write rate of 20,00020,000 operations per second.

Step-by-Step Solution

1
Analyze the workload characteristics and requirements.
High-volume write throughput (20,00020,000 writes/sec) with no transactional boundaries between separate logs.
Understanding boundaries and throughput patterns guides partition key selection.
2
Identify potential hot partitions.
Using `logDate` causes a hot partition because all logs on a given day target the same key. Using `serviceName` creates a hot partition if a few services dominate logs.
A partition key must distribute write traffic evenly across logical partitions.
3
Determine the optimal partitioning strategy.
Append a random suffix to the `logDate` to create a synthetic key, distributing write traffic across multiple logical partitions.
A synthetic partition key with random suffixes distributes high write traffic evenly, satisfying the write-optimized requirement.

Key Concept

Avoiding hot partitions in high-write Azure Cosmos DB containers using synthetic partition keys.

Alternative Method

Instead of appending a random suffix, a pre-calculated hash of another property (like a transaction ID) could be appended to the date to create a deterministic synthetic partition key, which helps when reading specific records if the suffix can be calculated.
Estimated Time:1m 30s
Rate this question