Examkin

Soru

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

A global car rental platform uses an Azure Cosmos DB Core (SQL) API container to store booking reservation documents. Each document contains a unique `bookingId` (GUID), `rentalLocationId` (e.g., `SFO`, `JFK`), `userId`, and a `bookingDate` (formatted as `YYYY-MM-DD`).

The platform has the following operational requirements:
- Throughput & Storage: The system processes millions of bookings per day. The database must scale horizontally without encountering partition size limitations or throughput bottlenecks (hot partitions).
- Transactional Scope: The system must run ACID transactions (via transactional batches or stored procedures) for booking updates that occur on the same day for a specific rental location.
- Read Patterns: A real-time operations dashboard frequently queries active bookings for a specific location on a given day.

Which two partitioning strategies or configurations should you implement to satisfy these requirements? (Select two.)

  1. Define a synthetic partition key by concatenating `rentalLocationId` and `bookingDate` (e.g., `SFO_2026-07-16`).Cevap
  2. Scope transactional batches to the synthetic partition key value representing the specific rental location and date.Cevap
  3. C
    Set the partition key to `rentalLocationId` to keep all booking records for a physical rental branch in a single logical partition.
  4. D
    Set the partition key to `bookingId` to ensure uniform distribution of writes across physical partitions.
  5. E
    Set the partition key to `bookingDate` to optimize daily dashboard queries.

Cevap

Implement a synthetic partition key combining the rental location ID and the booking date, and scope transactional batches to this key.
Defining a synthetic partition key that combines the rental location and booking date satisfies the ACID transactional requirement because Cosmos DB transactional operations are scoped to a single logical partition key value. This approach also limits the logical partition size by daily boundaries, preventing it from exceeding the 20 GB threshold, and supports the dashboard's query pattern without requiring expensive cross-partition scans.

Adım Adım Çözüm

1
Analyze transactional requirements.
Identified that multi-document transactions in Azure Cosmos DB require all target items to have the same partition key value.
This establishes the minimum partition key boundary, which must group documents by location and date.
2
Evaluate scale and logical partition limits.
Determined that partitioning by rental location ID alone will eventually exceed the 20 GB logical partition size limit, while partitioning by booking date alone creates a hot partition for writes on the current day.
Choosing a key with high cardinality and a time component prevents unbounded growth and evenly distributes write throughput.
3
Design a synthetic partition key.
Created a compound key by concatenating the location ID and the date (e.g., SFO_2026-07-16).
This synthetic key guarantees that transactions for a location on a specific day can execute in the same logical partition, daily data remains well below 20 GB, and dashboard queries are highly efficient single-partition reads.

Anahtar Kavram

Selecting and configuring synthetic partition keys in Azure Cosmos DB to satisfy transactional boundaries, size limits, and throughput optimization.
Bu soruyu puanla

Konular

Configure Partition Keys and Partitioning Strategies in Azure Cosmos DB

Bu konudan daha fazla soru