Terraform DynamoDB: Indexing All Attributes for Optimal Performance

• Introduction
• Step-by-Step Guide
• Code Example
• Additional Notes
• Summary
• Conclusion
• References

DynamoDB enforces a strict requirement that all attributes in a table must be part of either the primary key or a secondary index. This design is fundamental to DynamoDB's performance as it uses these keys and indexes to locate data efficiently. When setting up a DynamoDB table using Terraform, you are only required to define the primary key, which consists of a partition key and an optional sort key, and any necessary secondary indexes for your specific query patterns. An error message stating "all attributes must be indexed" arises when you attempt to create a table containing attributes that are not part of any key or index. To address this, you should first pinpoint the attributes not included in any key or index. Next, determine whether you need to query these attributes directly. If direct querying is required, create a secondary index incorporating these attributes. You have the choice between Global Secondary Indexes (GSIs) and Local Secondary Indexes (LSIs) based on your access patterns and data distribution. If you don't need to query these attributes directly, you can disregard the error. DynamoDB will continue to store these attributes, but you won't have the ability to query them directly. Keep in mind that adding indexes has implications for both cost and write performance, so it's best to index only the attributes essential for your query needs.

DynamoDB requires all attributes to be part of either the primary key or a secondary index. This is because DynamoDB uses these keys and indexes to efficiently access and query data.

When defining a DynamoDB table in Terraform, you don't need to explicitly index every attribute. You only need to define the primary key (partition key and optional sort key) and any secondary indexes you require for your queries.

If you're encountering an error stating "all attributes must be indexed," it means you're trying to create a table with attributes that are not included in any key or index.

To resolve this:

1. Identify the attributes not included in any key or index.
2. Decide if you need to query these attributes directly.
   • If yes, create a secondary index that includes these attributes. You can choose between Global Secondary Indexes (GSIs) and Local Secondary Indexes (LSIs) based on your access pattern and data distribution needs.
   • If no, you can safely ignore the error. DynamoDB will still store these attributes, but you won't be able to directly query them.

Remember that adding indexes impacts cost and write performance, so only index the attributes you need for querying.

The code demonstrates how to create a DynamoDB table using Terraform. It showcases three scenarios: creating a table without secondary indexes (which results in an error), creating a table with a Global Secondary Index (GSI) for querying by author, and creating a table with a Local Secondary Index (LSI) for querying by publication year within a specific book ID. The examples highlight the importance of indexes for efficient querying and demonstrate how to configure them using Terraform.

Scenario: Let's say we're building a table to store information about books.

Attributes:

• bookId (string): Unique identifier for each book (partition key)
• title (string): Title of the book
• author (string): Author of the book
• genre (string): Genre of the book
• publicationYear (number): Year the book was published

1. Table without secondary indexes (Error scenario):

resource "aws_dynamodb_table" "books_table" {
  name           = "books"
  billing_mode   = "PAY_PER_REQUEST"
  hash_key       = "bookId"

  attribute {
    name = "bookId"
    type = "S"
  }

  attribute {
    name = "title"
    type = "S"
  }

  attribute {
    name = "author"
    type = "S"
  }

  attribute {
    name = "genre"
    type = "S"
  }

  attribute {
    name = "publicationYear"
    type = "N"
  }
}

This code will throw an error because author, genre, and publicationYear are not part of any key or index.

2. Table with a Global Secondary Index (GSI):

resource "aws_dynamodb_table" "books_table" {
  name           = "books"
  billing_mode   = "PAY_PER_REQUEST"
  hash_key       = "bookId"

  attribute {
    name = "bookId"
    type = "S"
  }

  attribute {
    name = "title"
    type = "S"
  }

  attribute {
    name = "author"
    type = "S"
  }

  attribute {
    name = "genre"
    type = "S"
  }

  attribute {
    name = "publicationYear"
    type = "N"
  }

  global_secondary_index {
    name               = "author_index"
    hash_key           = "author"
    projection_type    = "ALL" # Project all attributes to the index
  }
}

This code defines a GSI named author_index that allows querying books by author.

3. Table with a Local Secondary Index (LSI):

resource "aws_dynamodb_table" "books_table" {
  name           = "books"
  billing_mode   = "PAY_PER_REQUEST"
  hash_key       = "bookId"
  range_key      = "publicationYear"

  attribute {
    name = "bookId"
    type = "S"
  }

  attribute {
    name = "title"
    type = "S"
  }

  attribute {
    name = "author"
    type = "S"
  }

  attribute {
    name = "genre"
    type = "S"
  }

  attribute {
    name = "publicationYear"
    type = "N"
  }

  local_secondary_index {
    name               = "publicationYear_index"
    range_key           = "publicationYear"
    projection_type    = "INCLUDE"
    non_key_attributes = ["title", "author"] # Only project specific attributes
  }
}

This code defines an LSI named publicationYear_index that allows querying books by publicationYear within a specific bookId. It also demonstrates projecting only specific attributes to the index.

Remember to choose the appropriate index type (GSI or LSI) and projection type based on your access patterns and data distribution needs.

• DynamoDB's indexing philosophy: Unlike traditional relational databases where you can query any column even without an index (though it might be slow), DynamoDB requires an index for efficient data access. This design prioritizes speed and scalability for large datasets.
• Impact of not indexing: If you choose not to index an attribute, you essentially make it hidden for direct queries. You can still store and retrieve it as part of an item, but you cannot use it as a filter in your queries.
• Choosing the right index:
  • GSIs: Offer flexibility as they can have a different partition key and sort key than the table's primary key. Useful for queries spanning the entire dataset.
  • LSIs: Tied to the table's partition key. Efficient for queries within a specific partition key value.
• Projection types:
  • ALL: Projects all table attributes to the index. Simpler but potentially increases storage costs.
  • INCLUDE: Projects only specified attributes. Offers finer control over index size and cost.
• Terraform best practices:
  • Use descriptive names for indexes to improve code readability.
  • Clearly document the purpose of each index in your Terraform code.
• Alternatives to consider:
  • If you need to query on many attributes without creating numerous indexes, consider using DynamoDB Streams and AWS Lambda to build a custom indexing and querying mechanism.
  • For complex querying needs beyond DynamoDB's capabilities, explore purpose-built database solutions like Amazon Aurora or Amazon Relational Database Service (RDS).
• Real-world analogy: Imagine a library where books are only searchable by title (primary key). To find books by author or genre, you need separate card catalogs (indexes) that list books by those criteria.

In conclusion, understanding DynamoDB's indexing requirement is crucial for efficient data retrieval. When using Terraform to manage your DynamoDB tables, ensure all attributes are either part of the primary key or a secondary index. If you encounter the "all attributes must be indexed" error, carefully analyze your data access patterns to determine if creating a GSI or LSI is necessary. Remember, while indexes enhance query performance, they also impact cost and write speed. Therefore, a well-defined indexing strategy, based on your application's specific needs, is essential for optimal DynamoDB performance.

• Don't Enforce DynamoDB's Indexes Creation · Issue #4123 ... | Terraform Version $ terraform -v Terraform v0.11.6 + provider.aws v1.14.0 Affected Resource(s) aws_dynamodb_table Terraform Configuration Files resource "aws_dynamodb_table" "table_test" { name = "...
• [Solved] DynamoDB Error All Attributes Must Be Indexed | This is a common error in DynamoDB -- get the solution for DynamoDB Error All Attributes Must Be Indexed
• Terraform seems not to support multiple attributes in a DynamoDB ... | This issue was originally opened by @jgryszko as hashicorp/terraform#12229. It was migrated here as part of the provider split. The original body of the issue is below. Hi, It looks like multiple a...
• Terraform & AWS DynamoDB. Hey guys! So I wanted to keep the ... | Hey guys! So I wanted to keep the ball rolling with basic Terraform stuff and I have been loving the feedback concerning workflows and work…
• Manage AWS DynamoDB scale | Terraform | HashiCorp Developer | Jul 8, 2022 ... │ Error: 1 error occurred: │ * all attributes must be indexed. ... Terraform configuration unless you will also use it in an index. Apply ...
• dynamo (terraform) | Reference cloudposse/terraform-aws-dynamodb https://github.com/cloudposse/terraform-aws-dynamodb/blob/master/main.tf
• aws_dynamodb_table | Resources | hashicorp/aws | Terraform ... | ... list of attributes to project into the index. These do not need to be defined as attributes on the table. projection_type - (Required) One of ALL , INCLUDE ...
• DynamoDB only useful if partition key value known in advance? : r/aws | Posted by u/katsucats - 29 votes and 49 comments
• CreateTable - Amazon DynamoDB | The total count of attributes provided in NonKeyAttributes , summed across all of the secondary indexes, must not exceed 100. If you project the same attribute ...