When Scan is acceptable in DynamoDB - Time & Space Complexity
Start learning this pattern below
Jump into concepts and practice - no test required
We want to understand how the time to run a Scan operation in DynamoDB changes as the amount of data grows.
How does scanning many items affect the work DynamoDB does?
Analyze the time complexity of the following Scan operation.
const params = {
TableName: "Products",
FilterExpression: "Price > :minPrice",
ExpressionAttributeValues: { ":minPrice": 100 }
};
const data = await dynamodb.scan(params).promise();
console.log(data.Items);
This code scans the entire "Products" table and filters items with Price greater than 100.
Look for repeated work inside the Scan.
- Primary operation: Reading each item in the table one by one.
- How many times: Once for every item stored in the table.
As the number of items grows, the Scan reads more and more data.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | Reads about 10 items |
| 100 | Reads about 100 items |
| 1000 | Reads about 1000 items |
Pattern observation: The work grows directly with the number of items. More items mean more reading.
Time Complexity: O(n)
This means the time to complete the Scan grows linearly with the number of items in the table.
[X] Wrong: "Scan only reads a few items, so it's always fast."
[OK] Correct: Scan reads every item in the table, so if the table is large, it takes longer.
Understanding when Scan is acceptable shows you know how to balance simplicity and performance in real projects.
"What if we replaced Scan with Query using a partition key? How would the time complexity change?"
Practice
Scan operation in DynamoDB?Solution
Step 1: Understand Scan operation purpose
Scan reads every item in the table, which is simple but slow for large tables.Step 2: Match Scan use case
Scan is acceptable when the table is small and you need all data, not a specific item by key.Final Answer:
When you need to read all items from a small table. -> Option CQuick Check:
Scan = small table full read [OK]
- Using Scan to get a single item by key
- Using Scan for updates or deletes
- Ignoring performance impact on large tables
Solution
Step 1: Identify correct Scan parameters
Scan uses FilterExpression to filter results after scanning all items.Step 2: Check syntax correctness
Scan(TableName='Users', FilterExpression='Age > :age', ExpressionAttributeValues={':age': 30}) uses FilterExpression and ExpressionAttributeValues correctly for filtering.Final Answer:
Scan(TableName='Users', FilterExpression='Age > :age', ExpressionAttributeValues={':age': 30}) -> Option DQuick Check:
FilterExpression syntax = Scan(TableName='Users', FilterExpression='Age > :age', ExpressionAttributeValues={':age': 30}) [OK]
- Using KeyConditionExpression with Scan
- Using wrong parameter names like Filter or ConditionExpression
- Not providing ExpressionAttributeValues for placeholders
Scan(TableName='Products', FilterExpression='Category = :cat', ExpressionAttributeValues={':cat': 'Book'})Solution
Step 1: Understand Scan with FilterExpression
Scan reads all items, then returns only those matching the filter Category = 'Book'.Step 2: Apply filter to items
Items with Category 'Book' are ID 1 and ID 3, so only these are returned.Final Answer:
[{"ID":1, "Category":"Book"}, {"ID":3, "Category":"Book"}] -> Option AQuick Check:
Filter returns matching items only [OK]
- Expecting Scan to return only filtered items without FilterExpression
- Confusing Scan with Query operation
- Ignoring that Scan reads all items first
Scan(TableName='Orders', FilterExpression='Status = :s')What is the most likely error?
Solution
Step 1: Check FilterExpression usage
FilterExpression uses placeholders like ':s' which must be defined in ExpressionAttributeValues.Step 2: Identify missing ExpressionAttributeValues
Code lacks ExpressionAttributeValues, so filter cannot apply and returns all items.Final Answer:
Missing ExpressionAttributeValues for ':s'. -> Option AQuick Check:
Filter needs ExpressionAttributeValues [OK]
- Confusing FilterExpression with KeyConditionExpression
- Forgetting ExpressionAttributeValues
- Assuming Scan ignores missing values silently
Status = 'Active'. Which approach is best?Solution
Step 1: Understand limitations of Scan on large tables
Scan reads all items and is slow and costly on large tables, even with filters.Step 2: Use Global Secondary Index (GSI) for efficient queries
Creating a GSI on 'Status' allows Query operation, which is fast and efficient for filtering by 'Status'.Final Answer:
Create a Global Secondary Index on 'Status' and use Query. -> Option BQuick Check:
GSI + Query = efficient large table filter [OK]
- Using Scan on large tables causing slow performance
- Trying Query without suitable key or index
- Ignoring cost and speed implications
