- DynamoDB Tutorial
- DynamoDB - Home
- DynamoDB - Overview
- DynamoDB - Basic Concepts
- DynamoDB - Environment
- DynamoDB - Operations Tools
- DynamoDB - Data Types
- DynamoDB - Create Table
- DynamoDB - Load Table
- DynamoDB - Query Table
- DynamoDB - Delete Table
- DynamoDB - API Interface
- DynamoDB - Creating Items
- DynamoDB - Getting Items
- DynamoDB - Update Items
- DynamoDB - Delete Items
- DynamoDB - Batch Writing
- DynamoDB - Batch Retrieve
- DynamoDB - Querying
- DynamoDB - Scan
- DynamoDB - Indexes
- Global Secondary Indexes
- Local Secondary Indexes
- DynamoDB - Aggregation
- DynamoDB - Access Control
- DynamoDB - Permissions API
- DynamoDB - Conditions
- Web Identity Federation
- DynamoDB - Data Pipeline
- DynamoDB - Data Backup
- DynamoDB - Monitoring
- DynamoDB - CloudTrail
- DynamoDB - MapReduce
- DynamoDB - Table Activity
- DynamoDB - Error Handling
- DynamoDB - Best Practices
- Selected Reading
- UPSC IAS Exams Notes
- Developer's Best Practices
- Questions and Answers
- Effective Resume Writing
- HR Interview Questions
- Computer Glossary
- Who is Who
DynamoDB - Indexes
DynamoDB uses indexes for primary key attributes to improve accesses. They accelerate application accesses and data retrieval, and support better performance by reducing application lag.
A secondary index holds an attribute subset and an alternate key. You use it through either a query or scan operation, which targets the index.
Its contents include attributes you project or copy. In creation, you define an alternate key for the index, and any attributes you wish to project in the index. DynamoDB then performs a copy of the attributes into the index, including primary key attributes sourced from the table. After performing these tasks, you simply use a query/scan as if performing on a table.
DynamoDB automatically maintains all secondary indices. On item operations, such as adding or deleting, it updates any indexes on the target table.
DynamoDB offers two types of secondary indexes −
Global Secondary Index − This index includes a partition key and sort key, which may differ from the source table. It uses the label “global” due to the capability of queries/scans on the index to span all table data, and over all partitions.
Local Secondary Index − This index shares a partition key with the table, but uses a different sort key. Its “local” nature results from all of its partitions scoping to a table partition with identical partition key value.
The best type of index to use depends on application needs. Consider the differences between the two presented in the following table −
|Quality||Global Secondary Index||Local Secondary Index|
|Key Schema||It uses a simple or composite primary key.||It always uses a composite primary key.|
|Key Attributes||The index partition key and sort key can consist of string, number, or binary table attributes.||The partition key of the index is an attribute shared with the table partition key. The sort key can be string, number, or binary table attributes.|
|Size Limits Per Partition Key Value||They carry no size limitations.||It imposes a 10GB maximum limit on total size of indexed items associated with a partition key value.|
|Online Index Operations||You can spawn them at table creation, add them to existing tables, or delete existing ones.||You must create them at table creation, but cannot delete them or add them to existing tables.|
|Queries||It allows queries covering the entire table, and every partition.||They address single partitions through the partition key value provided in the query.|
|Consistency||Queries of these indices only offer the eventually consistent option.||Queries of these offer the options of eventually consistent or strongly consistent.|
|Throughput Cost||It includes throughput settings for reads and writes. Queries/scans consume capacity from the index, not the table, which also applies to table write updates.||Queries/scans consume table read capacity. Table writes update local indexes, and consume table capacity units.|
|Projection||Queries/scans can only request attributes projected into the index, with no retrievals of table attributes.||Queries/scans can request those attributes not projected; furthermore, automatic fetches of them occur.|
When creating multiple tables with secondary indexes, do it sequentially; meaning make a table and wait for it to reach ACTIVE state before creating another and again waiting. DynamoDB does not permit concurrent creation.
Each secondary index requires certain specifications −
Type − Specify local or global.
Name − It uses naming rules identical to tables.
Key Schema − Only top level string, number, or binary type are permitted, with index type determining other requirements.
Attributes for Projection − DynamoDB automatically projects them, and allows any data type.
Throughput − Specify read/write capacity for global secondary indexes.
The limit for indexes remains 5 global and 5 local per table.
You can access the detailed information about indexes with DescribeTable. It returns the name, size, and item count.
Note − These values updates every 6 hours.
In queries or scans used to access index data, provide the table and index names, desired attributes for the result, and any conditional statements. DynamoDB offers the option to return results in either ascending or descending order.
Note − The deletion of a table also deletes all indexes.