Composite primary key in DynamoDB - Mini Project: Build & Apply

Create a DynamoDB Table with Composite Primary Key

📖 Scenario: You are building a simple database for an online bookstore. Each book can have multiple editions, and you want to store information about each edition separately. To uniquely identify each edition, you will use a composite primary key in DynamoDB.

🎯 Goal: Create a DynamoDB table named Books with a composite primary key consisting of ISBN as the partition key and Edition as the sort key.

📋 What You'll Learn

Create a DynamoDB table named Books

Use ISBN as the partition key (string type)

Use Edition as the sort key (number type)

Add an attribute Title (string type) to store the book title

💡 Why This Matters

🌍 Real World

Composite primary keys help uniquely identify items in databases where a single attribute is not enough, such as different editions of the same book.

💼 Career

Understanding composite keys is essential for designing efficient NoSQL databases like DynamoDB, commonly used in cloud applications.

1

Define the Table Name and Partition Key

Create a variable called table_name and set it to the string 'Books'. Then create a dictionary called key_schema with one entry: a dictionary with AttributeName set to 'ISBN' and KeyType set to 'HASH'.

DynamoDB

# Create table_name and key_schema variables
# Your code here

Hint

The partition key is called the HASH key in DynamoDB. Use a list with one dictionary for key_schema.

2

Add the Sort Key to the Key Schema

Add a second dictionary to the key_schema list with AttributeName set to 'Edition' and KeyType set to 'RANGE' to define the sort key.

DynamoDB

table_name = 'Books'
key_schema = [{
    'AttributeName': 'ISBN',
    'KeyType': 'HASH'
}]
# Add the sort key dictionary to key_schema
# Your code here

Hint

The sort key is called the RANGE key in DynamoDB. Add it as the second item in the key_schema list.

3

Define Attribute Definitions

Create a list called attribute_definitions with two dictionaries: one for ISBN with AttributeType set to 'S' (string), and one for Edition with AttributeType set to 'N' (number).

DynamoDB

table_name = 'Books'
key_schema = [{
    'AttributeName': 'ISBN',
    'KeyType': 'HASH'
}, {
    'AttributeName': 'Edition',
    'KeyType': 'RANGE'
}]
# Define attribute_definitions list
# Your code here

Hint

Attribute types use 'S' for string and 'N' for number in DynamoDB.

4

Add Table Creation Parameters

Create a dictionary called table_params with keys: TableName set to table_name, KeySchema set to key_schema, AttributeDefinitions set to attribute_definitions, and BillingMode set to 'PAY_PER_REQUEST'.

DynamoDB

table_name = 'Books'
key_schema = [{
    'AttributeName': 'ISBN',
    'KeyType': 'HASH'
}, {
    'AttributeName': 'Edition',
    'KeyType': 'RANGE'
}]

attribute_definitions = [{
    'AttributeName': 'ISBN',
    'AttributeType': 'S'
}, {
    'AttributeName': 'Edition',
    'AttributeType': 'N'
}]

# Create table_params dictionary
# Your code here

Hint

Use PAY_PER_REQUEST billing mode for simplicity.

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