Hello everyone! In this article, I will try to explain indexing in DynamooDb.

What Is Indexing in DynamoDB?

Amazon DynamoDB provides fast access to items in a table by specifying primary key values. But if you want to fetch the data of attributes other than the primary key, indexing comes into the picture.

DynamoDb provides two types of indexing:

1. Global secondary index

2. Local secondary index

When you create a secondary index, you need to specify the attributes that will be projected into the index. DynamoDB provides three different options for this:

1. KEYS_ONLY: Each item in the index consists only of the table partition key and sort key values, plus the index key values. The KEYS_ONLY option results in the smallest possible secondary index.

2. INCLUDE: In addition to the attributes described in KEYS_ONLY, the secondary index will include other non-key attributes that you specify.

3. ALL: The secondary index includes all of the attributes from the source table. Because all of the table data is duplicated in the index, an ALL projection results in the largest possible secondary index.

Global Secondary Index in DynamoDB

This is an index with a partition key and a sort key that can be different from the base table. A global secondary index is very helpful when you need to query your data without a primary key.

• The primary key of a global secondary index can be partition key or composite (partition key and sort key).
• Global secondary indexes can be created at the same time that you create a table. You can also add a new global secondary index to an existing table or delete an existing global secondary index
• A global secondary index lets you query over the entire table and across all partitions.
• The index partition key and sort key (if present) can be any base table attributes of type string, number, or binary.
• With global secondary index queries or scans, you can only request the attributes that are projected into the index. DynamoDB will not fetch any attributes from the table.
• There are no size restrictions for global secondary indexes.

Let's create a global secondary index using CLI on the local index:

aws dynamodb create-table \
             --region=eu-west-1 \
             --endpoint-url http://localhost:8000 \
             --table-name users \
             --attribute-definitions \
                 AttributeName=id,AttributeType=S \
                 AttributeName=name,AttributeType=S \
                 AttributeName=age,AttributeType=S \
             --key-schema \
                 AttributeName=id,KeyType=HASH \
                 AttributeName=name,KeyType=RANGE \
             --provisioned-throughput ReadCapacityUnits=10,WriteCapacityUnits=10 \
             --global-secondary-indexes IndexName=Index,\
KeySchema=["{AttributeName=name,KeyType=HASH}","{AttributeName=id,KeyType=RANGE}"],\
Projection="{ProjectionType=INCLUDE ,NonKeyAttributes=["age"]}",\
ProvisionedThroughput="{ReadCapacityUnits=10,WriteCapacityUnits=10}"

Here, you can see that we created the global secondary index with the table users. If you will see table than in this table we have:

• Hash key: id

• Range key: name

But in the global secondary index, we changed it, and in the global secondary index, we have:

• Hash key: name

• Range key: id

So, when your query is not able to satisfy your table condition (primary key), you can create the global secondary index and easily search your data.

Local Secondary Index in DynamoDB

This is an index that has the same partition key as the base table, but a different sort key.

Some applications only need to query data using the base table's primary key; however, there may be situations where an alternate sort key would be helpful. To give your application a choice of sort keys, you can create one or more local secondary indexes on a table and issue query or scan requests against these indexes.

Every local secondary index automatically contains the partition and sort keys from its base table. You can optionally project non-key attributes into the index. When you query the index, DynamoDB can retrieve these projected attributes efficiently. When you query a local secondary index, the query can also retrieve attributes that are not projected into the index. DynamoDB will automatically fetch these attributes from the base table but at a greater latency and with higher provisioned throughput costs.

• The primary key of a local secondary index must be composite (partition key and sort key).
• Local secondary indexes are created at the same time that you create a table. You cannot add a local secondary index to an existing table, nor can you delete any local secondary indexes that currently exist.
• When you query a local secondary index, you can choose either eventual consistency or strong consistency.
• If you query or scan a local secondary index, you can request attributes that are not projected into the index. DynamoDB will automatically fetch those attributes from the table.
• Queries or scans on a local secondary index consume read capacity units from the base table. When you write to a table, its local secondary indexes are also updated; these updates consume write capacity units from the base table.

Now, let's create the local secondary index with users table:

aws dynamodb create-table \
             --region=eu-west-1 \
             --endpoint-url http://localhost:8000 \
             --table-name users \
             --attribute-definitions \
                 AttributeName=id,AttributeType=S \
                 AttributeName=name,AttributeType=S \
                 AttributeName=age,AttributeType=S \
             --key-schema \
                 AttributeName=id,KeyType=HASH \
                 AttributeName=name,KeyType=RANGE \
             --provisioned-throughput ReadCapacityUnits=10,WriteCapacityUnits=10 \
             --local-secondary-indexes IndexName=localIndex,\
KeySchema=["{AttributeName=id,KeyType=HASH}","{AttributeName=age,KeyType=RANGE}"],\
Projection="{ProjectionType=INCLUDE ,NonKeyAttributes=["age"]}"

Here, you can see that we created the local secondary index where we have the same hash key (id) but different range key (age).