Examkin

Soru

Zorluk: ZorHigh-Performing Database Solutions

An inventory management application for a retail chain stores real-time stock levels in an Amazon DynamoDB table. The table schema uses `StoreID` as the partition key and `ItemSKU` as the sort key. During a promotional event, a few flagship stores experience a sudden, massive surge in sales, resulting in write requests to those specific store partition keys exceeding 2,5002,500 writes per second. The application encounters `ProvisionedThroughputExceededException` errors, although the table's total provisioned write capacity is largely underutilized. Which strategy should a solutions architect implement to resolve this database performance bottleneck with minimal impact on latency?

  1. A
    Enable DynamoDB Auto Scaling for the table and switch the capacity mode to On-Demand to automatically provision additional capacity during spikes.
  2. Append a calculated hash or a random integer suffix to the StoreID partition key during write operations, and update the application query logic to read across the sharded partition keys.Cevap
  3. C
    Recreate the table using ItemSKU as the partition key, and create a Global Secondary Index (GSI) with StoreID as the partition key to support store-specific queries.
  4. D
    Migrate the database to an Amazon Aurora PostgreSQL Multi-AZ cluster, and configure the application to distribute the write load across the reader endpoints.

Cevap

Adjust the write path to append a calculated hash or a random integer suffix to the partition key (write sharding), and query across the sharded keys to distribute the load.
The correct option is to implement write sharding by appending a suffix to the partition key. A single partition key in DynamoDB can only support up to 1,0001,000 WCUs per second. By appending a suffix (e.g., `StoreID_1`, `StoreID_2`), the writes for a single store are distributed across different physical partitions, resolving the hot partition throttling.

Adım Adım Çözüm

1
Analyze the cause of the performance degradation.
Throttling occurs because writes to a single partition key value (a specific flagship `StoreID`) exceed 2,5002,500 writes per second, which violates DynamoDB's physical limit of 1,0001,000 Write Capacity Units (WCUs) per second per partition.
Even if the overall table has sufficient capacity, a single hot partition key cannot exceed the single-partition limit.
2
Evaluate the impact of Global Secondary Indexes (GSIs).
Moving the hot key to a GSI does not solve the issue, as GSI writes will still be throttled and cause backpressure on the base table.
DynamoDB tables require successful GSI replication to avoid throttling the base table writes.
3
Evaluate capacity mode adjustments.
Switching to On-Demand capacity or enabling Auto Scaling increases total table limits but does not lift the physical single-partition throughput limit.
The partition-level capacity limit is a physical architectural boundary in DynamoDB.
4
Formulate a sharding strategy.
Add a suffix (e.g., `StoreID_1` to `StoreID_N`) to the partition key during writes to distribute the data across multiple partitions, and query across all suffixes.
This spreads the write workload of a single store across multiple partitions, allowing throughput to scale linearly.

Anahtar Kavram

DynamoDB partition design and write sharding to overcome partition limits.
Tahmini Süre:2m 0s
Bu soruyu puanla

Konular

High-Performing Database Solutions

Bu konudan daha fazla soru