Soru

Zorluk: OrtaData Store Operations with Amazon DynamoDB

A developer is managing a high-throughput ticketing application where transaction records are stored in an Amazon DynamoDB table. The table uses EventId as the partition key and TransactionId as the sort key. During a flash sale for a highly anticipated concert, the application experiences a surge in write requests for that specific concert, resulting in ProvisionedThroughputExceededException errors. However, CloudWatch metrics indicate that the table's overall consumed write capacity is far below the total provisioned write capacity. Which approach should the developer take to resolve this throttling issue?

  1. A
    Replace the query operations with a parallel Scan operation and apply a FilterExpression on EventId to distribute the read and write load across all table partitions.
  2. Implement write sharding by appending a randomized suffix to the EventId partition key value, and adjust the query logic to aggregate results across these sharded partitions.Cevap
  3. C
    Increase the provisioned write capacity units (WCUs) of the table to accommodate the peak write volume during the flash sale.
  4. D
    Initialize the AWS SDK client by hardcoding IAM credentials with administrative access to bypass DynamoDB throughput limits.

Cevap

Implement write sharding by appending a randomized suffix to the EventId partition key value, and adjust the query logic to aggregate results across these sharded partitions.
The correct option is to implement write sharding by appending a randomized suffix to the partition key. Because the throttling is caused by a hot partition key (high volume of writes to a single EventId), distributing the writes across sharded keys (e.g., EventId_1, EventId_2) allows DynamoDB to utilize multiple physical partitions. The application must then query all sharded partition keys to retrieve the full dataset.

Adım Adım Çözüm

1
Analyze the exception and the CloudWatch metrics.
The ProvisionedThroughputExceededException occurs despite the overall consumed capacity being below the provisioned limit, indicating a partition-level hot key issue rather than a table-level capacity issue.
DynamoDB distributes table capacity across multiple physical partitions based on the partition key. A high concentration of requests to a single partition key (a hot partition key) will throttle that partition even if the table-level limit is not reached.
2
Evaluate the solutions to mitigate hot partition keys.
Adding a randomized suffix (sharding) to the partition key distributes the write load across multiple partition keys.
By appending a suffix such as a random integer between 11 and NN, the single hot key is split into NN distinct keys, dispersing the traffic across multiple physical partitions.
3
Determine the changes required in the read path.
Modify the query logic to retrieve and aggregate results from all NN sharded partition keys.
Since the data is now distributed across multiple partition keys, a single query on the original partition key will no longer return all results; queries must be run across all sharded variations.

Anahtar Kavram

Mitigating hot partition keys in DynamoDB using write sharding
Bu soruyu puanla