Why table design determines performance in DynamoDB - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the code to specify the primary key for a DynamoDB table.

DynamoDB

KeySchema: [{ AttributeName: 'UserId', KeyType: '[1]' }]

Drag options to blanks, or click blank then click option'

APRIMARY

BRANGE

CHASH

DINDEX

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'RANGE' instead of 'HASH' for the partition key.

Confusing 'PRIMARY' or 'INDEX' as KeyType values.

The primary key's partition key in DynamoDB is defined with KeyType 'HASH'. This determines how data is distributed.

2fill in blank

medium

Complete the code to add a sort key to the DynamoDB table design.

DynamoDB

KeySchema: [ { AttributeName: 'UserId', KeyType: 'HASH' }, { AttributeName: 'Timestamp', KeyType: '[1]' } ]

Drag options to blanks, or click blank then click option'

APRIMARY

BRANGE

CSORT

DINDEX

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'HASH' instead of 'RANGE' for the sort key.

Using 'SORT' or 'PRIMARY' which are not valid KeyType values.

The sort key in DynamoDB is defined with KeyType 'RANGE'. It allows sorting and querying within the partition.

3fill in blank

hard

Fix the error in the attribute definition for the partition key.

DynamoDB

AttributeDefinitions: [ { AttributeName: 'UserId', AttributeType: '[1]' } ]

Drag options to blanks, or click blank then click option'

AS

BN

CB

DBOOL

Attempts:

3 left

💡 Hint

Common Mistakes

Using 'N' (number) when the key is a string.

Using 'B' (binary) or 'BOOL' which are not typical for keys.

The partition key attribute type is usually a string, represented by 'S' in DynamoDB.

4fill in blank

hard

Fill both blanks to create a Global Secondary Index (GSI) with a partition and sort key.

DynamoDB

GlobalSecondaryIndexes: [{ IndexName: 'StatusIndex', KeySchema: [ { AttributeName: '[1]', KeyType: 'HASH' }, { AttributeName: '[2]', KeyType: 'RANGE' } ], Projection: { ProjectionType: 'ALL' } }]

Drag options to blanks, or click blank then click option'

AStatus

BCreatedAt

CUserId

DTimestamp

Attempts:

3 left

💡 Hint

Common Mistakes

Using the main table keys instead of GSI keys.

Mixing up partition and sort keys.

The GSI uses 'Status' as the partition key and 'CreatedAt' as the sort key to allow queries by status and time.

5fill in blank

hard

Fill all three blanks to create a DynamoDB query filtering items by partition key and a condition on the sort key.

DynamoDB

const params = { TableName: 'Orders', KeyConditionExpression: '#pk = :pkVal AND [1] [2] :sortVal', ExpressionAttributeNames: { '#pk': '[3]' }, ExpressionAttributeValues: { ':pkVal': '123', ':sortVal': 20230101 } };

Drag options to blanks, or click blank then click option'

ATimestamp

B>

COrderId

D=

Attempts:

3 left

💡 Hint

Common Mistakes

Using '=' instead of '>' for the sort key condition.

Mixing up attribute names in ExpressionAttributeNames.

The query filters items where the partition key 'OrderId' equals '123' and the sort key 'Timestamp' is greater than a given value.

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