Why table design determines performance in DynamoDB - See It in Action

Why Table Design Determines Performance in DynamoDB

📖 Scenario: You are building a simple online bookstore database using DynamoDB. You want to understand how the way you design your table affects how fast and efficient your database works.

🎯 Goal: Build a DynamoDB table with a proper primary key and a secondary index to see how table design impacts query performance.

📋 What You'll Learn

Create a DynamoDB table named Books with a partition key called ISBN (string).

Add a sort key called Title (string) to the table.

Create a Global Secondary Index (GSI) named AuthorIndex with Author as the partition key and Year as the sort key.

Insert sample items with attributes ISBN, Title, Author, and Year.

💡 Why This Matters

🌍 Real World

In real online stores or apps, designing your database tables well helps users get their data quickly without delays.

💼 Career

Database designers and backend developers must understand table design to build fast, scalable applications using DynamoDB.

1

Create the DynamoDB table with primary key

Create a DynamoDB table named Books with a partition key called ISBN of type string and a sort key called Title of type string.

DynamoDB

# Define the Books table with partition key ISBN and sort key Title
# Your code here

Hint

Use KeySchema to define partition and sort keys. Partition key is HASH, sort key is RANGE.

2

Add a Global Secondary Index for author queries

Add a Global Secondary Index named AuthorIndex to the Books table with Author as the partition key and Year as the sort key. Both attributes are strings.

DynamoDB

Books = {
    'TableName': 'Books',
    'KeySchema': [
        {'AttributeName': 'ISBN', 'KeyType': 'HASH'},
        {'AttributeName': 'Title', 'KeyType': 'RANGE'}
    ],
    'AttributeDefinitions': [
        {'AttributeName': 'ISBN', 'AttributeType': 'S'},
        {'AttributeName': 'Title', 'AttributeType': 'S'},
        {'AttributeName': 'Author', 'AttributeType': 'S'},
        {'AttributeName': 'Year', 'AttributeType': 'S'}
    ],
    'GlobalSecondaryIndexes': [
        {
            'IndexName': 'AuthorIndex',
            'KeySchema': [
                {'AttributeName': 'Author', 'KeyType': 'HASH'},
                {'AttributeName': 'Year', 'KeyType': 'RANGE'}
            ],
            'Projection': {
                'ProjectionType': 'ALL'
            },
            'ProvisionedThroughput': {
                'ReadCapacityUnits': 5,
                'WriteCapacityUnits': 5
            }
        }
    ],
    'ProvisionedThroughput': {
        'ReadCapacityUnits': 5,
        'WriteCapacityUnits': 5
    }
}
# Your code here

Hint

Remember to add Author and Year to AttributeDefinitions before using them in the GSI.

3

Insert sample book items

Insert three sample items into the Books table with these exact attributes and values: {'ISBN': '978-0132350884', 'Title': 'Clean Code', 'Author': 'Robert C. Martin', 'Year': '2008'}, {'ISBN': '978-0201616224', 'Title': 'The Pragmatic Programmer', 'Author': 'Andrew Hunt', 'Year': '1999'}, and {'ISBN': '978-0131103627', 'Title': 'The C Programming Language', 'Author': 'Brian W. Kernighan', 'Year': '1988'}.

DynamoDB

Books = {
    'TableName': 'Books',
    'KeySchema': [
        {'AttributeName': 'ISBN', 'KeyType': 'HASH'},
        {'AttributeName': 'Title', 'KeyType': 'RANGE'}
    ],
    'AttributeDefinitions': [
        {'AttributeName': 'ISBN', 'AttributeType': 'S'},
        {'AttributeName': 'Title', 'AttributeType': 'S'},
        {'AttributeName': 'Author', 'AttributeType': 'S'},
        {'AttributeName': 'Year', 'AttributeType': 'S'}
    ],
    'GlobalSecondaryIndexes': [
        {
            'IndexName': 'AuthorIndex',
            'KeySchema': [
                {'AttributeName': 'Author', 'KeyType': 'HASH'},
                {'AttributeName': 'Year', 'KeyType': 'RANGE'}
            ],
            'Projection': {
                'ProjectionType': 'ALL'
            },
            'ProvisionedThroughput': {
                'ReadCapacityUnits': 5,
                'WriteCapacityUnits': 5
            }
        }
    ],
    'ProvisionedThroughput': {
        'ReadCapacityUnits': 5,
        'WriteCapacityUnits': 5
    }
}
items = [
    # Your code here
]

Hint

Use a list of dictionaries to represent the items with exact attribute names and values.

4

Explain how table design affects performance

Add a comment explaining why choosing the right partition key and using a Global Secondary Index improves query speed and overall performance in DynamoDB.

DynamoDB

Books = {
    # ... previous code ...
}
items = [
    # ... previous items ...
]
# Your explanation here

Hint

Explain in a comment how partition keys and GSIs help DynamoDB find data faster and keep performance high.

Practice

1. Why is choosing the right partition key important in DynamoDB table design?

easy

A. It helps distribute data evenly across storage nodes for faster access.

B. It automatically creates backups of your data.

C. It encrypts your data for security.

D. It limits the size of your table.

Solution

1. Step 1: Understand partition key role

   The partition key determines how data is spread across storage nodes in DynamoDB.

2. Step 2: Effect on performance

   Even data distribution prevents hot spots and allows faster read/write operations.

3. Final Answer:

   It helps distribute data evenly across storage nodes for faster access. -> Option A

4. Quick Check:

   Partition key = data distribution [OK]

Hint: Partition key spreads data evenly for speed [OK]

Common Mistakes:

• Thinking partition key controls backups
• Confusing partition key with encryption
• Believing partition key limits table size

2. Which of the following is the correct way to define a DynamoDB table with a partition key named UserId?

easy

A. CreateTable with KeySchema: [{ AttributeName: 'UserId', KeyType: 'INDEX' }]

B. CreateTable with KeySchema: [{ AttributeName: 'UserId', KeyType: 'RANGE' }]

C. CreateTable with KeySchema: [{ AttributeName: 'UserId', KeyType: 'PRIMARY' }]

D. CreateTable with KeySchema: [{ AttributeName: 'UserId', KeyType: 'HASH' }]

Solution

1. Step 1: Identify partition key type

   Partition key uses KeyType 'HASH' in DynamoDB table definition.

2. Step 2: Match correct syntax

   CreateTable with KeySchema: [{ AttributeName: 'UserId', KeyType: 'HASH' }] correctly uses KeyType 'HASH' for 'UserId' in KeySchema.

3. Final Answer:

   CreateTable with KeySchema: [{ AttributeName: 'UserId', KeyType: 'HASH' }] -> Option D

4. Quick Check:

   Partition key = KeyType 'HASH' [OK]

Hint: Partition key uses 'HASH' in KeySchema [OK]

Common Mistakes:

• Using 'RANGE' for partition key
• Using invalid KeyType like 'PRIMARY' or 'INDEX'
• Confusing partition key with sort key

3. Given a DynamoDB table with partition key OrderId and sort key ItemId, what will happen if you query with only OrderId specified?

medium

A. The query will fail due to missing ItemId.

B. You get only one item with that OrderId and ItemId.

C. You get all items with that OrderId, sorted by ItemId.

D. You get all items in the table regardless of OrderId.

Solution

1. Step 1: Understand query with partition key only

   Querying with partition key returns all items sharing that key, optionally sorted by sort key.

2. Step 2: Effect of missing sort key in query

   Not specifying sort key returns all matching partition key items sorted by sort key.

3. Final Answer:

   You get all items with that OrderId, sorted by ItemId. -> Option C

4. Quick Check:

   Query with partition key only = multiple sorted items [OK]

Hint: Query with partition key returns all matching items [OK]

Common Mistakes:

• Thinking query needs both keys
• Expecting query to fail without sort key
• Believing query returns entire table

4. You designed a DynamoDB table with a partition key that has very few unique values. What problem might this cause?

medium

A. Hot partitions causing slow performance and throttling.

B. Data loss due to key collisions.

C. Table size limits exceeded quickly.

D. Automatic backups fail.

Solution

1. Step 1: Analyze partition key uniqueness

   Few unique partition key values cause uneven data distribution.

2. Step 2: Impact on performance

   Uneven distribution leads to hot partitions, slowing reads/writes and causing throttling.

3. Final Answer:

   Hot partitions causing slow performance and throttling. -> Option A

4. Quick Check:

   Low key uniqueness = hot partitions [OK]

Hint: Few unique keys cause hot partitions [OK]

Common Mistakes:

• Confusing hot partitions with data loss
• Thinking table size is affected by key uniqueness
• Assuming backups depend on key design

5. You have a DynamoDB table storing user activity logs. To optimize performance, which table design is best?

hard

A. Partition key: ActivityType only, no sort key for simplicity.

B. Partition key: UserId, Sort key: Timestamp to query recent activities quickly.

C. Partition key: Timestamp, Sort key: UserId to group by time first.

D. No partition key, only a sort key on UserId.

Solution

1. Step 1: Consider query patterns for user logs

   Users often want recent activities, so partition by UserId and sort by Timestamp helps.

2. Step 2: Evaluate options for performance

   Partition key: UserId, Sort key: Timestamp to query recent activities quickly supports fast queries per user ordered by time; others cause hot partitions or lack partition key.

3. Final Answer:

   Partition key: UserId, Sort key: Timestamp to query recent activities quickly. -> Option B

4. Quick Check:

   UserId + Timestamp = optimized user activity queries [OK]

Hint: Partition by user, sort by time for fast queries [OK]

Common Mistakes:

• Using timestamp as partition key causes hot partitions
• Skipping partition key causes errors
• Choosing only activity type limits query flexibility