Examkin

Soru

Zorluk: ZorResolving DynamoDB Throttling and Key Distribution Issues

A health tracking application named FitPulse records real-time heart rate data from millions of user devices. The application writes telemetry records directly to an Amazon DynamoDB table configured with provisioned write capacity. The table uses `DeviceType` (with values such as `Watch`, `Band`, or `Ring`) as the partition key and `Timestamp` as the sort key. During a global fitness event, write activity surges, and the application receives a high volume of `ProvisionedThroughputExceededException` errors. CloudWatch metrics show that the total consumed Write Capacity Units (WCUs) are well below the table's total provisioned WCU limit. Which of the following is the most effective solution to resolve this throttling issue and ensure even write distribution across the partitions?

  1. A
    Modify the application to retrieve records using parallel Scan operations on the DynamoDB table to bypass partition throughput limits.
  2. Redesign the partition key schema to use a high-cardinality attribute such as `DeviceId` and, if write volumes for a single device are extremely high, append a random or calculated numeric suffix to the partition key.Cevap
  3. C
    Increase the visibility timeout of the Amazon SQS queue that buffers incoming writes to 1212 hours to allow the DynamoDB table more time to process the backlog.
  4. D
    Hardcode the IAM User's access key and secret access key in the application's SDK client initialization code to reduce credential retrieval latency during write surges.

Cevap

Redesign the partition key schema to use a high-cardinality attribute such as `DeviceId` and, if write volumes for a single device are extremely high, append a random or calculated numeric suffix to the partition key.
Redesigning the partition key schema to use a high-cardinality attribute distributes the database write load across many partitions. In Amazon DynamoDB, provisioned capacity is distributed across physical partitions. If a low-cardinality attribute like `DeviceType` is used as the partition key, all writes for a given device type will target the same partition, causing a hot partition that exceeds the per-partition limit (10001000 WCUs) even if the table-level provisioned capacity is not fully consumed. Appending a random or calculated numeric suffix to the partition key (write sharding) further distributes writes across multiple partitions when a single entity's write rate exceeds the per-partition limit.

Adım Adım Çözüm

1
Analyze the CloudWatch metrics showing that total consumed throughput is below the table's total provisioned limits while `ProvisionedThroughputExceededException` errors are occurring.
Identify that the issue is a hot partition rather than an overall table capacity exhaustion.
Provisioned capacity in DynamoDB is divided across physical partitions, meaning a single partition can exceed its individual limit (10001000 WCUs or 30003000 RCUs) even if the table-wide threshold is not breached.
2
Evaluate the primary key design (`DeviceType` as partition key and `Timestamp` as sort key).
Recognize that `DeviceType` has low cardinality (few distinct values like `Watch`, `Band`, or `Ring`), causing heavy write volumes to target only a few partitions.
Low-cardinality keys lead to uneven data distribution and partition overloading.
3
Redesign the schema to use a high-cardinality attribute like `DeviceId` as the partition key, and apply write sharding if necessary.
Ensure even key distribution across DynamoDB's physical partitions.
Using a high-cardinality key like `DeviceId` combined with a random or calculated suffix spreads the write requests uniformly across all physical partitions, resolving the hot partition throttling.

Anahtar Kavram

Resolving DynamoDB partition throttling by designing a high-cardinality partition key schema to avoid hot partitions.
Tahmini Süre:2m 0s
Bu soruyu puanla

Konular

Resolving DynamoDB Throttling and Key Distribution Issues