Jump into concepts and practice - no test required
or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Scan vs Query Performance Comparison in DynamoDB
📖 Scenario: You are managing a DynamoDB table that stores customer orders. You want to understand the difference in performance between using Scan and Query operations to retrieve data.
🎯 Goal: Build a simple DynamoDB setup with a table of orders, then write code to perform a Scan and a Query operation. Compare how each operation works and understand their performance differences.
📋 What You'll Learn
Create a DynamoDB table named Orders with OrderId as the partition key
Insert 5 sample orders with specific OrderId and CustomerName
Define a variable to hold the CustomerName to query
Write a Query operation to get orders for the given CustomerName
Write a Scan operation to get all orders and filter by CustomerName
💡 Why This Matters
🌍 Real World
Understanding the difference between Scan and Query helps optimize database performance and cost in real DynamoDB applications.
💼 Career
Database developers and cloud engineers often need to choose the right DynamoDB operation to efficiently retrieve data.
Progress0 / 4 steps
1
Create the Orders table with sample data
Create a dictionary called orders with these exact entries representing orders: 'OrderId': 101, 'CustomerName': 'Alice', 'OrderId': 102, 'CustomerName': 'Bob', 'OrderId': 103, 'CustomerName': 'Alice', 'OrderId': 104, 'CustomerName': 'Charlie', 'OrderId': 105, 'CustomerName': 'Bob'. Store these as a list of dictionaries in orders.
DynamoDB
Hint
Use a list of dictionaries. Each dictionary has keys 'OrderId' and 'CustomerName'.
2
Set the customer name to query
Create a variable called customer_to_find and set it to the string 'Bob'.
DynamoDB
Hint
Just assign the string 'Bob' to the variable customer_to_find.
3
Write the Query operation to find orders for Bob
Create a list called query_results that contains only the orders from orders where CustomerName equals customer_to_find. Use a list comprehension with order as the loop variable.
DynamoDB
Hint
Use a list comprehension with order in orders and filter by order['CustomerName'] == customer_to_find.
4
Write the Scan operation to find orders for Bob
Create a list called scan_results that contains all orders from orders but filtered by CustomerName equal to customer_to_find. Use a for loop with order as the loop variable and an if statement inside the loop to append matching orders to scan_results.
DynamoDB
Hint
Initialize scan_results as an empty list. Use a for loop over orders. Inside the loop, use an if statement to check order['CustomerName'] == customer_to_find. Append matching orders to scan_results.
Practice
(1/5)
1. Which DynamoDB operation is generally faster when you know the partition key of the item you want to retrieve?
easy
A. Scan
B. UpdateItem
C. Query
D. DeleteItem
Solution
Step 1: Understand Query operation
Query uses the partition key to directly find matching items, making it efficient.
Step 2: Compare with Scan operation
Scan reads the entire table, which is slower and less efficient.
Final Answer:
Query -> Option C
Quick Check:
Query is faster for known keys [OK]
Hint: Use Query when you know the partition key for speed [OK]
Common Mistakes:
Thinking Scan is faster because it reads all data
Confusing Query with Scan
Assuming UpdateItem is for reading data
2. Which of the following is the correct syntax to perform a Query operation in DynamoDB using AWS SDK for JavaScript?
Hint: Query needs KeyConditionExpression, not FilterExpression [OK]
Common Mistakes:
Using FilterExpression instead of KeyConditionExpression for Query
Using scan method with KeyConditionExpression
Confusing getItem with query syntax
3. Given a DynamoDB table with 1000 items, what will be the main difference in performance between these two operations? dynamoDbClient.scan({ TableName: 'MyTable' }) and dynamoDbClient.query({ TableName: 'MyTable', KeyConditionExpression: '#pk = :pk', ExpressionAttributeNames: { '#pk': 'PartitionKey' }, ExpressionAttributeValues: { ':pk': '123' } })
medium
A. Scan reads all 1000 items; Query reads only matching items, so Query is faster.
B. Scan is faster because it reads all items at once; Query is slower due to filtering.
C. Both operations have the same speed because they access the same table.
D. Query reads all items; Scan reads only matching items.
Solution
Step 1: Understand Scan operation
Scan reads every item in the table, so it processes all 1000 items.
Step 2: Understand Query operation
Query uses the partition key to read only matching items, which is faster.
Final Answer:
Scan reads all items; Query reads only matching items, so Query is faster. -> Option A
A. Missing ExpressionAttributeNames for reserved word PartitionKey
B. Using Scan instead of Query
C. TableName is misspelled
D. Incorrect KeyConditionExpression syntax; should use #pk = :pk
Solution
Step 1: Check KeyConditionExpression syntax
KeyConditionExpression requires placeholders for attribute names like #pk defined in ExpressionAttributeNames.
Step 2: Identify missing ExpressionAttributeNames
The code uses 'PartitionKey' directly without ExpressionAttributeNames, causing no matches.
Final Answer:
Incorrect KeyConditionExpression syntax; should use #pk = :pk -> Option D
Quick Check:
Reserved words need placeholders in KeyConditionExpression [OK]
Hint: Use placeholders for reserved words in KeyConditionExpression [OK]
Common Mistakes:
Not using ExpressionAttributeNames for reserved words
Confusing Scan and Query methods
Misspelling TableName
5. You want to retrieve all items where the attribute 'Status' equals 'Active' from a large DynamoDB table. The table's partition key is 'UserId'. Which approach is best for performance and cost?
hard
A. Use Query with KeyConditionExpression on 'UserId' and FilterExpression on 'Status' = 'Active'.
B. Create a Global Secondary Index (GSI) on 'Status' and Query the GSI for 'Active' items.
C. Use Scan with a FilterExpression on 'Status' = 'Active' to get all matching items.
D. Use Scan without any filters to get all items and then filter in application code.
Solution
Step 1: Understand limitations of Scan and Query
Scan reads entire table and is costly; Query requires partition key, but 'Status' is not the partition key.
Step 2: Use GSI for efficient querying
Creating a GSI on 'Status' allows Query on 'Status' attribute efficiently without scanning.
Final Answer:
Create a Global Secondary Index (GSI) on 'Status' and Query the GSI for 'Active' items. -> Option B
Quick Check:
GSI enables efficient queries on non-key attributes [OK]
Hint: Use GSI to query non-key attributes efficiently [OK]