Soru

Zorluk: OrtaHigh-Performing Database Solutions

An online auction application uses Amazon DynamoDB to store bids. The table uses AuctionDate (formatted as YYYY-MM-DD) as the partition key and BidTime as the sort key. During the final minutes of popular auctions, the application experiences write throttling and ProvisionedThroughputExceededException errors, even though the total write capacity is well below the table's provisioned limit. In addition, users experience high read latency when retrieving the current highest bid for an auction. Which two database configurations or architectural changes will resolve these performance issues?

  1. Redesign the table schema to use a high-cardinality partition key, such as AuctionID, to distribute write requests more evenly across multiple physical partitions.Cevap
  2. Deploy an Amazon DynamoDB Accelerator (DAX) cluster to cache read requests, reducing read latency for the highest bids to microseconds.Cevap
  3. C
    Keep the existing schema and switch the DynamoDB table to on-demand capacity mode to automatically scale throughput to resolve the hot partition throttling.
  4. D
    Configure an Amazon RDS Read Replica to handle the high volume of read queries and set up automatic failover to the replica if the primary database becomes throttled.

Cevap

Redesign the table schema to use a high-cardinality partition key like AuctionID to distribute writes, and deploy an Amazon DynamoDB Accelerator (DAX) cluster to cache reads.
The correct configurations are to redesign the schema to use a high-cardinality partition key (such as AuctionID) and to deploy Amazon DynamoDB Accelerator (DAX). Changing to a high-cardinality partition key ensures writes are evenly distributed across physical partitions, preventing hot partition throttling. DAX provides an in-memory cache that reduces read latency to microseconds and offloads read traffic from the partition.

Adım Adım Çözüm

1
Analyze the database schema and identify the cause of the write throttling.
The partition key AuctionDate is low-cardinality and causes all write operations on a given day to target the same physical partition, leading to hot partition throttling.
DynamoDB partitions have individual throughput limits (1,000 WCUs), which can be exceeded even if the table-level provisioned capacity is not fully utilized.
2
Choose a new partition key that distributes the workload evenly.
Using a high-cardinality attribute like AuctionID distributes concurrent bids across different partitions.
High-cardinality keys ensure that partition-level throughput limits are not breached during peak traffic.
3
Address the read latency requirement for retrieval of the highest bids.
Deploy DynamoDB Accelerator (DAX).
DAX provides microsecond latency for read operations by caching read requests, offloading the database table.

Anahtar Kavram

Designing high-performing DynamoDB architectures by using high-cardinality partition keys to prevent hot partitions, and utilizing DynamoDB Accelerator (DAX) for microsecond read latencies.
Bu soruyu puanla