You are designing an Azure Cosmos DB container to store chat messages for a multi-tenant e… — Microsoft Azure Developer (AZ-204)

You are designing an Azure Cosmos DB container to store chat messages for a multi-tenant enterprise collaboration application. The application supports thousands of corporate tenants, each containing numerous distinct chat channels.

The workload has the following characteristics:
- Writes are heavy and occur continuously across all active channels.
- The most frequent query retrieves the history of a specific chat channel, sorted by timestamp.
- The application uses transactional batch operations to insert, update, or delete multiple messages within a single channel as an atomic unit.
- A single tenant's data can exceed $20\text{ GB}$ over time, whereas any individual channel's data is guaranteed to remain under $2\text{ GB}$ .

You need to select a partition key that ensures scalability, avoids hot partitions, and supports the transactional requirements.

Which partition key strategy should you implement?

A
Use the tenant ID as the partition key.
Create a synthetic partition key by combining the tenant ID and the channel ID.Cevap
C
Use the message ID as the partition key.
D
Use the sender ID as the partition key.

Cevap

Create a synthetic partition key by combining the tenant ID and the channel ID.

The correct strategy is to create a synthetic partition key by combining the tenant ID and the channel ID. In Azure Cosmos DB, transactional batches are constrained to a single logical partition, meaning all items in the transaction must share the same partition key value. Combining tenant ID and channel ID ensures that all messages in a specific channel are stored in the same partition, enabling atomic batch operations and efficient single-partition reads for channel history. Additionally, because any single channel's data is guaranteed to be under

2\text{ GB}

(well below the

20\text{ GB}

logical partition limit), this strategy avoids partition size issues and distributes the active write workload across many distinct partitions, preventing hot partitions.

Adım Adım Çözüm

Analyze the transactional boundary requirements of the application.

Cosmos DB transactions (like transactional batches or stored procedures) must occur within a single logical partition (items must share the same partition key value).

Since the application needs to run transactional batch operations on messages within a single channel, the partition key must encompass the channel identifier.

Analyze the partition size and cardinality constraints.

A single tenant's data can exceed the

20\text{ GB}

logical partition limit, while channel data is guaranteed to remain under

2\text{ GB}

. Using the tenant ID alone is invalid because it violates the partition size limit. Using a unique message ID or sender ID prevents transactional batches on channels.

We must choose a key that keeps a single channel's data in one partition while remaining under

20\text{ GB}

and avoiding hot partitions.

Synthesize a partition key to meet both criteria.

Combining the tenant ID and the channel ID (e.g., 'tenant123_channel456') satisfies all requirements.

This synthetic key groups channel messages into a single partition for transactions and efficient reads, keeps partitions below the

20\text{ GB}

limit, and distributes the workload across many partitions to prevent hot partitions.

Anahtar Kavram

Synthetic partition keys and transaction boundaries in Azure Cosmos DB

Soru

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Konular

Bu konudan daha fazla soru