Denormalization trade-offs in MongoDB - Time & Space Complexity
When we denormalize data in MongoDB, we copy related information into one place to speed up reads.
We want to understand how this affects the time it takes to update or read data as the data grows.
Analyze the time complexity of updating a denormalized document.
// Update user info in many posts where user data is embedded
const userId = "123";
const newName = "Alice";
db.posts.updateMany(
{ "author.id": userId },
{ $set: { "author.name": newName } }
);
This code updates all posts where the author's id matches, changing the embedded author name.
Look for repeated work done by the database.
- Primary operation: Scanning and updating each post with matching author id.
- How many times: Once for each post by that author, which can be many.
As the number of posts by the user grows, the updates take longer.
| Input Size (n posts) | Approx. Operations |
|---|---|
| 10 | 10 updates |
| 100 | 100 updates |
| 1000 | 1000 updates |
Pattern observation: The work grows directly with the number of posts to update.
Time Complexity: O(n)
This means the update time grows linearly with how many documents need changing.
[X] Wrong: "Denormalization always makes updates faster because data is in one place."
[OK] Correct: Actually, denormalization can slow updates because you must change many copies of the same data.
Understanding these trade-offs shows you can think about real-world data design and performance, a key skill in database work.
"What if we used references instead of embedding author data? How would the time complexity of updates change?"
Practice
Solution
Step 1: Understand denormalization purpose
Denormalization stores related data together to speed up reading.Step 2: Compare options with this purpose
Only Faster read operations by storing related data together mentions faster reads by storing data together, which matches denormalization benefits.Final Answer:
Faster read operations by storing related data together -> Option AQuick Check:
Denormalization = Faster reads [OK]
- Confusing denormalization with normalization benefits
- Thinking denormalization reduces storage space
- Assuming denormalization simplifies updates
Solution
Step 1: Identify denormalized data structure
Denormalization stores related data inside one document, like embedding orders inside a user document.Step 2: Check options for embedded data
{ _id: 1, name: 'Alice', orders: [{id: 101, total: 50}] }embeds orders array inside user document, showing denormalization.Final Answer:
{ _id: 1, name: 'Alice', orders: [{id: 101, total: 50}] } -> Option BQuick Check:
Embedded orders = Denormalization [OK]
- Choosing separate documents as denormalized
- Confusing references with embedded data
- Ignoring array embedding as denormalization
{ _id: 1, name: 'Bob', address: { city: 'NY', zip: '10001' } }What happens if Bob moves to 'LA' and you update only the city in this document?
Solution
Step 1: Understand update impact in denormalization
Denormalization duplicates data, so updating one copy doesn't affect others.Step 2: Analyze update effect on embedded address
Updating city in one document changes only that document; duplicates elsewhere remain unchanged.Final Answer:
Only this document's city changes; duplicates elsewhere stay old -> Option CQuick Check:
Update one copy, duplicates unchanged [OK]
- Assuming all duplicates update automatically
- Thinking embedded documents prevent updates
- Believing MongoDB merges conflicting values
Solution
Step 1: Identify update challenges with duplicated data
Duplicated data means updates must be applied to every copy to keep consistency.Step 2: Evaluate options about update behavior
Only Updating phone number requires changing all documents manually correctly states that manual updates to all duplicates are needed.Final Answer:
Updating phone number requires changing all documents manually -> Option AQuick Check:
Manual update needed for duplicates [OK]
- Believing MongoDB auto-syncs duplicates
- Thinking denormalization forbids embedded fields
- Assuming denormalization blocks queries
Solution
Step 1: Analyze read vs update frequency
Many reads and few updates favor denormalization to speed up reads.Step 2: Choose schema matching denormalization benefits
Embedding comments inside posts (Embed all comments inside each post document) stores related data together for fast reads.Step 3: Consider update cost
Few comment edits mean duplicated data update cost is low, so embedding is suitable.Final Answer:
Embed all comments inside each post document -> Option DQuick Check:
Many reads + few updates = Embed data [OK]
- Choosing references despite many reads
- Duplicating data unnecessarily increasing update cost
- Ignoring update frequency in design
Ready to prove it?
Pass the test and this pattern moves unknown
