DynamoDB Keys - Everything You Need To Know

What are keys in DynamoDB?

Keys, like in many other NoSQL and SQL databases, act as a unique identifier of a record or item. If you want to access an item in the DynamoDB table fast (with O(1) complexity), you'll need to know its key. In DynamoDB, there are two types of primary keys: the partition key and the composite key.

Different DynamoDB Key Types

• Primary Simple Key
• Primary Composite Key
• Global Secondary Index
• Local Secondary Index
• Hot Key

DynamoDB Simple Key

DynamoDB simple key consists only of one value - the partition/hash key. Each record needs to have one of these, and it needs to be unique. With a simple key, DynamoDB essentially works just like a Key-Value store. You lose the ability to perform a Query; to fetch data from a table with such a key, you can use Scan or GetItem operation.

DynamoDB Composite Key

Another option is to use a composite key, which is composed of a partition key, also known as a hash key, and a sort key, also known as a range key. Choosing this option allows items to share the same partition/hash key, but the combination of hash key and sort key must be unique.

As a consequence, you can now use Query, which allows fetching a collection of items with the same partition key. Thanks to that (and GSIs + LSIs, more on that later), our Key-Value store becomes much more sophisticated because it allows for more complex query access patterns.

DynamoDB Global Secondary Index (GSI)

But what if you want to fetch an item without knowing its key, and you only know another attribute, let's say authorId of the Book? If you index that attribute using a Global Secondary Index, you don't have to use the scan operation.

With GSIs, you can use GetItem and query operations using non-primary key attributes. In the background, DynamoDB keeps each of the GSIs automatically in sync with the base table. When a mutation is made against the table, any of the global secondary indexes on that table are updated asynchronously in an eventually consistent manner.

DynamoDB Local Secondary Index (LSI)

Another variation of the secondary key is the Local Secondary Index. It works similarly to the GSI but with one difference. In LSIs, the partition key must remain the same as the primary key's partition key. However, you can change the sort key. This is useful if you need to be able to fetch a collection of items sorted based on more than one attribute, e.g., updatedAt and createdAt.

Generally speaking, you should rather avoid LSIs for two reasons:

• Unlike GSIs, you cannot update or delete them after table creation. All LSIs must be specified on table creation. This makes them rather inflexible.
• If you create a table with a Local Secondary Index, that table is going to have a 10GB size limit per partition key value.

DynamoDB Hot Key

Choosing the right keys is essential to keep your DynamoDB tables fast and performant. If your application will not access the keyspace uniformly, you might encounter the hot partition problem also known as hot key.

What is a hot key? It's an item with the key that is accessed much more frequently than the rest of the items. It causes an intensified load on one of the partitions, while others are accessed much less often.

DynamoDB Keys Best Practices

• Favor composite keys over simple keys. They offer more functionality without downsides. They enable you to sort within one partition and enable filtering without using FilterExpressions.
• Use keys with high cardinality to avoid hot keys/partitions problems. Isolate frequently accessed items so they won't reside on the same partition. This will reduce the likelihood of throttling.
• Plan your access patterns first, so you'll know what GSIs to create. This is especially important if you're going with Single-Table design.
• Maintain as few GSIs as possible. Remember that each GSI incurs costs. For most applications, three GSIs are enough.
• Prefer generic GSI attribute names, something like gsi1_pk, gsi2_sk, etc. This way they'll fit for multiple use cases, and you'll be able to adapt to the new business requirements without altering your table definition.
• Favor GSIs (Global Secondary Indexes) over LSIs (Local Secondary Indexes). LSIs have a maximum size of collection - 10 GB. After that, you'll start getting ItemCollectionSizeLimitExceededException. Moreover, you cannot update or delete them after table creation while you can do so with GSIs.

Frequently Asked Questions

What can be a key in DynamoDB?

From all of the DynamoDB Types, only String, Binary, and Number can be used as the key attribute type.

Is it possible to change the partition key in DynamoDB?

No. Once the table is set up, you cannot modify its Key Schema. You can only provision a new table, move data there, and then remove the first table.

Can DynamoDB sort key be updated?

No. Similarly to the partition key, the sort key cannot be changed after the table is provisioned.

Are DynamoDB keys case sensitive?

Yes. All the attribute names, values, and keys are case sensitive. E.g., ID is different than id.

How do I use numeric id for DynamoDB key?

Yes! Number is a supported type as DynamoDB key.

What is the maximum length of sort key in DynamoDB?

The minimum length of a partition key and sort key is 1 byte, while the maximum length is 2048 bytes (2048 characters when using String type).

Should every attribute be a key in DynamoDB?

Technically, it is possible by adding multiple global secondary indexes, which will cover all the attributes. However, this is highly inefficient and not cost-effective.

DynamoDB query without key, is that possible?

No. You cannot run a query without specifying the partition key. If you don't know the partition key of the item you're looking for, you either need to create a global secondary index on a known attribute or use Scan.

Additional Considerations

When designing your DynamoDB tables, it's crucial to consider the read and write capacity units (RCUs and WCUs) that your keys will consume. Hot keys can lead to throttling, which can degrade the performance of your application. Additionally, understanding the eventual consistency model of DynamoDB is important when working with GSIs, as there might be a slight delay in the propagation of changes from the base table to the index. Lastly, always monitor your DynamoDB tables using AWS CloudWatch to keep track of performance metrics and adjust your design as needed.