Partition key and sort key in AWS - Step-by-Step Execution

Process Flow - Partition key and sort key

Start: Insert Item

↓

Extract Partition Key

↓

Hash Partition Key

↓

Find Partition

↓

Check if Sort Key Exists?

No→Store Item in Partition

Yes↓

Sort Items in Partition by Sort Key

↓

Store Item in Sorted Order

↓

End

When adding data, DynamoDB uses the partition key to find the partition. If a sort key is present, it orders items within that partition by the sort key.

Execution Sample

AWS

PutItem({PartitionKey: 'User#123', SortKey: 'Order#456', Data: '...'});

This stores an item with partition key 'User#123' and sort key 'Order#456' in DynamoDB.

Process Table

Step	Action	Partition Key	Sort Key	Result
1	Receive item to store	User#123	Order#456	Item ready for processing
2	Extract partition key	User#123	Order#456	Partition key identified
3	Hash partition key	User#123	Order#456	Hash computed for partition placement
4	Locate partition	User#123	Order#456	Partition found based on hash
5	Check for sort key	User#123	Order#456	Sort key present
6	Sort items in partition	User#123	Order#456	Items ordered by sort key
7	Store item in sorted order	User#123	Order#456	Item stored successfully
8	End process	User#123	Order#456	Item available for queries

💡 Process ends after item is stored in the correct partition and sorted position.

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
PartitionKey	N/A	User#123	User#123	User#123	User#123
SortKey	N/A	Order#456	Order#456	Order#456	Order#456
PartitionHash	N/A	N/A	HashValue123	HashValue123	HashValue123
PartitionLocation	N/A	N/A	N/A	PartitionNode5	PartitionNode5

Key Moments - 3 Insights

Why do we hash the partition key before storing the item?

Hashing the partition key helps DynamoDB quickly find the right partition to store the item, as shown in step 3 of the execution_table.

What happens if there is no sort key?

If no sort key exists, the item is stored directly in the partition without sorting, as indicated by the branch in the concept_flow.

How does the sort key affect item storage?

The sort key orders items within the same partition, so items with the same partition key are sorted by the sort key before storage, as shown in steps 5 and 6.

Visual Quiz - 3 Questions

Look at the execution_table, what is the action at step 4?

A Hash partition key

B Store item in sorted order

C Locate partition

D Extract partition key

💡 Hint

Check the 'Action' column in execution_table row with Step '4'.

At which step does DynamoDB check if a sort key exists?

A Step 2

B Step 5

C Step 7

D Step 3

💡 Hint

Look for 'Check for sort key' in the execution_table.

If the sort key was missing, which step would be skipped?

A Step 6

B Step 4

C Step 2

D Step 7

💡 Hint

Refer to concept_flow where the branch skips sorting if no sort key.

Concept Snapshot

Partition key is used to find the partition by hashing.
Sort key orders items within the same partition.
Items with same partition key are stored together.
Without sort key, items are stored unordered in partition.
This design enables fast lookups and sorted queries.

Full Transcript

When you add an item to DynamoDB, it first looks at the partition key. It hashes this key to find the right partition where the item will live. If the item has a sort key, DynamoDB sorts all items in that partition by this key. This helps keep related items together and in order. If there is no sort key, the item is just stored in the partition without sorting. This process ensures quick access and organized storage.

Practice

1.

What is the main role of a partition key in AWS DynamoDB?

easy

A. It groups data into partitions for efficient storage and retrieval.

B. It sorts data within a partition in ascending order.

C. It encrypts the data before storing it.

D. It defines the backup schedule for the table.

Solution

1. Step 1: Understand partition key purpose

   The partition key is used to group data into partitions, which helps DynamoDB distribute and store data efficiently.

2. Step 2: Differentiate from sort key

   The sort key orders data inside each partition but does not group data across partitions.

3. Final Answer:

   It groups data into partitions for efficient storage and retrieval. -> Option A

4. Quick Check:

   Partition key = groups data [OK]

Hint: Partition key groups data, sort key orders it inside partitions [OK]

Common Mistakes:

• Confusing partition key with sort key
• Thinking partition key sorts data
• Assuming partition key controls backups

2.

Which of the following is the correct way to define a DynamoDB table with a partition key named UserId and a sort key named OrderDate in AWS CLI?

aws dynamodb create-table --table-name Orders --attribute-definitions AttributeName=UserId,AttributeType=S AttributeName=OrderDate,AttributeType=S --key-schema ...

easy

A. --key-schema AttributeName=UserId,KeyType=HASH AttributeName=OrderDate,KeyType=RANGE

B. --key-schema AttributeName=OrderDate,KeyType=HASH AttributeName=UserId,KeyType=RANGE

C. --key-schema AttributeName=UserId,KeyType=RANGE AttributeName=OrderDate,KeyType=HASH

D. --key-schema AttributeName=OrderDate,KeyType=RANGE AttributeName=UserId,KeyType=HASH

Solution

1. Step 1: Identify partition and sort key roles

   The partition key uses KeyType=HASH and the sort key uses KeyType=RANGE in DynamoDB key schema.

2. Step 2: Match keys to names

   UserId is the partition key (HASH), OrderDate is the sort key (RANGE).

3. Final Answer:

   --key-schema AttributeName=UserId,KeyType=HASH AttributeName=OrderDate,KeyType=RANGE -> Option A

4. Quick Check:

   Partition=HASH, Sort=RANGE [OK]

Hint: Partition key = HASH, sort key = RANGE in key schema [OK]

Common Mistakes:

• Swapping HASH and RANGE key types
• Mixing up partition and sort key names
• Using wrong attribute types

3.

Given a DynamoDB table with CustomerId as partition key and InvoiceDate as sort key, what will the following query return?

Query: KeyConditionExpression = "CustomerId = :cid AND InvoiceDate > :date"

Assuming :cid is '123' and :date is '2023-01-01'.

medium

A. All invoices for customer '123' regardless of date.

B. All invoices for customer '123' with dates after January 1, 2023.

C. All invoices for all customers with dates after January 1, 2023.

D. All invoices with dates before January 1, 2023.

Solution

1. Step 1: Understand KeyConditionExpression

   The query filters items where partition key CustomerId equals '123' and sort key InvoiceDate is greater than '2023-01-01'.

2. Step 2: Interpret the filter effect

   This returns all invoices for customer '123' with InvoiceDate after January 1, 2023.

3. Final Answer:

   All invoices for customer '123' with dates after January 1, 2023. -> Option B

4. Quick Check:

   Partition key = '123' AND sort key > '2023-01-01' [OK]

Hint: Partition key filters customer, sort key filters date range [OK]

Common Mistakes:

• Ignoring partition key filter
• Assuming query returns all customers
• Confusing greater than with less than

4.

What is wrong with this DynamoDB key schema definition?

--attribute-definitions AttributeName=OrderId,AttributeType=S AttributeName=OrderDate,AttributeType=S --key-schema AttributeName=OrderDate,KeyType=HASH AttributeName=OrderId,KeyType=RANGE

medium

A. Attribute names cannot contain uppercase letters.

B. Attribute types must be different for partition and sort keys.

C. KeyType values must both be HASH for composite keys.

D. Partition key and sort key are swapped; OrderId should be HASH, OrderDate RANGE.

Solution

1. Step 1: Check key roles

   Partition key must be HASH and sort key must be RANGE in key schema.

2. Step 2: Identify swapped keys

   OrderId should be the partition key (HASH), but here OrderDate is set as HASH and OrderId as RANGE, which is incorrect.

3. Final Answer:

   Partition key and sort key are swapped; OrderId should be HASH, OrderDate RANGE. -> Option D

4. Quick Check:

   Partition = HASH, Sort = RANGE order matters [OK]

Hint: Partition key always HASH, sort key always RANGE [OK]

Common Mistakes:

• Swapping HASH and RANGE key types
• Assuming attribute types must differ
• Thinking uppercase letters are invalid

5.

You want to design a DynamoDB table to store user activity logs. Each user can have multiple logs per day. Which key design is best to efficiently query all logs for a user on a specific day?

hard

A. Partition key: UserId, Sort key: ActivityDateTime

B. Partition key: ActivityDateTime, Sort key: UserId

C. Partition key: UserId_ActivityDate, Sort key: ActivityTime

D. Partition key: ActivityType, Sort key: UserId

Solution

1. Step 1: Understand query needs

   You want to query logs by user and by specific day efficiently.

2. Step 2: Design keys for efficient queries

   Combining UserId and ActivityDate as partition key groups logs per user per day. Using ActivityTime as sort key orders logs within that day.

3. Final Answer:

   Partition key: UserId_ActivityDate, Sort key: ActivityTime -> Option C

4. Quick Check:

   Composite partition key groups user-day logs [OK]

Hint: Combine user and date in partition key for day queries [OK]

Common Mistakes:

• Using ActivityDateTime as partition key alone
• Swapping partition and sort keys
• Not combining keys to match query pattern