DynamoDB Local Secondary Indexes (LSI) - Complete Guide
Why Local Secondary Indexes Are Important
Local Secondary Indexes (LSIs) are crucial for DynamoDB because they allow you to query data using an alternative sort key while maintaining the same partition key. This enables flexible query patterns on your data that would otherwise require full table scans, which are expensive and slow.
What is a Local Secondary Index?
A Local Secondary Index is an index that has the same partition key as the base table but a different sort key. The term 'local' refers to the fact that the index is scoped to a single partition key value, meaning all index entries are stored in the same partition as the corresponding base table items.
Key Characteristics of LSIs:
• Must be created at table creation time - cannot be added later
• Maximum of 5 LSIs per table
• Same partition key as the base table, different sort key
• Shares the provisioned throughput with the base table
• Limited to 10GB of data per partition key value
• Supports both eventual and strong consistency
How Local Secondary Indexes Work
When you create an LSI, DynamoDB automatically maintains the index. When items are added, updated, or deleted in the base table, the corresponding LSI entries are updated automatically.
Projection Types:
• KEYS_ONLY - Only the partition key and sort keys are projected
• INCLUDE - Specified attributes are projected in addition to keys
• ALL - All attributes from the base table are projected
Example Use Case:
Base table: UserOrders with partition key UserId and sort key OrderDate
LSI: Sort by OrderStatus instead, allowing queries like 'get all pending orders for user X'
Item Collections and Size Limits
An item collection is all items with the same partition key value across the base table and all LSIs. The total size cannot exceed 10GB. This is a critical limitation to understand.
Exam Tips: Answering Questions on DynamoDB Local Secondary Indexes
1. Creation Time: If a question mentions adding an index after table creation, the answer is NOT an LSI. LSIs can only be created when the table is created.
2. Partition Key Rule: LSIs always share the same partition key as the base table. If you need a different partition key, you need a Global Secondary Index (GSI).
3. Count Limit: Remember the maximum of 5 LSIs per table. Questions may test this limit.
4. 10GB Limit: Watch for scenarios involving large amounts of data per partition key. The 10GB item collection limit is a common exam topic.
5. Consistency Options: LSIs support both eventual and strongly consistent reads, unlike GSIs which only support eventual consistency.
6. Throughput: LSIs consume capacity from the base table's provisioned throughput. They do not have separate capacity settings.
7. Query vs Scan: LSIs enable efficient Query operations. If someone needs to query by an attribute that is not the current sort key, an LSI with that attribute as the sort key is the solution.
8. LSI vs GSI Comparison: Know the differences - LSIs are created at table creation, share partition key, support strong consistency, and have the 10GB limit. GSIs can be created anytime, have different partition keys, only support eventual consistency, and have separate throughput.
Common Exam Scenarios:
• Optimizing queries on existing tables with alternative sort orders
• Choosing between LSI and GSI based on requirements
• Understanding capacity consumption and cost implications
• Handling the 10GB item collection size constraint