Key-value and document store model in DynamoDB - Step-by-Step Execution

Concept Flow - Key-value and document store model

Start: Client sends request

↓

Check: Is key present?

No→Return: Item not found

Yes↓

Retrieve value/document by key

↓

Return value/document to client

The flow shows how a key-value or document store retrieves data by checking the key and returning the associated value or document.

Execution Sample

DynamoDB

SELECT * FROM "Users" WHERE UserID = '123';

This query retrieves the document (record) for the user with UserID '123' from the Users table.

Execution Table

Step	Action	Condition	Result	Output
1	Receive query	N/A	Query parsed	N/A
2	Check if key '123' exists	Key '123' in Users?	Yes	N/A
3	Retrieve document	N/A	Document found	{UserID: '123', Name: 'Alice', Age: 30}
4	Return document	N/A	Document sent to client	{UserID: '123', Name: 'Alice', Age: 30}
5	End	N/A	Query complete	N/A

💡 Query ends after returning the document for key '123'

Variable Tracker

Variable	Start	After Step 2	After Step 3	Final
key	undefined	'123'	'123'	'123'
document	undefined	undefined	{UserID: '123', Name: 'Alice', Age: 30}	{UserID: '123', Name: 'Alice', Age: 30}
output	undefined	undefined	undefined	{UserID: '123', Name: 'Alice', Age: 30}

Key Moments - 2 Insights

Why do we check if the key exists before retrieving the document?

Checking the key first (Step 2 in execution_table) avoids unnecessary retrieval attempts and lets us return a clear 'not found' response if the key is missing.

Is the entire document returned or just the key?

The entire document associated with the key is returned (Step 4), not just the key itself, as shown in the output column.

Visual Quiz - 3 Questions

Look at the execution_table, what is the output at Step 3?

A Document sent to client

B Query parsed

C {UserID: '123', Name: 'Alice', Age: 30}

D Key '123' in Users?

💡 Hint

Check the 'Output' column for Step 3 in execution_table

At which step does the system confirm the key exists?

A Step 2

B Step 1

C Step 3

D Step 4

💡 Hint

Look at the 'Condition' column in execution_table where key presence is checked

If the key '123' was not found, what would happen in the flow?

A Return the document anyway

B Return 'Item not found' message

C Retrieve a different document

D Ignore the query

💡 Hint

Refer to concept_flow where 'No' branch returns 'Item not found'

Concept Snapshot

Key-value and document stores use a unique key to find and return a whole document.
The system first checks if the key exists.
If yes, it retrieves and returns the document.
If no, it returns a 'not found' message.
This model is fast and simple for retrieving data by key.

Full Transcript

This visual execution shows how a key-value or document store model works in DynamoDB. The client sends a query with a key. The system checks if the key exists in the table. If it does, the system retrieves the full document associated with that key and returns it to the client. If the key is missing, the system returns an 'Item not found' message. Variables like the key, document, and output change step-by-step as the query executes. This model is efficient for quick lookups by unique keys.

Practice

1. What is the main feature of a key-value store in DynamoDB?

easy

A. It uses a unique key to quickly find data.

B. It requires complex joins between tables.

C. It stores data only in fixed columns.

D. It only supports relational data models.

Solution

1. Step 1: Understand key-value store basics

   A key-value store uses a unique key to store and retrieve data quickly without complex relations.

2. Step 2: Compare options with key-value features

   Options A, C, and D describe relational or fixed schema models, not key-value stores.

3. Final Answer:

   It uses a unique key to quickly find data. -> Option A

4. Quick Check:

   Key-value store = unique key fast access [OK]

Hint: Key-value means unique key for fast lookup [OK]

Common Mistakes:

• Confusing key-value with relational databases
• Thinking key-value needs fixed columns
• Assuming key-value supports joins

2. Which of the following is the correct way to define a composite primary key in a DynamoDB table?

easy

A. PrimaryKey: { PartitionKey: 'UserId', SortKey: 'Timestamp' }

B. PrimaryKey = UserId, SortKey = Timestamp

C. PrimaryKey: { PartitionKey: 'UserId' }

D. PrimaryKey: UserId, ForeignKey: Timestamp

Solution

1. Step 1: Recall DynamoDB primary key syntax

   DynamoDB primary key can be simple (partition key) or composite (partition + sort key) defined as an object with keys PartitionKey and SortKey.

2. Step 2: Check each option's syntax

   PrimaryKey: { PartitionKey: 'UserId', SortKey: 'Timestamp' } correctly shows both PartitionKey and SortKey in an object. PrimaryKey: { PartitionKey: 'UserId' } misses SortKey, B uses wrong assignment syntax, D uses ForeignKey which is invalid in DynamoDB.

3. Final Answer:

   PrimaryKey: { PartitionKey: 'UserId', SortKey: 'Timestamp' } -> Option A

4. Quick Check:

   Primary key = PartitionKey + SortKey object [OK]

Hint: Primary key uses PartitionKey and optional SortKey keys [OK]

Common Mistakes:

• Using equal sign instead of colon in definitions
• Confusing foreign key with sort key
• Omitting sort key when needed

3. Given a DynamoDB table with items: {UserId: '123', Name: 'Alice'}, {UserId: '456', Name: 'Bob'}, what will the query return if you request the item with UserId '123'?

medium

A. [{UserId: '456', Name: 'Bob'}]

B. Error: Item not found

C. []

D. [{UserId: '123', Name: 'Alice'}]

Solution

1. Step 1: Understand query by primary key

   Querying by UserId '123' returns the item with that key if it exists.

2. Step 2: Match UserId '123' in given items

   The item {UserId: '123', Name: 'Alice'} matches the query.

3. Final Answer:

   [{UserId: '123', Name: 'Alice'}] -> Option D

4. Quick Check:

   Query by key returns matching item [OK]

Hint: Query by key returns exact matching item [OK]

Common Mistakes:

• Expecting multiple items for a unique key
• Confusing query result with scan result
• Assuming error if item not found instead of empty

4. You wrote this DynamoDB query but it returns no results: Table.query(KeyConditionExpression='UserId = :uid', ExpressionAttributeValues={':uid': '789'}). What is the likely problem?

medium

A. KeyConditionExpression must use '==' instead of '='.

B. ExpressionAttributeValues should not use colons in keys.

C. The key name 'UserId' is incorrect or missing in the table.

D. Query requires a ScanIndexForward parameter.

Solution

1. Step 1: Check key name correctness

   If the key name 'UserId' does not exist or is misspelled in the table schema, the query returns no results.

2. Step 2: Validate syntax and parameters

   Using ':' in ExpressionAttributeValues keys is correct. '=' is valid in KeyConditionExpression. ScanIndexForward is optional for sorting, not required for results.

3. Final Answer:

   The key name 'UserId' is incorrect or missing in the table. -> Option C

4. Quick Check:

   Correct key name needed for query success [OK]

Hint: Check key names match table schema exactly [OK]

Common Mistakes:

• Removing colons from ExpressionAttributeValues keys
• Using '==' instead of '=' in expressions
• Adding unnecessary parameters

5. You want to store user profiles with flexible nested data like addresses and preferences in DynamoDB. Which model best fits this need?

hard

A. Use a relational model with multiple tables and foreign keys.

B. Use a document store model to save JSON-like nested objects.

C. Use a key-value store with only simple string values.

D. Use a graph database to store nested user data.

Solution

1. Step 1: Identify data flexibility needs

   Nested and flexible data like addresses and preferences require a document model that supports JSON-like structures.

2. Step 2: Match model to DynamoDB capabilities

   DynamoDB supports document store model allowing nested objects. Relational and graph models are not native to DynamoDB. Simple key-value stores do not support nested data well.

3. Final Answer:

   Use a document store model to save JSON-like nested objects. -> Option B

4. Quick Check:

   Nested data = document store model [OK]

Hint: Nested JSON data fits document store model best [OK]

Common Mistakes:

• Choosing relational model for flexible nested data
• Assuming key-value stores handle nested objects well
• Confusing graph databases with DynamoDB