Question

Difficulty: MediumData Store Operations with Amazon DynamoDB

A developer is designing the data tier for a mobile multiplayer game. Player match logs are stored in an Amazon DynamoDB table with `PlayerID` as the partition key and `MatchID` as the sort key. The table contains millions of records. The game client needs to perform two operations:

1. Retrieve all matches played by a specific player within the last 77 days.
2. Retrieve all matches across the entire game where a player scored more than 10,00010,000 points.

Which TWO strategies should the developer implement to support these access patterns with the lowest read latency and minimum consumption of Read Capacity Units (RCUs)?

  1. Create a Global Secondary Index (GSI) with `PlayerID` as the partition key and `MatchTimestamp` as the sort key, and query the GSI to retrieve the player's recent matches.Answer
  2. Implement a sparse Global Secondary Index (GSI) by writing a `HighScoreThreshold` attribute only when a score exceeds 10,00010,000, and query the GSI to retrieve the high-scoring matches.Answer
  3. C
    Perform a `Scan` operation on the base table with a `FilterExpression` on `MatchTimestamp` to retrieve the player's recent matches.
  4. D
    Perform a `Scan` operation on the base table with a `FilterExpression` on `Score` to identify matches exceeding 10,00010,000 points.
  5. E
    Initialize the DynamoDB client in the application code by hardcoding IAM User credentials to authorize the queries.

Answer

The developer should create a Global Secondary Index (GSI) with PlayerID as the partition key and MatchTimestamp as the sort key to retrieve a player's recent matches. Additionally, they should implement a sparse GSI by writing a HighScoreThreshold attribute only when a score exceeds 10,000, and query this GSI for high-scoring matches.
Querying a Global Secondary Index (GSI) configured with PlayerID as the partition key and MatchTimestamp as the sort key allows the application to perform a highly efficient query to retrieve recent matches for a specific player. Additionally, creating a sparse GSI by conditionally writing a HighScoreThreshold attribute only when a score exceeds 10,000 enables the application to query only the high-scoring matches, bypassing the need to perform a costly scan of the entire table.

Step-by-Step Solution

1
Analyze the access pattern for retrieving matches for a specific player within a 77-day window.
Identify that the base table only supports querying by PlayerID and MatchID. Filtering by MatchTimestamp on the base table requires a Scan or a Query with a FilterExpression, both of which read extra data and waste RCU.
To retrieve only the relevant matches directly, we must place MatchTimestamp as the sort key in a secondary index.
2
Create a Global Secondary Index (GSI) to resolve the first access pattern.
Define a GSI with PlayerID as the partition key and MatchTimestamp as the sort key. Use a Query operation on this GSI with a KeyConditionExpression to fetch matches within the 77-day range.
This allows DynamoDB to read only the items that match the criteria, minimizing RCU consumption.
3
Analyze the access pattern for retrieving high-scoring matches across all players.
Scanning the base table is highly inefficient because it evaluates every record. We need a way to only index and retrieve records where the score is greater than 10,00010,000.
Using a sparse index will exclude low-scoring matches from the GSI, significantly reducing index size and retrieval costs.
4
Implement a sparse GSI for the second access pattern.
Modify the application logic to write a HighScoreThreshold attribute (e.g., containing the score) to the base table item only if the score exceeds 10,00010,000. Create a GSI with HighScoreThreshold as the partition key.
Items without the HighScoreThreshold attribute will not be indexed in the GSI, making the GSI sparse. Querying this sparse GSI directly targets high-scoring matches without scanning other records.

Key Concept

Optimizing read operations in DynamoDB using Global Secondary Indexes (GSIs) and sparse indexes instead of performing full table Scan operations.
Estimated Time:2m 0s
Rate this question