Module Review: Secondary Indexes
In this module, we explored how to access data beyond the primary key. We learned the critical differences between LSI and GSI, how to “overload” a GSI to store multiple access patterns, and how to use Sparse Indexes for efficient filtering.
Key Takeaways
- LSI vs GSI:
- LSI: Created at table creation. Shares throughput with base table. Limits partition size to 10GB. Strong consistency possible.
- GSI: Created anytime. Has its own throughput (RCU/WCU). No size limits. Only eventual consistency.
- Overloading: Using generic names (
GSI1PK,GSI1SK) allows you to index different entity types in the same GSI, saving money. - Sparse Indexes: GSIs only contain items that have the index key. Omitting the key acts as a “free” filter.
- Projections: Always project only the attributes you need (
KEYS_ONLY,INCLUDE, orALL) to save storage and cost.
1. Flashcards
LSI vs GSI: Which one allows Strong Consistency?
(Click to flip)
LSI (Local Secondary Index).
Because it lives on the same physical partition as the base table item.
What happens if I don't set the GSI Key on an item?
The item is not written to the index.
This is the principle behind Sparse Indexes.
Can I add an LSI after the table is created?
No.
LSIs must be defined at table creation time. GSIs can be added anytime.
Why "Overload" a GSI?
To support multiple access patterns without paying for multiple indexes.
You use generic key names like SK or GSI1PK.
What is the LSI size limit?
The total size of an Item Collection (Base Item + all LSI items) cannot exceed 10 GB.
2. Cheat Sheet: LSI vs GSI
| Feature | LSI (Local) | GSI (Global) |
|---|---|---|
| Creation | Table Creation Only | Anytime |
| Key Schema | PK = Base PK, SK = Different | PK = Anything, SK = Anything |
| Consistency | Strong or Eventual | Eventual Only |
| Provisioning | Shares Base Table Throughput | Independent RCU/WCU |
| Size Limit | 10GB per Partition Key | Unlimited |
| Projections | Keys, Include, All | Keys, Include, All |