Partition key selection in DynamoDB - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why is choosing a good partition key important in DynamoDB?

Imagine you have a DynamoDB table storing user orders. Which reason best explains why selecting a good partition key matters?

A It prevents the need for a sort key in the table design.

B It guarantees that all data is stored in a single partition for faster access.

C It allows DynamoDB to automatically create indexes without user input.

D It ensures data is evenly distributed across partitions to avoid hot spots and improve performance.

💡 Hint

Think about how DynamoDB stores data internally and what happens if too many items share the same partition key.

A good partition key spreads data evenly across partitions, avoiding hot spots that slow down reads and writes. Options B, C, and D are incorrect because data is distributed, indexes require design, and sort keys are optional but unrelated to partition key choice.

❓ query_result

intermediate

What is the result of this partition key choice?

Given a DynamoDB table with partition key 'Country' and sort key 'UserID', what happens if most users are from the same country?

DynamoDB

Table: Users
Partition Key: Country
Sort Key: UserID
Data: 90% users have Country = 'USA', 10% others

Question: How does this affect performance?

A The 'USA' partition becomes a hot partition causing throttling and slower queries.

B Data is evenly distributed because sort key balances the load.

C DynamoDB automatically splits the 'USA' partition to handle load.

D Queries on 'USA' users will be faster due to data locality.

💡 Hint

Consider how DynamoDB partitions data based on the partition key only.

Since partition key is 'Country', all 'USA' users share the same partition, causing a hot partition. Sort key does not affect partition distribution. DynamoDB does not automatically split hot partitions instantly. Queries on hot partitions slow down.

📝 Syntax

advanced

Which partition key definition is valid in DynamoDB table creation?

Choose the correct AWS CLI command snippet to create a DynamoDB table with a partition key named 'UserID' of type string.

DynamoDB

aws dynamodb create-table --table-name Users --attribute-definitions ... --key-schema ... --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5

A --attribute-definitions AttributeName=UserID,AttributeType=N --key-schema AttributeName=UserID,KeyType=HASH

B --attribute-definitions AttributeName=UserID,AttributeType=S --key-schema AttributeName=UserID,KeyType=HASH

C --attribute-definitions AttributeName=UserID,AttributeType=BOOL --key-schema AttributeName=UserID,KeyType=HASH

D --attribute-definitions AttributeName=UserID,AttributeType=SS --key-schema AttributeName=UserID,KeyType=HASH

💡 Hint

Check the valid attribute types for partition keys in DynamoDB.

Partition keys must be of type String (S), Number (N), or Binary (B). BOOL and SS (string set) are invalid for keys. Option B uses String type correctly.

❓ optimization

advanced

How to optimize partition key for a high-traffic IoT sensor data table?

You have a DynamoDB table storing sensor readings. Each sensor sends data every second. Which partition key design best avoids hot partitions?

A Use 'SensorID' as partition key to distribute data evenly across sensors.

B Use a constant value as partition key to simplify queries.

C Use 'SensorID' concatenated with date (e.g., 'SensorID#20240601') as partition key.

D Use 'Timestamp' as partition key to group data by time.

💡 Hint

Think about how to spread writes evenly when sensors send frequent data.

Using only 'SensorID' may cause hot partitions if some sensors send more data. Using timestamp alone groups all data by time causing hot spots. A constant partition key causes a single hot partition. Concatenating 'SensorID' with date creates more partitions and balances load.

🔧 Debug

expert

Why does this DynamoDB query cause throttling despite low overall traffic?

Given a table with partition key 'UserID' and sort key 'OrderDate', a query filters orders for UserID='123'. Despite low total traffic, the query is throttled. What is the likely cause?

DynamoDB

Query:
{
  TableName: 'Orders',
  KeyConditionExpression: 'UserID = :uid',
  ExpressionAttributeValues: { ':uid': '123' }
}

A UserID='123' has many orders causing a hot partition and throttling.

B The query syntax is invalid causing throttling errors.

C Sort key 'OrderDate' is missing in the query causing throttling.

D Provisioned throughput is too high causing throttling.

💡 Hint

Consider what happens if one partition key value has a lot of data.

Throttling happens because the partition for UserID='123' is overloaded with many orders. Query syntax is valid. High provisioned throughput does not cause throttling. Sort key is optional in queries filtering by partition key.

Practice

1. What is the main role of a partition key in DynamoDB?

easy

A. It sets the maximum size of the table.

B. It defines the data type of the table.

C. It determines how data is distributed across storage nodes.

D. It controls the read and write capacity of the table.

Solution

1. Step 1: Understand partition key purpose

   The partition key is used to decide where data is stored in DynamoDB's distributed system.

2. Step 2: Compare options

   Only It determines how data is distributed across storage nodes. correctly describes this role; others describe unrelated features.

3. Final Answer:

   It determines how data is distributed across storage nodes. -> Option C

4. Quick Check:

   Partition key = data distribution [OK]

Hint: Partition key decides data location in storage [OK]

Common Mistakes:

• Confusing partition key with capacity settings
• Thinking partition key sets data type
• Assuming partition key limits table size

2. Which of the following is a valid way to define a partition key in a DynamoDB table creation command?

easy

A. "KeySchema": [{"AttributeName": "UserId", "KeyType": "HASH"}]

B. "KeySchema": [{"AttributeName": "UserId", "KeyType": "RANGE"}]

C. "KeySchema": [{"AttributeName": "UserId", "KeyType": "PRIMARY"}]

D. "KeySchema": [{"AttributeName": "UserId", "KeyType": "INDEX"}]

Solution

1. Step 1: Recall partition key syntax

   Partition key uses KeyType "HASH" in DynamoDB KeySchema.

2. Step 2: Check each option

   Only "KeySchema": [{"AttributeName": "UserId", "KeyType": "HASH"}] uses "HASH" correctly; others use invalid or incorrect KeyType values.

3. Final Answer:

   "KeySchema": [{"AttributeName": "UserId", "KeyType": "HASH"}] -> Option A

4. Quick Check:

   Partition key = KeyType HASH [OK]

Hint: Partition key uses KeyType 'HASH' in schema [OK]

Common Mistakes:

• Using RANGE instead of HASH for partition key
• Confusing PRIMARY or INDEX as KeyType
• Misnaming KeyType values

3. Given a DynamoDB table with partition key UserId having many unique values, and sort key OrderDate, what will happen if you query with UserId = '123' only?

medium

A. The query will fail because sort key is missing.

B. You get all orders for user '123' sorted by OrderDate.

C. You get only one order for user '123' without sorting.

D. You get all orders for all users sorted by OrderDate.

Solution

1. Step 1: Understand query with partition key only

   Querying with partition key returns all items with that key, optionally sorted by sort key.

2. Step 2: Analyze given keys

   Since UserId is partition key and OrderDate is sort key, querying UserId='123' returns all orders for that user sorted by OrderDate.

3. Final Answer:

   You get all orders for user '123' sorted by OrderDate. -> Option B

4. Quick Check:

   Query by partition key returns all matching items [OK]

Hint: Query by partition key returns all matching items [OK]

Common Mistakes:

• Thinking query needs sort key value
• Expecting only one item without sort key
• Assuming query returns all users' data

4. You designed a DynamoDB table with CustomerId as partition key but notice hot partitions causing slow performance. What is the likely cause?

medium

A. CustomerId has too many unique values causing large partitions.

B. CustomerId is used as sort key instead of partition key.

C. CustomerId is missing from the KeySchema.

D. CustomerId has very few unique values causing uneven data distribution.

Solution

1. Step 1: Understand hot partitions

   Hot partitions happen when few partition keys get most traffic, causing uneven load.

2. Step 2: Analyze CustomerId uniqueness

   If CustomerId has few unique values, many requests hit same partitions causing hot spots.

3. Final Answer:

   CustomerId has very few unique values causing uneven data distribution. -> Option D

4. Quick Check:

   Few unique keys = hot partitions [OK]

Hint: Few unique partition keys cause hot partitions [OK]

Common Mistakes:

• Assuming too many unique keys cause hot partitions
• Confusing missing key with performance issue
• Mixing partition key with sort key roles

5. You want to design a DynamoDB table to store IoT sensor data from thousands of devices. Which partition key choice will best support even data distribution and scalability?

hard

A. Use DeviceId as partition key because it has many unique values.

B. Use a constant string like 'SensorData' as partition key for all items.

C. Use Timestamp as partition key to sort data by time.

D. Use DeviceType as partition key since it groups similar devices.

Solution

1. Step 1: Identify key with many unique values

   DeviceId uniquely identifies each device, providing many distinct partition keys.

2. Step 2: Evaluate other options

   Constant string causes hot partition; Timestamp changes too fast for partition key; DeviceType groups few devices causing uneven load.

3. Final Answer:

   Use DeviceId as partition key because it has many unique values. -> Option A

4. Quick Check:

   Many unique keys = good partition key [OK]

Hint: Choose partition key with many unique values [OK]

Common Mistakes:

• Using constant value causing hot partitions
• Choosing timestamp as partition key
• Grouping by device type causing uneven load