Composite primary key in DynamoDB - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a composite primary key in DynamoDB?

A composite primary key in DynamoDB is made of two parts: a partition key and a sort key. Together, they uniquely identify each item in a table.

beginner

Why use a composite primary key instead of a simple primary key?

Using a composite primary key lets you store multiple related items with the same partition key but different sort keys. This helps organize data and query it efficiently.

beginner

In DynamoDB, what does the partition key do in a composite primary key?

The partition key decides which partition (storage unit) the data goes to. It groups items together for fast access.

beginner

What role does the sort key play in a composite primary key?

The sort key orders items within the same partition key. It lets you store and query multiple items with the same partition key but different sort keys.

intermediate

How does a composite primary key help with querying data in DynamoDB?

It allows you to find all items with the same partition key and filter or sort them by the sort key. This makes queries more flexible and efficient.

What two parts make up a composite primary key in DynamoDB?

A Index key and sort key

B Primary key and foreign key

C Hash key and range key

D Partition key and sort key

A composite primary key consists of a partition key and a sort key. (Note: Hash key and range key are older terms for partition and sort keys.)

What does the partition key determine in DynamoDB?

A Which partition stores the item

B The total number of items in the table

C The order of items within a partition

D The size of the item

The partition key decides which partition stores the item, helping distribute data.

Can two items in DynamoDB have the same partition key but different sort keys?

A Yes, if they have different sort keys

B No, partition keys must be unique

C Yes, but only if they are in different tables

D No, both keys must be unique together

Items can share the same partition key if their sort keys differ, allowing multiple related items.

What advantage does a composite primary key provide when querying data?

A It allows filtering by partition key only

B It speeds up writes but not reads

C It enables sorting and filtering within a partition

D It removes the need for indexes

The sort key lets you sort and filter items within the same partition key.

Which of these is NOT true about composite primary keys in DynamoDB?

A They uniquely identify each item in the table

B They allow multiple items with the same partition and sort key

C They consist of a partition key and a sort key

D They help organize data for efficient queries

Items cannot have the same partition key and sort key combination; that would not be unique.

Explain what a composite primary key is in DynamoDB and why it is useful.

Think about how two keys work together to organize and find data.

Describe how the partition key and sort key work together in a composite primary key.

Consider their roles in storing and retrieving data.

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