Examkin

Soru

Zorluk: ZorAzure Cosmos DB and NoSQL Solutions

You are designing the data storage architecture for a global multiplayer online game. The game requires a database to store player session state and real-time match telemetry.

The database tier must meet the following requirements:
- Support a write-heavy workload with an 80:2080:20 write-to-read ratio.
- Provide sub-10 ms10\text{ ms} write latency for session updates.
- Achieve a recovery point objective (RPO=0RPO = 0) guaranteeing zero data loss in the event of a regional datacenter outage.
- Store cold telemetry data older than 3030 days in Azure Blob Storage, ensuring the archived data also survives a regional datacenter outage.
- Secure client-side telemetry uploads to the archive storage using Shared Access Signatures (SAS) that can be immediately revoked if client credentials are compromised.

You have the following data fields for partitioning the database:
- `gameRegion` (55 distinct values)
- `tenantId` (1212 distinct values)
- `playerId` (millions of unique values, uniformly distributed)
- `sessionType` (44 distinct values)

Which architecture should you recommend?

  1. A
    Partition the Cosmos DB container using gameRegion. Configure the Cosmos DB account to use Strong consistency with a secondary read region. Configure the archive storage account with Geo-redundant storage (GRS). Secure client-side uploads by generating Shared Access Signatures (SAS) associated with a Stored Access Policy.
  2. Partition the Cosmos DB container using playerId. Configure the Cosmos DB account to use Strong consistency with a secondary read region. Configure the archive storage account with Geo-redundant storage (GRS). Secure client-side uploads by generating Shared Access Signatures (SAS) associated with a Stored Access Policy.Cevap
  3. C
    Partition the Cosmos DB container using playerId. Configure the Cosmos DB account to use Session consistency with a secondary read region. Configure the archive storage account with Locally redundant storage (LRS). Secure client-side uploads by generating Shared Access Signatures (SAS) associated with a Stored Access Policy.
  4. D
    Partition the Cosmos DB container using playerId. Configure the Cosmos DB account to use Strong consistency with a secondary read region. Configure the archive storage account with Geo-redundant storage (GRS). Secure client-side uploads by generating ad-hoc SAS tokens with a one-year lifetime directly signed by the storage account master key.

Cevap

Partition the Cosmos DB container using playerId, configure Strong consistency, use Geo-redundant storage (GRS) for blob archives, and secure client-side uploads with SAS tokens associated with a Stored Access Policy.
The correct design partitions the Cosmos DB container using a high-cardinality key like playerId to ensure even distribution of writes and reads, preventing hot partitions. To achieve zero data loss (RPO=0RPO = 0) in a regional disaster, the Cosmos DB account must use Strong consistency. For the archive Blob Storage, Geo-redundant storage (GRS) ensures survival during a regional disaster by replicating data to a secondary region. Finally, generating Shared Access Signatures (SAS) associated with a Stored Access Policy allows the tokens to be revoked instantly by modifying or deleting the policy, meeting the security requirement.

Adım Adım Çözüm

1
Select the database partition key that prevents hot partitions under high write load.
Choose playerId as the partition key.
Since the workload is write-heavy and playerId has millions of unique, uniformly distributed values, it provides high cardinality, ensuring that writes are distributed evenly across physical partitions and preventing hot partition bottlenecks.
2
Configure the consistency level to meet the zero data loss requirement.
Select Strong consistency with a secondary geo-replicated region.
To guarantee a recovery point objective of zero (RPO=0RPO = 0) in the event of a regional outage, write replication must be synchronous, which is only guaranteed by Strong consistency.
3
Select the appropriate redundancy tier for the archive storage.
Choose Geo-redundant storage (GRS) for the Blob Storage account.
GRS replicates data to a secondary region geographically distant from the primary region, ensuring the archived data survives a regional datacenter disaster.
4
Design the client-side token authorization and revocation mechanism.
Implement SAS tokens associated with a Stored Access Policy.
Ad-hoc SAS tokens cannot be revoked individually without rotating the storage account's master keys. Associating SAS tokens with a Stored Access Policy allows instantaneous revocation by simply deleting or updating the policy on the container.

Anahtar Kavram

Azure Cosmos DB partitioning, consistency levels, and Azure Storage redundancy and security configuration.
Bu soruyu puanla

Konular

Azure Cosmos DB and NoSQL Solutions

Bu konudan daha fazla soru