Partition key distribution in DynamoDB - Mini Project: Build & Apply

Partition Key Distribution in DynamoDB

📖 Scenario: You are building a simple DynamoDB table to store user orders for an online store. To keep the database fast and balanced, you need to choose a good partition key that spreads the data evenly.

🎯 Goal: Create a DynamoDB table with a partition key that distributes user orders evenly across partitions. You will define the table schema, set a partition key, and add sample items to see how the key affects data distribution.

📋 What You'll Learn

Create a DynamoDB table named Orders with a partition key called OrderID of type string.

Add a variable sample_orders containing 5 orders with unique OrderID values.

Write a query to retrieve all orders with a specific OrderID.

Add a secondary index on CustomerID to allow queries by customer.

💡 Why This Matters

🌍 Real World

Good partition key design helps DynamoDB distribute data evenly, improving speed and scalability for real online stores or apps.

💼 Career

Understanding partition keys and indexes is essential for database roles working with NoSQL databases like DynamoDB.

1

Create the DynamoDB table schema

Create a DynamoDB table named Orders with a partition key called OrderID of type string. Use the AWS SDK syntax to define the table schema in a variable called table_schema.

DynamoDB

table_schema = {
    # Your code here
}

Hint

Define table_schema as a dictionary with keys TableName, KeySchema, AttributeDefinitions, and ProvisionedThroughput. The partition key is OrderID of type string.

2

Add sample orders data

Create a list called sample_orders with 5 dictionaries. Each dictionary should have keys OrderID (string), CustomerID (string), and Amount (number). Use these exact OrderID values: "O1001", "O1002", "O1003", "O1004", "O1005".

DynamoDB

table_schema = {
    'TableName': 'Orders',
    'KeySchema': [
        {'AttributeName': 'OrderID', 'KeyType': 'HASH'}
    ],
    'AttributeDefinitions': [
        {'AttributeName': 'OrderID', 'AttributeType': 'S'}
    ],
    'ProvisionedThroughput': {
        'ReadCapacityUnits': 5,
        'WriteCapacityUnits': 5
    }
}

sample_orders = [
    # Your code here
]

Hint

Make a list of 5 dictionaries with the exact OrderID values given. Each dictionary must also have CustomerID and Amount keys.

3

Write a query to get orders by OrderID

Write a function called get_order_by_id that takes a parameter order_id. Inside the function, write a query expression to get the order from sample_orders where OrderID matches order_id. Use a for loop with variables order to find the matching order and return it.

DynamoDB

table_schema = {
    'TableName': 'Orders',
    'KeySchema': [
        {'AttributeName': 'OrderID', 'KeyType': 'HASH'}
    ],
    'AttributeDefinitions': [
        {'AttributeName': 'OrderID', 'AttributeType': 'S'}
    ],
    'ProvisionedThroughput': {
        'ReadCapacityUnits': 5,
        'WriteCapacityUnits': 5
    }
}

sample_orders = [
    {'OrderID': 'O1001', 'CustomerID': 'C001', 'Amount': 250},
    {'OrderID': 'O1002', 'CustomerID': 'C002', 'Amount': 450},
    {'OrderID': 'O1003', 'CustomerID': 'C001', 'Amount': 150},
    {'OrderID': 'O1004', 'CustomerID': 'C003', 'Amount': 300},
    {'OrderID': 'O1005', 'CustomerID': 'C004', 'Amount': 500}
]

def get_order_by_id(order_id):
    # Your code here

Hint

Define a function get_order_by_id that loops through sample_orders. Return the order where OrderID matches order_id. Return None if not found.

4

Add a secondary index on CustomerID

Update the table_schema dictionary to add a global secondary index named CustomerIndex. The index should have CustomerID as the partition key of type string. Add CustomerID to the AttributeDefinitions list as well.

DynamoDB

table_schema = {
    'TableName': 'Orders',
    'KeySchema': [
        {'AttributeName': 'OrderID', 'KeyType': 'HASH'}
    ],
    'AttributeDefinitions': [
        {'AttributeName': 'OrderID', 'AttributeType': 'S'}
    ],
    'ProvisionedThroughput': {
        'ReadCapacityUnits': 5,
        'WriteCapacityUnits': 5
    }
}

sample_orders = [
    {'OrderID': 'O1001', 'CustomerID': 'C001', 'Amount': 250},
    {'OrderID': 'O1002', 'CustomerID': 'C002', 'Amount': 450},
    {'OrderID': 'O1003', 'CustomerID': 'C001', 'Amount': 150},
    {'OrderID': 'O1004', 'CustomerID': 'C003', 'Amount': 300},
    {'OrderID': 'O1005', 'CustomerID': 'C004', 'Amount': 500}
]

def get_order_by_id(order_id):
    for order in sample_orders:
        if order['OrderID'] == order_id:
            return order
    return None

# Add a global secondary index on CustomerID below

Hint

Add a GlobalSecondaryIndexes key to table_schema. Define an index named CustomerIndex with CustomerID as the partition key. Also add CustomerID to AttributeDefinitions.

Practice

1. What is the main purpose of a partition key in DynamoDB?

easy

A. To create backups of the database

B. To store large files in the database

C. To encrypt data automatically

D. To divide data into parts for faster access

Solution

1. Step 1: Understand the role of partition key

   The partition key is used to split data into different sections called partitions.

2. Step 2: Recognize the benefit of partitioning

   This splitting helps DynamoDB access data faster by looking in smaller parts instead of the whole table.

3. Final Answer:

   To divide data into parts for faster access -> Option D

4. Quick Check:

   Partition key divides data = faster access [OK]

Hint: Partition key splits data to speed up access [OK]

Common Mistakes:

• Thinking partition key stores files
• Confusing partition key with encryption
• Assuming partition key creates backups

2. Which of the following is the correct way to define a partition key in a DynamoDB table using AWS CLI?

easy

A. aws dynamodb create-table --table-name MyTable --key-schema AttributeName=UserId,KeyType=HASH --attribute-definitions AttributeName=UserId,AttributeType=S --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5

B. aws dynamodb create-table --table-name MyTable --partition-key UserId --attribute-type String

C. aws dynamodb create-table --table-name MyTable --key UserId --type HASH

D. aws dynamodb create-table --table-name MyTable --primary-key UserId STRING

Solution

1. Step 1: Review AWS CLI syntax for creating table with partition key

   The correct syntax uses --key-schema with AttributeName and KeyType=HASH for partition key.

2. Step 2: Check attribute definitions and throughput

   Attribute definitions must specify AttributeName and AttributeType, and provisioned throughput is required.

3. Final Answer:

   aws dynamodb create-table --table-name MyTable --key-schema AttributeName=UserId,KeyType=HASH --attribute-definitions AttributeName=UserId,AttributeType=S --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 -> Option A

4. Quick Check:

   Correct AWS CLI syntax = aws dynamodb create-table --table-name MyTable --key-schema AttributeName=UserId,KeyType=HASH --attribute-definitions AttributeName=UserId,AttributeType=S --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 [OK]

Hint: Use --key-schema with KeyType=HASH for partition key [OK]

Common Mistakes:

• Using --partition-key instead of --key-schema
• Missing attribute definitions
• Incorrect key type syntax

3. Given a DynamoDB table with partition key 'UserId' having only two values: 'A' and 'B', what is the likely impact on partition key distribution?

medium

A. Good distribution because two keys are enough

B. Poor distribution causing hot partitions

C. No impact because DynamoDB balances automatically

D. Table will reject writes due to low key variety

Solution

1. Step 1: Understand partition key uniqueness importance

   Partition keys with few unique values cause data to cluster in few partitions.

2. Step 2: Recognize effect of low unique keys

   This clustering leads to hot partitions, slowing down performance and limiting scalability.

3. Final Answer:

   Poor distribution causing hot partitions -> Option B

4. Quick Check:

   Few unique keys = hot partitions [OK]

Hint: Few keys cause hot partitions, hurting performance [OK]

Common Mistakes:

• Assuming two keys are enough for good distribution
• Believing DynamoDB auto-balances all cases
• Thinking table rejects writes for low key variety

4. You notice your DynamoDB table has uneven partition key distribution causing slow queries. Which change will fix this?

medium

A. Change partition key to a field with many unique values

B. Increase read capacity units only

C. Add a sort key with the same values as partition key

D. Delete and recreate the table without changes

Solution

1. Step 1: Identify cause of uneven distribution

   Uneven distribution happens when partition key has few unique values.

2. Step 2: Choose a partition key with high uniqueness

   Changing to a key with many unique values spreads data evenly across partitions, improving performance.

3. Final Answer:

   Change partition key to a field with many unique values -> Option A

4. Quick Check:

   High uniqueness partition key = even distribution [OK]

Hint: Pick partition key with many unique values to fix distribution [OK]

Common Mistakes:

• Only increasing capacity without fixing key
• Adding sort key with same values doesn't help
• Recreating table without changing key

5. You have a DynamoDB table storing orders with partition key 'CustomerId'. Some customers place thousands of orders daily, others only a few. How can you improve partition key distribution to avoid hot partitions?

hard

A. Use 'OrderId' alone as partition key

B. Keep 'CustomerId' as partition key and add 'OrderId' as sort key

C. Use a composite key combining 'CustomerId' and 'OrderDate' as partition key

D. Use a random number as partition key for all orders

Solution

1. Step 1: Identify problem with current partition key

   Using only 'CustomerId' causes hot partitions for customers with many orders.

2. Step 2: Improve distribution by combining keys

   Combining 'CustomerId' and 'OrderDate' creates more unique partition keys, spreading load better.

3. Step 3: Understand why other options fail

   Keep 'CustomerId' as partition key and add 'OrderId' as sort key keeps same partition key, so hot partitions remain; Use 'OrderId' alone as partition key loses customer grouping; Use a random number as partition key for all orders breaks data organization.

4. Final Answer:

   Use a composite key combining 'CustomerId' and 'OrderDate' as partition key -> Option C

5. Quick Check:

   Composite key increases uniqueness, reduces hot partitions [OK]

Hint: Combine keys to increase uniqueness and spread load [OK]

Common Mistakes:

• Adding sort key but not changing partition key
• Using only order ID loses customer grouping
• Random keys break data access patterns