Why Composite primary key in DynamoDB? - Purpose & Use Cases

The Big Idea

What if one key isn't enough to find exactly what you need? Discover how combining keys solves this!

The Scenario

Imagine you have a big notebook where you write down all your friends' phone numbers. But some friends have the same name, so when you look for a number, you get confused and sometimes write the wrong one.

The Problem

Using just one name to find a phone number is slow and risky. You might call the wrong friend or waste time flipping through pages to find the right one. It's easy to make mistakes and hard to keep things organized.

The Solution

A composite primary key is like using both your friend's name and their city to find their phone number. This way, you have two pieces of information working together to find exactly the right friend quickly and without mistakes.

Before vs After

✗ Before

Table with only 'Name' as partition key
Find phone by name only

✓ After

Table with 'Name' as partition key and 'City' as sort key (composite primary key)
Find phone by name and city

What It Enables

It lets you uniquely identify and quickly find items even when one piece of information alone is not enough.

Real Life Example

In an online store, many customers can have the same first name. Using a composite key like 'CustomerID' and 'OrderID' helps find the exact order for the right customer without confusion.

Key Takeaways

Composite keys combine two attributes to uniquely identify data.

This prevents confusion when one attribute alone is not unique.

It makes searching and organizing data faster and safer.

Practice

1.

What is a composite primary key in DynamoDB?

easy

A. A key that allows duplicate items

B. A key made of only one attribute

C. A key made of two attributes: PartitionKey and SortKey

D. A key used only for indexing

Solution

1. Step 1: Understand primary key types in DynamoDB

   DynamoDB supports simple primary keys (one attribute) and composite primary keys (two attributes).

2. Step 2: Identify composite primary key components

   A composite primary key consists of a PartitionKey and a SortKey to uniquely identify items.

3. Final Answer:

   A key made of two attributes: PartitionKey and SortKey -> Option C

4. Quick Check:

   Composite primary key = PartitionKey + SortKey [OK]

Hint: Composite key always has PartitionKey and SortKey [OK]

Common Mistakes:

• Thinking composite key has only one attribute
• Confusing composite key with secondary indexes
• Believing composite key allows duplicates

2.

Which of the following is the correct way to define a composite primary key in DynamoDB table creation?

{
  "TableName": "Orders",
  "KeySchema": [
    {"AttributeName": "CustomerId", "KeyType": "HASH"},
    {"AttributeName": "OrderDate", "KeyType": "RANGE"}
  ]
}

easy

A. Use KeyType RANGE for both attributes

B. Use KeyType RANGE for PartitionKey and HASH for SortKey

C. Use KeyType HASH for both attributes

D. Use KeyType HASH for PartitionKey and RANGE for SortKey

Solution

1. Step 1: Recall KeyType meanings

   In DynamoDB, HASH means PartitionKey and RANGE means SortKey.

2. Step 2: Match KeyType to attributes

   PartitionKey must be HASH and SortKey must be RANGE for composite keys.

3. Final Answer:

   Use KeyType HASH for PartitionKey and RANGE for SortKey -> Option D

4. Quick Check:

   PartitionKey=HASH, SortKey=RANGE [OK]

Hint: HASH = PartitionKey, RANGE = SortKey in KeySchema [OK]

Common Mistakes:

• Swapping HASH and RANGE roles
• Using same KeyType for both keys
• Confusing attribute names with KeyType

3.

Given a DynamoDB table with composite primary key (UserId as PartitionKey, Timestamp as SortKey), what will this query return?

{
  "TableName": "UserActivity",
  "KeyConditionExpression": "UserId = :uid and Timestamp > :time",
  "ExpressionAttributeValues": {
    ":uid": {"S": "user123"},
    ":time": {"N": "1609459200"}
  }
}

medium

A. All activities of user123 with Timestamp greater than 1609459200

B. All activities of all users with Timestamp greater than 1609459200

C. All activities of user123 regardless of Timestamp

D. Syntax error due to missing SortKey in query

Solution

1. Step 1: Understand KeyConditionExpression

   It filters items by PartitionKey equality and SortKey condition.

2. Step 2: Analyze the query conditions

   UserId = :uid restricts to user123; Timestamp > :time filters timestamps after 1609459200.

3. Final Answer:

   All activities of user123 with Timestamp greater than 1609459200 -> Option A

4. Quick Check:

   PartitionKey + SortKey condition filters items [OK]

Hint: PartitionKey = value AND SortKey condition filters items [OK]

Common Mistakes:

• Thinking query returns all users' data
• Ignoring SortKey condition
• Assuming syntax error without SortKey equality

4.

What is wrong with this DynamoDB query using composite primary key (UserId as PartitionKey, OrderId as SortKey)?

{
  "TableName": "Orders",
  "KeyConditionExpression": "OrderId = :oid",
  "ExpressionAttributeValues": {
    ":oid": {"S": "order789"}
  }
}

medium

A. PartitionKey UserId is missing in KeyConditionExpression

B. SortKey OrderId cannot be used in KeyConditionExpression

C. ExpressionAttributeValues syntax is incorrect

D. TableName is invalid

Solution

1. Step 1: Recall query requirements for composite keys

   Queries must specify PartitionKey equality in KeyConditionExpression.

2. Step 2: Check the given query

   Only SortKey OrderId is used; PartitionKey UserId is missing, causing error.

3. Final Answer:

   PartitionKey UserId is missing in KeyConditionExpression -> Option A

4. Quick Check:

   PartitionKey must be in query condition [OK]

Hint: Always include PartitionKey equality in query [OK]

Common Mistakes:

• Using only SortKey in query condition
• Assuming SortKey alone can identify items
• Ignoring required PartitionKey in queries

5.

You want to store blog posts in DynamoDB. Each post has a AuthorId and a PostDate. You want to quickly find all posts by an author sorted by date. Which composite primary key design is best?

hard

A. PartitionKey: PostDate, SortKey: AuthorId

B. PartitionKey: AuthorId, SortKey: PostDate

C. PartitionKey: AuthorId only, no SortKey

D. PartitionKey: PostDate only, no SortKey

Solution

1. Step 1: Identify query pattern

   You want to find all posts by an author, sorted by date.

2. Step 2: Choose PartitionKey and SortKey accordingly

   PartitionKey should be AuthorId to group posts by author; SortKey should be PostDate to sort posts by date.

3. Final Answer:

   PartitionKey: AuthorId, SortKey: PostDate -> Option B

4. Quick Check:

   Group by author, sort by date = AuthorId + PostDate [OK]

Hint: PartitionKey groups, SortKey sorts related items [OK]

Common Mistakes:

• Swapping PartitionKey and SortKey roles
• Using only one key losing sorting ability
• Choosing SortKey that doesn't support query pattern