Single document atomicity in MongoDB - Time & Space Complexity
We want to understand how the time to update a single document changes as the document size grows.
How does MongoDB handle updates inside one document in terms of speed?
Analyze the time complexity of the following code snippet.
db.collection.updateOne(
{ _id: 123 },
{ $set: { "profile.name": "Alice", "profile.age": 30 } }
)
This code updates fields inside a single document identified by its unique _id.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Access and update fields inside one document.
- How many times: Once per update, no loops over multiple documents.
As the document size grows, the time to update a field inside it grows roughly in a straight line.
| Input Size (document fields) | Approx. Operations |
|---|---|
| 10 | 10 operations |
| 100 | 100 operations |
| 1000 | 1000 operations |
Pattern observation: More fields mean more work, growing steadily with document size.
Time Complexity: O(n)
This means updating a single document takes time proportional to the document's size.
[X] Wrong: "Updating one document always takes the same time no matter its size."
[OK] Correct: Larger documents need more work to find and update fields, so time grows with size.
Knowing how single document updates scale helps you explain database behavior clearly and confidently.
"What if the update changed multiple nested fields instead of just one? How would the time complexity change?"
Practice
single document atomicity mean in MongoDB?Solution
Step 1: Understand atomicity in MongoDB context
MongoDB guarantees that updates to a single document are atomic, meaning all changes in that update happen fully or not at all.Step 2: Compare options with this definition
All changes to a single document happen completely or not at all correctly states this. Options A, B, and D describe behaviors that are not true for single document atomicity.Final Answer:
All changes to a single document happen completely or not at all -> Option AQuick Check:
Single document atomicity = All-or-nothing update [OK]
- Thinking atomicity applies to multiple documents
- Believing only one field updates atomically
- Assuming document locking happens automatically
Solution
Step 1: Identify the correct update method for one document
The methodupdateOneupdates a single document atomically. It uses a filter and an update operator like$set.Step 2: Check each option's syntax
db.collection.updateOne({ _id: 1 }, { $set: { name: 'Alice' } }) usesupdateOnewith$set, which is correct. db.collection.update({ _id: 1 }, { name: 'Alice' }) uses deprecatedupdatewithout update operator. db.collection.modifyOne({ _id: 1 }, { $set: { name: 'Alice' } }) uses a non-existent methodmodifyOne. db.collection.updateMany({ _id: 1 }, { $set: { name: 'Alice' } }) updates many documents, not one.Final Answer:
db.collection.updateOne({ _id: 1 }, { $set: { name: 'Alice' } }) -> Option DQuick Check:
Use updateOne with $set for atomic single document update [OK]
- Using update without $set operator
- Using updateMany when only one document should update
- Using non-existent methods like modifyOne
{ _id: 1, count: 5 }, what will be the document after this atomic update?db.collection.updateOne({ _id: 1 }, { $inc: { count: 3 }, $set: { status: 'active' } })Solution
Step 1: Understand the update operators used
The$incoperator increases thecountfield by 3. The$setoperator adds or updates thestatusfield to 'active'.Step 2: Calculate the new document values
Originalcountis 5, incremented by 3 gives 8. Thestatusfield is set to 'active'.Final Answer:
{ _id: 1, count: 8, status: 'active' } -> Option BQuick Check:
$inc adds 3, $set adds status [OK]
- Thinking $inc replaces the field instead of adding
- Ignoring $set operator effect
- Assuming update fails without errors
db.collection.updateOne({ _id: 2 }, { count: 10, status: 'done' })What is the problem?
Solution
Step 1: Check the update document structure
The update document must use update operators like$setto specify fields to change. Here, the update document lacks any operator.Step 2: Understand MongoDB update syntax rules
Without an operator, MongoDB treats the update document as a replacement document, overwriting the entire document. This causes unexpected behavior if other fields exist.Final Answer:
Missing update operator like $set causes the update to replace the entire document -> Option CQuick Check:
Always use $set or other operators in update document [OK]
- Forgetting $set causes full document replacement
- Assuming updateOne updates fields without operators
- Misunderstanding filter syntax
db.users.updateOne(
{ _id: 123 },
{ $set: { email: 'new@example.com' }, $inc: { logins: 1 } }
)Why is this update atomic and what would happen if you tried to update email and logins in two separate updateOne calls?
Solution
Step 1: Understand atomicity of single document updates
MongoDB guarantees that all changes in a single updateOne call on one document happen fully or not at all, ensuring atomicity.Step 2: Compare single update vs multiple updates
Using one updateOne with both $set and $inc ensures both fields change together. Using two separate updateOne calls risks one succeeding and the other failing, causing inconsistent data.Final Answer:
This update is atomic because both changes happen together; separate calls risk partial updates -> Option AQuick Check:
Single updateOne call = atomic multi-field update [OK]
- Thinking atomicity applies across multiple update calls
- Believing MongoDB can't update multiple fields atomically
- Assuming separate updates are safer
Ready to prove it?
Pass the test and this pattern moves unknown
