Basic scan operation in DynamoDB - Time & Space Complexity
Start learning this pattern below
Jump into concepts and practice - no test required
When we use a scan operation in DynamoDB, it looks through all the items in a table. Understanding how long this takes helps us know how it will behave as the table grows.
We want to find out how the time needed changes when the number of items increases.
Analyze the time complexity of the following code snippet.
const params = {
TableName: "MyTable"
};
const data = await dynamodb.scan(params).promise();
console.log(data.Items);
This code scans the entire "MyTable" and returns all items found.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Reading each item in the table one by one.
- How many times: Once for every item in the table.
As the number of items grows, the scan must look at each item, so the work grows steadily.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 reads |
| 100 | 100 reads |
| 1000 | 1000 reads |
Pattern observation: The number of operations grows directly with the number of items.
Time Complexity: O(n)
This means the time to scan grows in a straight line 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 big, it takes longer.
Knowing how scan time grows helps you explain why it's better to use queries or indexes when possible. This shows you understand how database operations scale.
"What if we added a filter expression to the scan? How would the time complexity change?"
Practice
scan operation do in DynamoDB?Solution
Step 1: Understand the scan operation
The scan operation reads every item in the DynamoDB table without filtering by key.Step 2: Compare with other operations
Unlike get or query, scan reads all items, not just specific keys.Final Answer:
Reads all items in a table -> Option AQuick Check:
Scan = Reads all items [OK]
- Confusing scan with get or query
- Thinking scan deletes or updates data
- Assuming scan reads only filtered items
Solution
Step 1: Identify scan method usage
The scan method is called on the DynamoDB client with parameters including TableName.Step 2: Check other methods
Get, query, and delete are different operations and do not perform scan.Final Answer:
const data = await client.scan({ TableName: 'MyTable' }); -> Option CQuick Check:
Scan syntax uses client.scan() [OK]
- Using get or query instead of scan
- Missing await keyword
- Wrong method names like delete
Solution
Step 1: Understand scan returns all items
Scan reads every item in the table, so all 3 items will be returned.Step 2: Check options for completeness
Only [{id:1, name:'A'}, {id:2, name:'B'}, {id:3, name:'C'}] lists all 3 items; others are incomplete or errors.Final Answer:
[{id:1, name:'A'}, {id:2, name:'B'}, {id:3, name:'C'}] -> Option AQuick Check:
Scan returns all items [OK]
- Expecting scan to return only one item
- Thinking scan returns empty if no filter
- Confusing scan with query results
const params = { TableName: 'MyTable', FilterExpression: 'age > :val', ExpressionAttributeValues: { ':val': 30 } };
const data = await client.scan(params);What is the likely problem?
Solution
Step 1: Understand FilterExpression in scan
FilterExpression filters results after scanning all items; if no items match, result is empty.Step 2: Check syntax and params
Syntax is correct, TableName is present, and scan supports FilterExpression.Final Answer:
FilterExpression is applied after scan reads all items, so no items match age > 30 -> Option DQuick Check:
FilterExpression filters after scan [OK]
- Thinking FilterExpression prevents scanning items
- Assuming scan fails with FilterExpression
- Missing TableName parameter
status is 'active'. Which approach is best to reduce data returned and improve performance?Solution
Step 1: Understand scan vs query
Scan reads entire table; query reads items by key, more efficient for filtering.Step 2: Check if status can be partition key
If status is partition key, query can efficiently get only 'active' items without scanning all.Step 3: Evaluate other options
FilterExpression filters after scan, so less efficient; filtering in app wastes bandwidth; ProjectionExpression only limits attributes, not items.Final Answer:
Use query operation with status as partition key -> Option BQuick Check:
Query with key filters efficiently [OK]
- Relying on scan with filters for large tables
- Filtering data in application instead of query
- Confusing ProjectionExpression with filtering items
