Why document design matters in MongoDB - Challenge Your Understanding

Challenge - 5 Problems

❓ query_result

intermediate

How does embedding affect query speed?

Consider a MongoDB collection users where each user document embeds an array of orders. Which query will generally be faster to retrieve all orders for a single user?

MongoDB

db.users.findOne({user_id: 123}, {orders: 1})

A Querying the <code>users</code> collection with embedded <code>orders</code> returns all orders in one read.

B Querying <code>users</code> without embedding orders is faster for all cases.

C Using a join operation between <code>users</code> and <code>orders</code> collections is faster.

D Querying a separate <code>orders</code> collection with a user_id filter is always faster.

💡 Hint

Think about how embedding data reduces the need for multiple queries.

Embedding related data like orders inside a user document allows MongoDB to fetch all needed data in a single read, improving query speed.

🧠 Conceptual

intermediate

Why avoid large documents in MongoDB?

What is a main reason to avoid very large documents in MongoDB?

A MongoDB does not support documents larger than 1 KB.

B Large documents automatically split into multiple collections.

C Large documents can slow down read and write operations due to size limits and memory usage.

D Large documents improve query speed by storing more data in one place.

💡 Hint

Consider how document size affects performance and limits.

MongoDB has a document size limit (16MB), and very large documents can slow down operations and increase memory use.

📝 Syntax

advanced

Identify the correct schema design for referencing

Which MongoDB document design correctly references another collection?

MongoDB

User document referencing an Address document

A {"name": "Alice", "address": {"street": "Main St", "city": "Town"}}

B {"name": "Alice", "address": "507f1f77bcf86cd799439011"}

C {"name": "Alice", "address": ObjectId("507f1f77bcf86cd799439011")}

D {"name": "Alice", "address_id": ObjectId("507f1f77bcf86cd799439011")}

💡 Hint

Referencing uses ObjectId type fields to link documents.

Option D correctly uses an ObjectId field to reference another document. Option D embeds the address, not referencing. Option D uses ObjectId but inside an object, which is invalid. Option D uses a string instead of ObjectId.

🔧 Debug

advanced

Why does this query return no results?

Given a collection products where each document embeds an array tags, why does this query return no results?

db.products.find({tags: "electronics"})

A Because the field name <code>tags</code> is misspelled in the query.

B Because <code>tags</code> is an array, the query should use <code>{tags: {$in: ["electronics"]}}</code> to match elements.

C Because the query syntax is invalid and causes an error.

D Because the <code>tags</code> field does not exist in any document.

💡 Hint

Think about how MongoDB matches array fields in queries.

MongoDB matches array fields by checking if the value is an element of the array. The query {tags: "electronics"} matches documents where tags array contains exactly "electronics" as an element, so it should work. But if the array contains objects or complex types, $in is safer. However, the main reason is that if the array contains objects, the query won't match a string. Using $in ensures matching any element in the array.

🧠 Conceptual

expert

Impact of document design on scaling

How does document design affect horizontal scaling in MongoDB sharded clusters?

A Poor document design with large embedded arrays can cause uneven shard key distribution and hotspotting.

B Document design does not affect sharding; only shard keys matter.

C Referencing documents across shards automatically balances load evenly.

D Embedding all data in one document always improves scaling by reducing network calls.

💡 Hint

Consider how document size and structure affect shard key distribution and performance.

Large embedded arrays can cause documents to be large and unevenly distributed, leading to hotspots on certain shards. Good document design helps distribute data evenly and improves scaling.