Soru

Zorluk: Çok zorHigh-Performing Database Solutions

A solutions architect is designing a high-performance real-time bidding application. The application requires microsecond read latency when retrieving active user profiles (uniquely identified by UUID v4) and must support up to 2,000,0002,000,000 write operations per second during peak events. Additionally, the system must run hourly aggregation queries based on campaign ID. A small subset of popular campaigns receives more than 95%95\% of all bids, creating a highly skewed write pattern. Which combination of database configurations will meet these requirements while preventing write throttling on the primary table and its indexes? (Select TWO.)

  1. Deploy an Amazon DynamoDB Accelerator (DAX) cluster to cache read requests for user profiles, reducing retrieval latency to the microsecond level.Cevap
  2. Implement write sharding on the Global Secondary Index (GSI) by appending a randomized partition key suffix to the campaign ID attribute before writing to the table.Cevap
  3. C
    Create a Global Secondary Index (GSI) using the raw campaign ID as the partition key to query aggregation data directly.
  4. D
    Configure Amazon RDS for PostgreSQL with read replicas, and configure the application to automatically promote a read replica to the primary instance during peak write latency.
  5. E
    Configure the DynamoDB table using Provisioned Capacity Mode with static read and write capacity units to handle the sudden, highly irregular peaks in campaign write volume.

Cevap

Deploy an Amazon DynamoDB Accelerator (DAX) cluster to cache read requests, and implement write sharding on the Global Secondary Index (GSI) by appending a randomized partition key suffix to the campaign ID attribute.
Deploying Amazon DynamoDB Accelerator (DAX) caches frequent read queries for user profiles, reducing retrieval latency from milliseconds to microseconds. Implementing write sharding by appending a randomized suffix to the campaign ID attribute distributes the highly skewed write volume across multiple partition keys on the Global Secondary Index (GSI). This prevents a few popular campaign partition keys from becoming hot partitions, avoiding write throttling on both the GSI and the base table.

Adım Adım Çözüm

1
Address the microsecond read latency requirement for user profiles.
Identify that standard DynamoDB read latency is in the single-digit millisecond range. To achieve microsecond latency, an in-memory cache is required. Amazon DynamoDB Accelerator (DAX) is the optimal choice as it integrates natively with DynamoDB APIs.
DAX caches reads, offloading the database and reducing read latency to microseconds without requiring code changes to manage cache invalidation.
2
Analyze the write pattern and identify potential bottlenecks.
The application requires up to 2,000,0002,000,000 writes per second, and 95%95\% of these writes are concentrated on a few popular campaign IDs.
This highly skewed distribution will lead to write throttling due to hot partitions if campaign ID is used directly as a partition key.
3
Select the indexing strategy for hourly aggregations.
A Global Secondary Index (GSI) is needed to query data by campaign ID. However, writing directly to a GSI with campaign ID as the partition key would create hot partitions, causing write operations to fail.
GSI writes are throttled if a single GSI partition is overloaded, which backpressures and throttles writes on the base table.
4
Mitigate the hot partition key issue on the index.
Implement write sharding by appending a random integer suffix (e.g., from a range of 1 to N) to the campaign ID attribute before writing to the table.
This distributes the writes across multiple physical partitions for the index, allowing the database to scale horizontally and support the heavy write load without throttling.

Anahtar Kavram

Mitigating DynamoDB hot partitions through write sharding on partition keys with highly skewed data distributions, and using DAX for microsecond read caching.
Tahmini Süre:3m 0s
Bu soruyu puanla