Schema design for read-heavy workloads in MongoDB - Mini Project: Build & Apply

Schema Design for Read-Heavy Workloads in MongoDB

📖 Scenario: You are building a simple blog platform where many users read posts frequently, but writes (new posts or updates) happen less often. To make reading posts fast and efficient, you want to design a MongoDB schema optimized for read-heavy workloads.

🎯 Goal: Create a MongoDB schema that stores blog posts with embedded comments to optimize read performance. You will start by defining the initial data structure, add a configuration for maximum comments per post, implement the core logic to embed comments inside posts, and finally complete the schema with an index to speed up reads.

📋 What You'll Learn

Create a collection called posts with fields _id, title, content, and comments (an array).

Add a configuration variable max_comments to limit the number of comments stored per post.

Write a function add_comment(post, comment) that adds a comment to the comments array only if the number of comments is less than max_comments.

Create an index on the title field to speed up read queries by post title.

💡 Why This Matters

🌍 Real World

Many web applications have pages that are read far more often than updated. Embedding related data and indexing key fields helps make these reads fast and efficient.

💼 Career

Understanding schema design for read-heavy workloads is important for backend developers and database administrators to optimize performance and scalability in real-world applications.

1

Create the initial posts collection schema

Create a MongoDB document structure for a blog post with fields: _id (string), title (string), content (string), and an empty array comments. Assign this document to a variable called post.

MongoDB

post = {
    "_id": "post1",
    "title": "",
    "content": "",
    "comments": []
}
# Your code here

Hint

Use a Python dictionary to represent the MongoDB document. Initialize comments as an empty list.

2

Add a configuration variable max_comments

Create a variable called max_comments and set it to 3. This will limit the number of comments stored per post.

MongoDB

post = {
    "_id": "post1",
    "title": "Introduction to MongoDB",
    "content": "MongoDB is a NoSQL database optimized for document storage.",
    "comments": []
}

# Your code here

Hint

Just create a simple variable named max_comments and assign the number 3.

3

Write a function to add comments respecting max_comments

Write a function called add_comment(post, comment) that adds the comment string to the comments array inside post only if the number of comments is less than max_comments. Use len(post["comments"]) to check the count.

MongoDB

post = {
    "_id": "post1",
    "title": "Introduction to MongoDB",
    "content": "MongoDB is a NoSQL database optimized for document storage.",
    "comments": []
}

max_comments = 3

def add_comment(post, comment):
    # Your code here

Hint

Use an if statement to check the length of post["comments"]. Append the comment only if the count is less than max_comments.

4

Create an index on the title field for faster reads

Write a MongoDB command to create an index on the title field of the posts collection. Assign this command to a variable called index_command. Use the format { "title": 1 } to specify ascending order.

MongoDB

post = {
    "_id": "post1",
    "title": "Introduction to MongoDB",
    "content": "MongoDB is a NoSQL database optimized for document storage.",
    "comments": []
}

max_comments = 3

def add_comment(post, comment):
    if len(post["comments"]) < max_comments:
        post["comments"].append(comment)

index_command = {}
# Your code here

Hint

Use a dictionary with the key "title" and value 1 to indicate ascending index order.

Practice

1. Which schema design approach is best for read-heavy workloads in MongoDB?

easy

A. Embed related data in the same document to reduce read operations

B. Use references for all data to keep documents small

C. Normalize data like in relational databases

D. Store all data in separate collections regardless of usage

Solution

1. Step 1: Understand read-heavy workload needs

   Read-heavy workloads benefit from fewer queries and faster data retrieval.

2. Step 2: Choose schema design for fast reads

   Embedding related data in one document reduces the need for multiple queries, speeding up reads.

3. Final Answer:

   Embed related data in the same document to reduce read operations -> Option A

4. Quick Check:

   Embedding = faster reads [OK]

Hint: Embed related data for fast reads in read-heavy apps [OK]

Common Mistakes:

• Choosing referencing for all data slows reads
• Normalizing like SQL increases read complexity
• Separating all data causes many queries

2. Which of the following is the correct way to embed an array of comments inside a blog post document in MongoDB?

easy

A. { title: 'Post', comments: [{ user: 'Alice', text: 'Nice!' }, { user: 'Bob', text: 'Great!' }] }

B. { title: 'Post', comments: 'user: Alice, text: Nice!' }

C. { title: 'Post', comments: { user: 'Alice', text: 'Nice!' } }

D. { title: 'Post', comments: ['user: Alice', 'text: Nice!'] }

Solution

1. Step 1: Identify correct array embedding syntax

   Embedding an array of subdocuments requires an array of objects inside the field.

2. Step 2: Check each option's structure

   { title: 'Post', comments: [{ user: 'Alice', text: 'Nice!' }, { user: 'Bob', text: 'Great!' }] } correctly uses an array of objects for comments; others use incorrect types or formats.

3. Final Answer:

   { title: 'Post', comments: [{ user: 'Alice', text: 'Nice!' }, { user: 'Bob', text: 'Great!' }] } -> Option A

4. Quick Check:

   Array of objects = correct embedding [OK]

Hint: Use array of objects to embed multiple related items [OK]

Common Mistakes:

• Using string instead of array for multiple comments
• Embedding a single object instead of an array
• Using array of strings instead of objects

3. Given this MongoDB document for a product with embedded reviews:

{ _id: 1, name: 'Gadget', reviews: [{ user: 'Ann', rating: 5 }, { user: 'Ben', rating: 4 }] }

What will be the result of this query?

db.products.findOne({ _id: 1 }, { name: 1, 'reviews.rating': 1 })

medium

A. { name: 'Gadget', reviews: [{ rating: 5 }, { rating: 4 }] }

B. { _id: 1, name: 'Gadget', reviews: [{ rating: 5 }, { rating: 4 }] }

C. { _id: 1, name: 'Gadget' }

D. { _id: 1, name: 'Gadget', reviews: [{ user: 'Ann', rating: 5 }, { user: 'Ben', rating: 4 }] }

Solution

1. Step 1: Understand projection with dot notation

   Using 'reviews.rating': 1 includes only the rating field inside each review subdocument.

2. Step 2: Analyze returned fields

   The query returns _id, name, and reviews with only rating fields (user excluded).

3. Final Answer:

   { _id: 1, name: 'Gadget', reviews: [{ rating: 5 }, { rating: 4 }] } -> Option B

4. Quick Check:

   Projection with dot notation = filtered subfields [OK]

Hint: Use dot notation in projection to include subfields only [OK]

Common Mistakes:

• Expecting full subdocuments when projecting subfields
• Forgetting _id is included by default
• Assuming projection excludes _id without explicit exclusion

4. You designed a schema embedding user addresses inside user documents, but queries on addresses are slow. What is the likely problem?

medium

A. MongoDB does not support embedding arrays

B. Embedding always makes queries slower

C. You must store addresses in a separate database

D. Addresses should be referenced separately if they are large or updated often

Solution

1. Step 1: Identify embedding drawbacks

   Embedding large or frequently changing data can cause large documents and slow updates or queries.

2. Step 2: Choose referencing for large or mutable data

   Referencing addresses separately keeps user documents small and improves query speed on addresses.

3. Final Answer:

   Addresses should be referenced separately if they are large or updated often -> Option D

4. Quick Check:

   Large mutable data = use referencing [OK]

Hint: Reference large or changing data to keep documents small [OK]

Common Mistakes:

• Assuming embedding always improves speed
• Thinking MongoDB disallows embedding arrays
• Believing separate databases are needed for performance

5. You have a read-heavy app showing user profiles with many posts. Posts change often, but profiles rarely do. How should you design the schema for fast reads?

hard

A. Embed user profile data inside each post document

B. Embed posts inside user profiles despite frequent changes

C. Store user profiles and posts in separate collections, referencing posts from profiles

D. Duplicate posts data inside profiles and update both on changes

Solution

1. Step 1: Analyze data change frequency

   Posts change often; embedding them inside profiles would cause large documents and frequent updates.

2. Step 2: Choose referencing for frequently changing large data

   Storing posts separately and referencing them keeps profiles small and reads fast.

3. Step 3: Avoid data duplication to prevent sync issues

   Duplicating posts in profiles causes update complexity and inconsistency risks.

4. Final Answer:

   Store user profiles and posts in separate collections, referencing posts from profiles -> Option C

5. Quick Check:

   Frequent changes = referencing large data [OK]

Hint: Reference frequently changing data, embed stable data [OK]

Common Mistakes:

• Embedding frequently changing posts inside profiles
• Duplicating data causing sync problems
• Embedding profiles inside posts which is illogical