Amazon DynamoDB in Practice: Access Patterns, Keys, and Indexes
Learn how to define access patterns, choose keys, and use secondary indexes in Amazon DynamoDB through a practical example involving customer orders.
Amazon DynamoDB in Practice: Access Patterns, Keys, and Indexes
After publishing my previous article about Amazon DynamoDB, I received some interesting comments and suggestions, so I decided to write this follow-up to explore some of these concepts in more depth.
Starting with Access Patterns
One of the main differences between relational databases and DynamoDB lies in how we approach data modeling.
In a relational database, it is common to organize data into related tables and use SQL queries to combine information as needed. With DynamoDB, planning starts with a different question: how does the application need to access this data?
Before defining the table structure, it is important to list the queries the application will need to perform. This step is known as defining access patterns.
Let's consider an e-commerce application that stores customer orders. Some of its requirements might include:
- Retrieving a specific order by its identifier.
- Retrieving all orders for a customer, from newest to oldest.
Although both queries involve orders, each has a different requirement. This is precisely what influences the table design.
Partition Key and Sort Key in Practice
In DynamoDB, the Partition Key is the key used to identify and distribute items within a table. When present, the Sort Key allows items sharing the same Partition Key to be organized and queried according to their sort key values.
To retrieve a customer's orders in reverse chronological order, for example, we could use a table with the following structure:
- Partition Key:
CustomerId - Sort Key:
OrderDate
Each order would contain the customer's identifier and the order date as part of its composite primary key.
With this structure, the application can use a
Query operation to retrieve orders for a specific customer and sort them by date, from newest to oldest, provided the dates are stored in a format that supports chronological ordering.But what if we also need to retrieve an order directly by its
OrderId?In this case, the existing structure does not allow us to query an order directly using only its identifier, because
OrderId is not part of the primary key. We can consider alternatives, such as using a Global Secondary Index (GSI) or choosing a data model that supports both access patterns.This decision depends on the required queries, how frequently each operation is performed, and the associated costs.
When Does a Global Secondary Index (GSI) Make Sense?
A Global Secondary Index, or GSI, allows us to query the same data using a different key structure from the table's primary key.
Imagine that, in addition to querying orders by customer, the application needs to find all orders with a particular status, such as
PENDING.If this query is important to the application's functionality, a GSI can allow orders to be queried by status without requiring the application to scan every item in the table.
However, creating an additional index also has consequences. DynamoDB must keep the index updated as relevant data changes. This can increase write capacity consumption and costs, in addition to requiring extra storage.
For this reason, there is no need to create a GSI for every imaginable query. The goal is to evaluate which access patterns actually need to be supported and whether the index's benefits justify its costs.
A GSI can be especially useful when there is a frequent query requirement that cannot be efficiently supported by the existing primary key.
How Do These Decisions Affect the Design?
Data modeling in DynamoDB involves balancing different requirements. One structure may simplify certain queries, while another may better support different access patterns.
Before defining keys and indexes, it is worth considering:
- Which queries the application actually needs to perform.
- How frequently each query will be executed.
- The volume of data that will be stored and queried.
- Whether the benefits of an additional index justify its write and storage costs.
This planning helps prevent designs that work well for one query but make other important operations more difficult.
Working with Amazon DynamoDB requires us to think beyond data structure alone. We need to understand how the application will use the information and how choices involving keys and indexes can affect performance and costs.
Defining access patterns before modeling the table is a good starting point. From there, we can evaluate which keys make sense, when a secondary index is necessary, and what trade-offs each choice involves.
Rather than simply creating a table, the goal is to build a structure that meets the application's actual needs.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article