DynamoDB vs MongoDB vs Cassandra - Hands-On Comparison

Comparing DynamoDB, MongoDB, and Cassandra with Sample Queries

📖 Scenario: You are working as a junior database analyst for a company that wants to understand how three popular NoSQL databases work: DynamoDB, MongoDB, and Cassandra. You will create simple data structures and queries to see how each database handles data storage and retrieval.

🎯 Goal: Build simple data entries and queries in DynamoDB style to compare with MongoDB and Cassandra concepts. You will create a table, add a configuration for querying, write a query to retrieve data, and finalize the setup.

📋 What You'll Learn

Create a DynamoDB table structure with exact attribute names and values

Add a configuration variable for query filtering

Write a query expression to retrieve items based on the configuration

Complete the table setup with a key schema and provisioned throughput

💡 Why This Matters

🌍 Real World

Understanding how different NoSQL databases store and query data helps in choosing the right database for applications like user management, product catalogs, or real-time analytics.

💼 Career

Database developers and data engineers often need to work with multiple NoSQL databases and write queries or configurations that fit the application's needs.

1

Create a DynamoDB table with sample items

Create a variable called table_items as a list of dictionaries. Add exactly two items with these attributes: {'UserID': 'user1', 'Name': 'Alice', 'Age': 30} and {'UserID': 'user2', 'Name': 'Bob', 'Age': 25}.

DynamoDB

# Create a list called table_items with two dictionaries for users
# Your code here

Hint

Use a list with two dictionaries exactly as shown, with keys 'UserID', 'Name', and 'Age'.

2

Add a filter configuration for querying

Create a variable called age_filter and set it to the integer 28. This will be used to filter users older than this age.

DynamoDB

table_items = [
    {'UserID': 'user1', 'Name': 'Alice', 'Age': 30},
    {'UserID': 'user2', 'Name': 'Bob', 'Age': 25}
]
# Create an integer variable age_filter set to 28
# Your code here

Hint

Just assign the number 28 to the variable age_filter.

3

Write a query to select users older than the filter

Create a variable called filtered_users that uses a list comprehension to select items from table_items where the 'Age' is greater than age_filter.

DynamoDB

table_items = [
    {'UserID': 'user1', 'Name': 'Alice', 'Age': 30},
    {'UserID': 'user2', 'Name': 'Bob', 'Age': 25}
]
age_filter = 28
# Use list comprehension to create filtered_users with users older than age_filter
# Your code here

Hint

Use a list comprehension filtering by item['Age'] > age_filter.

4

Complete the DynamoDB table setup with key schema and throughput

Create a dictionary called table_config with keys: 'TableName' set to 'Users', 'KeySchema' set to a list with one dictionary {'AttributeName': 'UserID', 'KeyType': 'HASH'}, and 'ProvisionedThroughput' set to {'ReadCapacityUnits': 5, 'WriteCapacityUnits': 5}.

DynamoDB

table_items = [
    {'UserID': 'user1', 'Name': 'Alice', 'Age': 30},
    {'UserID': 'user2', 'Name': 'Bob', 'Age': 25}
]
age_filter = 28
filtered_users = [item for item in table_items if item['Age'] > age_filter]
# Create table_config dictionary with TableName, KeySchema, and ProvisionedThroughput
# Your code here

Hint

Follow the exact dictionary structure with keys and nested lists/dictionaries as shown.

Practice

1. Which database is best known for automatic scaling and simple key-value access?

easy

A. Cassandra

B. DynamoDB

C. MongoDB

D. MySQL

Solution

1. Step 1: Understand DynamoDB's core feature

   DynamoDB is designed for simple key-value access and automatic scaling.

2. Step 2: Compare with other databases

   MongoDB focuses on flexible document storage, Cassandra on high availability for huge data.

3. Final Answer:

   DynamoDB -> Option B

4. Quick Check:

   Automatic scaling + key-value = DynamoDB [OK]

Hint: Automatic scaling with key-value means DynamoDB [OK]

Common Mistakes:

• Confusing MongoDB's flexible documents with key-value simplicity
• Thinking Cassandra automatically scales like DynamoDB
• Choosing MySQL which is relational, not key-value

2. Which of the following is the correct way to describe MongoDB's data model?

easy

A. Column-family store with automatic partitioning

B. Simple key-value pairs with fixed schema

C. Flexible document storage with rich queries

D. Relational tables with strict schema

Solution

1. Step 1: Identify MongoDB's data model

   MongoDB stores data as flexible JSON-like documents allowing rich queries.

2. Step 2: Eliminate other options

   Column-family store describes Cassandra, key-value with fixed schema fits DynamoDB less, relational tables fit SQL databases.

3. Final Answer:

   Flexible document storage with rich queries -> Option C

4. Quick Check:

   MongoDB = flexible documents + rich queries [OK]

Hint: MongoDB = flexible JSON documents + rich queries [OK]

Common Mistakes:

• Confusing MongoDB with Cassandra's column-family model
• Thinking MongoDB uses fixed schema like relational DB
• Mixing key-value with document storage

3. Given a large dataset requiring high availability and fast writes across multiple data centers, which database is most suitable?

medium

A. MongoDB

B. DynamoDB

C. SQLite

D. Cassandra

Solution

1. Step 1: Analyze requirements for high availability and multi-datacenter writes

   Cassandra is designed for huge data with high availability and multi-region replication.

2. Step 2: Compare other options

   MongoDB supports replication but less optimized for huge scale multi-datacenter writes; DynamoDB is scalable but less focused on multi-datacenter writes; SQLite is local and not distributed.

3. Final Answer:

   Cassandra -> Option D

4. Quick Check:

   High availability + multi-datacenter = Cassandra [OK]

Hint: Huge data + multi-region writes = Cassandra [OK]

Common Mistakes:

• Choosing DynamoDB for multi-datacenter writes
• Confusing SQLite as distributed database
• Assuming MongoDB handles huge multi-region writes best

4. You try to use MongoDB's flexible document queries on DynamoDB but get errors. What is the likely cause?

medium

A. DynamoDB does not support flexible document queries like MongoDB

B. DynamoDB requires SQL syntax for queries

C. MongoDB uses column-family data model incompatible with DynamoDB

D. DynamoDB only supports relational tables

Solution

1. Step 1: Understand query capabilities of DynamoDB

   DynamoDB supports key-value and simple queries but not rich flexible document queries like MongoDB.

2. Step 2: Eliminate incorrect causes

   DynamoDB does not use SQL syntax, is not column-family, and is not relational.

3. Final Answer:

   DynamoDB does not support flexible document queries like MongoDB -> Option A

4. Quick Check:

   DynamoDB lacks MongoDB's flexible queries [OK]

Hint: DynamoDB lacks MongoDB's rich document query support [OK]

Common Mistakes:

• Assuming DynamoDB uses SQL syntax
• Confusing data models between MongoDB and Cassandra
• Thinking DynamoDB supports relational tables

5. You need a database for an app that requires flexible JSON documents, automatic scaling, and global availability. Which approach best fits this need?

hard

A. Use DynamoDB with JSON support and global tables

B. Use MongoDB with sharding and replica sets only

C. Use Cassandra with column-family tables and no JSON support

D. Use SQLite with local JSON extensions

Solution

1. Step 1: Identify features needed

   The app needs flexible JSON documents, automatic scaling, and global availability.

2. Step 2: Match features to databases

   DynamoDB supports JSON documents, automatic scaling, and global tables for availability. MongoDB supports JSON but global availability requires extra setup and scaling is manual. Cassandra lacks native JSON support and SQLite is local only.

3. Final Answer:

   Use DynamoDB with JSON support and global tables -> Option A

4. Quick Check:

   JSON + auto scale + global = DynamoDB [OK]

Hint: DynamoDB global tables + JSON = best for scaling + availability [OK]

Common Mistakes:

• Choosing MongoDB without considering scaling complexity
• Ignoring Cassandra's lack of JSON support
• Selecting SQLite which is not distributed