DynamoDB Composite Key - The Ultimate Guide [w/ Code Examples]

What is a Composite Key in DynamoDB?

A composite key in DynamoDB is made up of both the partition key and the sort key. Unlike other attributes, the composite key does not actually exist within the item. It is an abstract concept that can be thought of as a combination of the partition key and sort key. Therefore, it will not be visible or returned in the item itself. When you have a sort key, you will always have a composite key.

When you have a composite key on your DynamoDB Table, that will be considered the primary key. In simpler terms, this means when you have a sort key set on your table, all Get, Update, and Delete item commands must include both the partition key and sort key. This is because the partition key is no longer considered unique; the composite key is considered unique, and therefore you need both elements to identify the specific item you are referring to.

Why Do I Need a Composite Key in DynamoDB?

A composite key allows you to further query your data in an efficient manner. While you can query just based on the partition key, sometimes your partition will contain many items, which would start to degrade the performance of your queries. By adding a sort key, you can further query your data in a more efficient manner.

When querying, you must specify the partition key equal to something. However, the power of the composite key is that you can further filter the results by the sort key with more flexible comparison operations (greater than, less than, begins with, etc.). This allows for more granular and efficient data retrieval, especially in large datasets.

The Best Practices You Should Follow For DynamoDB Composite Keys

As with other keys, it is critical that you define your keys correctly. Dynobase has a world-class Single Table Design Tool that can help you visualize access patterns and how to design your keys in an optimal way based on your access patterns. With this tool, you can see exactly how queries will interact with your data based on the key values you define.

When designing your composite keys, consider the access patterns of your application. Ensure that the partition key distributes data evenly across partitions to avoid hot partitions, and use the sort key to enable efficient querying and sorting of data within each partition.

Composite Key vs Other Key Types

Composite Key vs Primary Key

If you are using the composite key on a DynamoDB Table itself, it is considered the primary key for the table. However, if you are using the composite key on a global secondary index (GSI), it is not considered the primary key for the table but rather for the index.

Composite Key vs Partition Key

The composite key is made up of both the partition key and sort key. It only applies if you have a sort key on your table. If you do not have a sort key, then you do not have a composite key. The partition key alone can be used as the primary key in such cases, but it limits the querying capabilities compared to a composite key.

Working with Composite Key (Code Examples)

Create Composite Key

Creating a composite key is as simple as defining both the partition key and the sort key on the item you add to your table.

DynamoDBClient.putItem({
    "TableName": "myTable",
    "Item": {
        "pk": {
            "S": "myPartitionKey"
        },
        "sk": {
            "S": "mySortKey"
        },
        "email": {
            "S": "test@test.com"
        }
    }
})
DynamoDBClient.putItem({
    "TableName": "myTable",
    "Item": {
        "pk": {
            "S": "myPartitionKey"
        },
        "sk": {
            "S": "mySortKey"
        },
        "email": {
            "S": "test@test.com"
        }
    }
})

Query on Composite Key

DynamoDBClient.query({
    "TableName": "myTable",
    "KeyConditionExpression": "#pk = :pk",
    "ExpressionAttributeNames": {
        "#pk": "pk"
    },
    "ExpressionAttributeValues": {
        ":pk": "myPartitionKey"
    }
})
DynamoDBClient.query({
    "TableName": "myTable",
    "KeyConditionExpression": "#pk = :pk",
    "ExpressionAttributeNames": {
        "#pk": "pk"
    },
    "ExpressionAttributeValues": {
        ":pk": "myPartitionKey"
    }
})

This will query your database and return all/multiple items with the partition key (pk) attribute equal to myPartitionKey.

Get Item by Composite Key

DynamoDBClient.getItem({
    "TableName": "myTable",
    "Key": {
        "pk": {
            "S": "myPartitionKey"
        },
        "sk": {
            "S": "mySortKey"
        }
    }
})
DynamoDBClient.getItem({
    "TableName": "myTable",
    "Key": {
        "pk": {
            "S": "myPartitionKey"
        },
        "sk": {
            "S": "mySortKey"
        }
    }
})

This will get a single item where the partition key (pk) attribute is equal to myPartitionKey, and the sort key (sk) attribute is equal to mySortKey. Remember, the composite key is unique, so only a single item can ever exist in your table that matches this key.

You cannot query on just the partition key if you have a composite key. You must always include both the entire composite key. If you want to query just based on the partition key, it can lead to many items being returned, and therefore you must use the Query on Composite Key code sample above.

Frequently Asked Questions

How to store a composite key in DynamoDB?

You can store a composite key in DynamoDB by defining both the partition key and sort key on the item you add to your table.

Can I create a DynamoDB composite key using 3 attributes?

You cannot create a DynamoDB composite key using 3 attributes/columns. You can, however, set your application to combine multiple attributes into a single field and use that as your partition key or sort key. However, this functionality is not built into DynamoDB and would all be handled at your application level.

Can a DynamoDB composite key be a primary key?

Yes. If you have a composite key on your DynamoDB Table itself, it will be considered the primary key.

Additional Considerations for Composite Keys

When designing your DynamoDB table with composite keys, it's important to consider the scalability and performance implications. DynamoDB automatically partitions your data across multiple servers based on the partition key. Therefore, choosing a partition key that ensures an even distribution of data is crucial to avoid hot partitions, which can lead to throttling and degraded performance. Additionally, the sort key should be chosen to optimize query patterns, allowing for efficient data retrieval and sorting within each partition. Understanding your application's access patterns and designing your keys accordingly can significantly enhance the performance and scalability of your DynamoDB tables.