Examkin

Soru

Zorluk: Çok zorHigh-Performing Database Solutions

An IoT telemetry platform receives status updates from 500,000500,000 devices, with each device sending an update every 1010 seconds. A solutions architect is designing an Amazon DynamoDB table to store these updates. The system must support a write volume of 50,00050,000 writes per second with sub-millisecond latency. The primary query pattern is to retrieve all status updates for a specific day, sorted by the recording timestamp, with a target latency of under 100100 milliseconds.

To meet these requirements, the architect initially designs the table with a partition key of `status_date` (formatted as `YYYY-MM-DD`) and a sort key of `timestamp#device_id`. During load testing, the application experiences write throttling and receives `ProvisionedThroughputExceededException` errors, even though the total provisioned Write Capacity Units (WCUs) are set high enough to handle the workload.

Which database design modification will resolve this bottleneck while meeting the performance and query requirements?

  1. Redesign the table to use `device_id` as the partition key and `timestamp` as the sort key. Create a Global Secondary Index (GSI) with a partition key of `status_date_shard` (combining the date with a calculated hash prefix between 00 and 4949) and a sort key of `timestamp`. Configure the application to query all 5050 GSI shards in parallel for a given date and merge the results.Cevap
  2. B
    Redesign the table to use `device_id` as the partition key and `timestamp` as the sort key. Create a Global Secondary Index (GSI) with a partition key of `status_date` and a sort key of `timestamp`. Configure the application to query the GSI to retrieve the daily data.
  3. C
    Enable Amazon DynamoDB Accelerator (DAX) for the table, and update the application to write all status updates through the DAX cluster using a write-through caching strategy.
  4. D
    Migrate the database to Amazon RDS for PostgreSQL. To distribute the write workload and prevent bottlenecks on the primary instance, configure the application to send write operations to the RDS Read Replicas, which will automatically sync and failover if the primary instance is overloaded.

Cevap

Redesign the table to use `device_id` as the partition key and `timestamp` as the sort key, and create a Global Secondary Index (GSI) with a partition key of `status_date_shard` (using a calculated hash prefix between 00 and 4949) and a sort key of `timestamp`, querying all 5050 shards in parallel.
The correct answer resolves the bottleneck by distributing base table writes using a high-cardinality partition key (`device_id`) and distributing GSI writes using a sharded partition key (`status_date_shard`). By splitting the GSI partition key into 5050 shards, the write rate to any single GSI partition is reduced to 1,0001,000 writes per second, which matches the physical partition throughput limit of DynamoDB. The application can retrieve all data for a specific day by running 5050 parallel queries and combining the results.

Adım Adım Çözüm

1
Analyze the write rate and partition limits.
The application requires 50,00050,000 writes per second. A single DynamoDB partition can support a maximum of 1,0001,000 Write Capacity Units (WCUs) per second. Using `status_date` (which is the same for all writes on a given day) as the partition key concentrates all 50,00050,000 writes on a single partition, exceeding the limit by 5050 times.
To understand the physical limits causing the ProvisionedThroughputExceededException.
2
Evaluate the base table partition key design.
Changing the base table partition key to `device_id` distributes the 50,00050,000 writes across 500,000500,000 unique partitions. This results in 0.10.1 writes per second per partition, which is well below the 1,0001,000 WCU per-partition limit.
To ensure the base table writes are highly distributed and do not cause throttling.
3
Evaluate the impact of the Global Secondary Index (GSI) partition key.
If a GSI is created with `status_date` as the partition key, all writes are copied to a single GSI partition. When a GSI partition is throttled, the throttling backpressures the base table, causing the write requests on the base table to fail.
To avoid introducing a downstream write bottleneck via the GSI.
4
Implement write sharding (synthetic keys) on the GSI.
By appending a calculated hash prefix or random suffix from 00 to 4949 to the `status_date`, the GSI partition key is split into 5050 distinct keys (e.g., `2026-07-14_0` to `2026-07-14_49`). The 50,00050,000 writes are evenly distributed, resulting in 1,0001,000 writes per second per shard, which is within the 1,0001,000 WCU partition limit.
To satisfy both the high-throughput write requirement and the ability to query all data for a specific day.

Anahtar Kavram

DynamoDB write sharding and partition hot-key mitigation for high-performing database designs.
Bu soruyu puanla

Konular

High-Performing Database Solutions

Bu konudan daha fazla soru