Schema design for read-heavy workloads in MongoDB - Step-by-Step Execution

Concept Flow - Schema design for read-heavy workloads

Identify read-heavy workload

↓

Choose schema design strategy

↓

Embed related data

↓

Query data directly

↓

Fast read performance

↓

Monitor and adjust

Start by identifying if reads dominate. Then choose embedding for fewer reads or referencing for smaller docs. Finally, query accordingly and monitor performance.

Execution Sample

MongoDB

db.orders.insertOne({
  _id: 1,
  customer: { name: "Alice", email: "[e-mail]" },
  items: [{ product: "Book", qty: 2 }]
})

Insert an order document embedding customer info and items for fast reads.

Execution Table

Step	Action	Data State	Effect on Reads
1	Insert order with embedded customer and items	{_id:1, customer:{name:'Alice', email:'[e-mail]'}, items:[{product:'Book', qty:2}]}	One read fetches all needed data
2	Query order by _id	Returns full order with customer and items embedded	Fast read, no joins needed
3	Update customer email inside order	Modify embedded customer.email in order document	Write affects whole order document
4	Insert order with referenced customer ID	{_id:2, customerId: 123, items:[{product:'Pen', qty:5}]}	Reads require join or multiple queries
5	Query order and lookup customer by ID	Order data plus separate customer data fetched	Slower read due to extra query or $lookup
6	End	Schema choice affects read speed and complexity	Embedding favors read speed; referencing favors data size and write flexibility

💡 Execution stops after showing how embedding vs referencing affects read performance

Variable Tracker

Variable	Start	After Step 1	After Step 3	After Step 4	After Step 5	Final
order document	empty	{_id:1, customer:{name:'Alice', email:'[e-mail]'}, items:[{product:'Book', qty:2}]}	{_id:1, customer:{name:'Alice', email:'[e-mail]'}, items:[{product:'Book', qty:2}]}	{_id:2, customerId:123, items:[{product:'Pen', qty:5}]}	{_id:2, customerId:123, items:[{product:'Pen', qty:5}]}	Order data varies by embedding or referencing

Key Moments - 3 Insights

Why does embedding customer data speed up reads?

Because all needed data is in one document, so one query fetches everything without extra lookups, as shown in execution_table step 2.

Why might referencing customer data slow down reads?

Because it requires additional queries or $lookup to fetch related data, adding overhead as seen in execution_table step 5.

What is a trade-off of embedding data for read-heavy workloads?

Writes become heavier since updating embedded data means rewriting the whole document, demonstrated in execution_table step 3.

Visual Quiz - 3 Questions

Look at the execution_table, what is the effect on reads after inserting an order with embedded customer data (Step 1)?

A Reads require multiple queries

B One read fetches all needed data

C Reads are slower due to joins

D No data is fetched

💡 Hint

Check the 'Effect on Reads' column at Step 1 in execution_table

At which step does updating embedded customer data happen?

A Step 2

B Step 4

C Step 3

D Step 5

💡 Hint

Look for the step describing modifying embedded customer.email in execution_table

If you switch from embedding to referencing, how does the read performance change according to the execution_table?

A Reads require extra queries or $lookup, slowing them down

B Reads become faster with fewer queries

C Reads do not change

D Reads stop working

💡 Hint

Compare Steps 2 and 5 in execution_table for read performance differences

Concept Snapshot

Schema design for read-heavy workloads:
- Embed related data to reduce number of reads
- Referencing keeps documents smaller but needs joins
- Embedding speeds reads but can slow writes
- Choose based on read vs write priorities
- Monitor and adjust schema as workload changes

Full Transcript

This visual execution shows how schema design affects read-heavy workloads in MongoDB. First, we identify if reads dominate. Then we choose embedding to store related data together or referencing to keep documents smaller. Embedding allows fetching all data in one query, speeding reads, but updates require rewriting the whole document. Referencing needs extra queries or $lookup, slowing reads but improving write flexibility. The execution table traces inserting orders with embedded or referenced customer data, querying them, and updating embedded fields. Variable tracking shows how order documents change. Key moments clarify why embedding speeds reads and referencing slows them. The quiz tests understanding of these effects. The snapshot summarizes key points for quick reference.