Question

Difficulty: MediumHigh-Performing Database Solutions

A solutions architect is designing a database schema for a smart utility grid system that collects hourly electricity usage readings from millions of smart meters. The data is written to an Amazon DynamoDB table. The table is currently configured with a partition key of `ReadingDate` (formatted as `YYYY-MM-DD`) and a sort key of `MeterID#Timestamp` to support daily regional reporting queries. During peak reporting hours, the application experiences write throttling and receives `ProvisionedThroughputExceededException` errors, even though the total consumed Write Capacity Units (WCUs) are far below the table's provisioned limit. Which database design modification will resolve this write throttling and optimize performance?

  1. Redesign the DynamoDB table to use `MeterID` as the partition key and a composite sort key of `ReadingDate#Timestamp`, and create a Global Secondary Index (GSI) with `ReadingDate` as the partition key to support the daily reporting queries.Answer
  2. B
    Change the partition key to `Timestamp` (formatted as `YYYYMMDDHHMMSS`) to ensure that write operations are spread sequentially and chronologically across the table partitions.
  3. C
    Retain `ReadingDate` as the partition key, switch the table's capacity mode to Provisioned with Auto Scaling enabled, and configure a high maximum Write Capacity Units (WCU) threshold.
  4. D
    Migrate the smart meter database to Amazon RDS for PostgreSQL and configure multiple Read Replicas in different Availability Zones to handle the high write throughput and act as failover targets.

Answer

Redesign the DynamoDB table to use MeterID as the partition key and a composite sort key of ReadingDate#Timestamp, and create a Global Secondary Index (GSI) with ReadingDate as the partition key to support the daily reporting queries.
Redesigning the table to use a high-cardinality attribute like the meter identifier as the partition key distributes the write workload evenly across all partitions. By pairing it with a composite sort key containing the date and timestamp, and setting up a global secondary index with the date as the partition key, the application can distribute writes to avoid throttling while still enabling efficient daily reporting queries.

Step-by-Step Solution

1
Analyze the cause of the ProvisionedThroughputExceededException.
Identify that using ReadingDate (formatted as YYYY-MM-DD) as the partition key results in all incoming writes for a specific day targeting the same partition key value, creating a hot partition.
DynamoDB partitions data based on the partition key value. When millions of smart meters write data simultaneously with the same ReadingDate value, they all target the same partition.
2
Select a partition key with high cardinality to distribute writes.
Choose MeterID as the partition key because it has millions of unique values, allowing DynamoDB to distribute write operations evenly across multiple partitions.
Distributing writes across many partition keys prevents any single partition from exceeding the physical limit of 1,0001,000 Write Capacity Units (WCUs) per partition.
3
Maintain support for regional daily reporting queries.
Combine ReadingDate and Timestamp into a composite sort key (ReadingDate#Timestamp) and create a Global Secondary Index (GSI) with ReadingDate as the partition key.
This allows the application to perform query operations on ReadingDate to retrieve all readings for a specific day, fulfilling the daily reporting requirements.

Key Concept

DynamoDB partition key design and hot partition prevention
Estimated Time:2m 0s
Rate this question