Examkin

Soru

Zorluk: OrtaSet Consistency Levels for Azure Cosmos DB

An operations monitoring application uses an Azure Cosmos DB API for NoSQL account with a single write region in East US and read replicas in West US and East Asia. The database account is currently configured with the default Session consistency level. The development team needs to optimize the application for both performance and read guarantees.

Which two statements regarding Azure Cosmos DB consistency level configurations and their trade-offs are correct? (Select two.)

  1. Switching the default consistency level from Session to Strong will double the Request Unit (RU) cost for read operations because reads require a quorum check across replica regions to ensure the latest version of data is returned.Cevap
  2. When using the default Session consistency, if a web app writes a tracking record using one client instance and subsequently reads it using a different client instance, the read may return stale data unless the application explicitly passes the session token from the write operation to the read client.Cevap
  3. C
    Configuring Bounded Staleness consistency will double the Request Unit (RU) cost for write operations because the database must block write acknowledgments until they are replicated to a majority of secondary regions.
  4. D
    To guarantee that a customer's browser session always reads its own writes across multiple scale-out web server instances, you should change the default consistency level to Consistent Prefix, which automatically scopes replication boundaries to individual client threads.
  5. E
    If reads under Session consistency frequently return stale data due to partition skew, you should change the container's partition key to a low-cardinality attribute such as the status code to force synchronous replication across physical partitions.

Cevap

Switching to Strong consistency doubles read RU costs due to replica quorum requirements, and when using Session consistency across different client instances, the session token must be explicitly passed to guarantee read-your-own-writes.
The correct statements are that switching the default consistency to Strong will double the RU cost for reads due to quorum reads, and that Session consistency requires passing the session token to guarantee read-your-own-writes when reads and writes occur on separate client instances.

Adım Adım Çözüm

1
Analyze the read RU cost implications of changing the default consistency level.
Strong and Bounded Staleness consistency levels perform quorum reads, which cost twice as much in RUs as reads performed under Session, Consistent Prefix, or Eventual consistency.
This evaluates the trade-offs of switching from Session to Strong consistency.
2
Evaluate how Session consistency behaves across multiple independent client instances.
The Cosmos DB SDK automatically manages the session token at the client instance level. If different instances are used for reads and writes, the session token must be manually extracted and passed to maintain the read-your-own-writes guarantee.
This verifies the scoping and requirements of Session consistency in scale-out application scenarios.
3
Verify write cost and replication mechanics under Bounded Staleness and Consistent Prefix.
Writes cost the same across all consistency levels, and Consistent Prefix only guarantees ordering, not immediate read-your-own-writes. Partition keys must also maintain high cardinality to prevent hot partitions.
This rules out the incorrect options.

Anahtar Kavram

Azure Cosmos DB consistency levels and their performance, cost, and session scoping behavior.
Bu soruyu puanla

Konular

Set Consistency Levels for Azure Cosmos DB

Bu konudan daha fazla soru