Scan vs query performance in AWS - Performance Comparison
When working with AWS databases, it is important to know how fast different data retrieval methods work as data grows.
We want to understand how the time to get data changes when using scan versus query operations.
Analyze the time complexity of the following operation sequence.
# Query operation
aws dynamodb query --table-name MyTable --key-condition-expression "UserId = :userId" --expression-attribute-values '{":userId":{"S":"123"}}'
# Scan operation
aws dynamodb scan --table-name MyTable
The query fetches items matching a specific key, while the scan reads all items in the table.
- Primary operation: Reading items from the database.
- How many times: Query reads only matching items; Scan reads every item in the table.
As the number of items in the table grows, query reads only a small subset, but scan reads all items.
| Input Size (n) | Approx. Api Calls/Operations |
|---|---|
| 10 | Query: few calls; Scan: 10 calls |
| 100 | Query: few calls; Scan: 100 calls |
| 1000 | Query: few calls; Scan: 1000 calls |
Pattern observation: Query time stays mostly the same; Scan time grows directly with table size.
Time Complexity: O(n) for scan, O(1) for query
This means scan time grows with the number of items, but query time stays mostly constant for targeted lookups.
[X] Wrong: "Scan and query take the same time because they both read data from the table."
[OK] Correct: Scan reads every item, so time grows with table size. Query reads only matching items, so time stays small.
Understanding how scan and query scale helps you design efficient data access in cloud apps, a key skill for real projects.
"What if we added an index to the table? How would that affect the time complexity of queries and scans?"
Practice
Solution
Step 1: Understand Query operation
Query retrieves items by specifying the primary key, making it fast and efficient.Step 2: Compare with Scan operation
Scan reads the entire table, which is slower and more costly when you know the key.Final Answer:
Query -> Option CQuick Check:
Known key = Query [OK]
- Thinking Scan is faster for known keys
- Confusing Update or Delete with data retrieval
- Assuming Query reads the whole table
Solution
Step 1: Identify Query command syntax
The Query operation uses 'aws dynamodb query' with key-condition-expression and expression-attribute-values.Step 2: Check other options
Scan reads the entire table (and does not support --key-condition-expression), get-item retrieves a single item by exact key, update-item modifies items, so only the Query syntax is correct.Final Answer:
aws dynamodb query --table-name MyTable --key-condition-expression 'Id = :id' --expression-attribute-values '{":id":{"S":"123"}}' -> Option AQuick Check:
Query syntax uses 'query' command [OK]
- Using Scan command instead of Query
- Confusing GetItem with Query
- Incorrect expression-attribute-values format
1. Query with KeyConditionExpression on partition key
2. Scan without any filter
Solution
Step 1: Analyze Query operation
Query uses the partition key to directly find matching items, reading fewer items and faster.Step 2: Analyze Scan operation
Scan reads every item in the table, making it slower and more expensive.Final Answer:
Query reads fewer items and is faster; Scan reads all items and is slower -> Option DQuick Check:
Query = fewer reads, Scan = full table [OK]
- Assuming Scan is faster than Query
- Thinking Query reads all items
- Ignoring cost differences
aws dynamodb scan --table-name Users
What is the best way to improve performance if you only want users with UserId = '123'?
Solution
Step 1: Identify problem with Scan
Scan reads all items, causing slowness when filtering after reading.Step 2: Use Query for known key
Query with KeyConditionExpression on UserId reads only matching items, improving speed.Final Answer:
Replace Scan with Query using KeyConditionExpression on UserId -> Option AQuick Check:
Known key = Query, not Scan [OK]
- Adding filter to Scan instead of using Query
- Increasing capacity without optimizing query
- Using UpdateItem unrelated to read performance
Solution
Step 1: Understand Scan with filter
Scan reads all 1 million items, filtering after reading, which is slow and costly.Step 2: Use GSI for efficient querying
Creating a GSI on 'Status' allows Query to directly find 'Active' items efficiently.Step 3: Evaluate other options
Query on primary key can't filter by 'Status' efficiently; scanning without filter wastes resources.Final Answer:
Create a Global Secondary Index (GSI) on 'Status' and use Query on the GSI -> Option BQuick Check:
GSI + Query = best performance for non-key attribute [OK]
- Using Scan with filter on large tables
- Querying primary key with filter instead of GSI
- Filtering in application after full Scan
Ready to prove it?
Pass the test and this pattern moves unknown
