What if you could instantly find and sort data without flipping through every page?
Why Local Secondary Index (LSI) concept in DynamoDB? - Purpose & Use Cases
Imagine you have a big notebook where you write down all your friends' names and their phone numbers. Now, you want to find all friends who live in the same city and sort them by their birthdays. Doing this by flipping through every page manually is tiring and slow.
Manually searching through pages every time you want to find friends by city and birthday is slow and easy to make mistakes. You might miss some entries or spend too much time flipping pages, especially as your notebook grows.
Local Secondary Index (LSI) lets you create a special, organized list inside your notebook that groups friends by city and sorts them by birthday. This way, you can quickly find and sort friends without flipping through every page.
Scan entire table and filter by city, then sort results in code
Query table using LSI on city and birthday to get sorted results directlyLSI enables fast, efficient queries on different sort keys within the same partition, making data retrieval quick and organized.
A music app stores songs by artist (partition key). Using LSI on song release date lets users quickly find all songs by an artist sorted by release date without scanning all songs.
Manual searching through all data is slow and error-prone.
LSI creates a sorted view on the same partition key with a different sort key.
This makes queries faster and more efficient for specific access patterns.
Practice
Solution
Step 1: Understand LSI functionality
LSI lets you query items with the same partition key but sorted by an alternate sort key.Step 2: Compare options
Only To allow querying data with the same partition key but different sort keys correctly describes this feature; others describe unrelated features.Final Answer:
To allow querying data with the same partition key but different sort keys -> Option BQuick Check:
LSI = alternate sort key with same partition key [OK]
- Thinking LSI creates new partition keys
- Confusing LSI with Global Secondary Index
- Believing LSI stores data separately
Solution
Step 1: Recall LSI definition rules
LSIs must use the same partition key as the main table but can have a different sort key.Step 2: Check options
Only Define the LSI with the same partition key but a different sort key matches this rule; others violate partition key or timing constraints.Final Answer:
Define the LSI with the same partition key but a different sort key -> Option DQuick Check:
LSI = same partition key + different sort key [OK]
- Trying to create LSI after table creation
- Using different partition keys for LSI
- Omitting sort key in LSI definition
UserID and sort key Timestamp, and an LSI with sort key OrderStatus, what will the following query return?Query: KeyConditionExpression = UserID = '123' AND OrderStatus = 'Pending'Solution
Step 1: Understand query with LSI
Query on LSI uses same partition key but different sort key (OrderStatus). The query filters UserID = '123' and OrderStatus = 'Pending'.Step 2: Analyze query result
It returns items with UserID '123' and OrderStatus 'Pending', sorted by OrderStatus.Final Answer:
All items with UserID '123' and OrderStatus 'Pending' sorted by OrderStatus -> Option CQuick Check:
Query on LSI filters by partition and LSI sort key [OK]
- Assuming LSI changes partition key
- Thinking query returns all items with OrderStatus only
- Believing syntax error occurs using LSI sort key
Solution
Step 1: Check LSI query requirements
Queries on LSI require the correct partition key value; wrong partition key returns no results.Step 2: Evaluate options
The partition key value in the query is incorrect explains no results due to incorrect partition key; other options are less likely or invalid.Final Answer:
The partition key value in the query is incorrect -> Option AQuick Check:
Correct partition key needed for LSI query [OK]
- Trying to add LSI after table creation
- Ignoring missing sort key attributes
- Confusing LSI partition key with main table partition key
CustomerID and sort key OrderDate. You want to query all orders for a customer sorted by OrderStatus instead of OrderDate. How should you design the Local Secondary Index (LSI) to achieve this?Solution
Step 1: Understand LSI design rules
LSI must use the same partition key as the main table but can have a different sort key.Step 2: Apply to problem
To sort by OrderStatus for the same CustomerID, create an LSI with partition key CustomerID and sort key OrderStatus at table creation.Step 3: Eliminate wrong options
Create an LSI with partition keyOrderStatusand sort keyOrderDateafter table creation is invalid because LSI cannot be created after table creation; Create a Global Secondary Index (GSI) with partition keyCustomerIDand sort keyOrderStatusis about GSI, not LSI; AddOrderStatusas a new partition key in the main table changes partition key, which is not allowed.Final Answer:
Create an LSI with partition key CustomerID and sort key OrderStatus defined at table creation -> Option AQuick Check:
LSI = same partition key + new sort key at creation [OK]
- Trying to create LSI after table creation
- Confusing LSI with GSI
- Changing partition key in LSI
Ready to prove it?
Pass the test and this pattern moves unknown
