Memory and storage engine basics (WiredTiger) in MongoDB - Time & Space Complexity
When using MongoDB's WiredTiger storage engine, it's important to understand how the time to read and write data changes as your data grows.
We want to see how the engine handles more data and what affects the speed of operations.
Analyze the time complexity of a simple document insert and read operation using WiredTiger.
// Insert a document
db.collection.insertOne({ _id: 1, name: "Alice", age: 30 });
// Find a document by _id
db.collection.findOne({ _id: 1 });
This code inserts one document and then retrieves it by its unique _id field.
Look at what happens repeatedly when inserting or finding documents.
- Primary operation: Searching the B-tree index for the _id field.
- How many times: Once per insert or find operation, but the search may traverse multiple tree levels.
As the number of documents grows, the B-tree index grows in height slowly.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 3-4 steps to find a document |
| 100 | About 4-5 steps |
| 1000 | About 5-6 steps |
Pattern observation: The number of steps grows slowly, increasing by a small amount even when data grows a lot.
Time Complexity: O(log n)
This means the time to find or insert a document grows slowly as the data size grows, thanks to the efficient tree structure.
[X] Wrong: "Finding a document always takes the same time no matter how much data there is."
[OK] Correct: The time depends on the size of the data because the engine searches through a tree structure, which grows with data size, so it takes a bit longer as data grows.
Understanding how WiredTiger uses tree structures to keep operations efficient shows you know how databases handle large data smoothly, a useful skill in many real projects.
"What if we added a new index on a non-unique field? How would that affect the time complexity of inserts and queries?"
Practice
Solution
Step 1: Recall MongoDB default engine
MongoDB uses WiredTiger as its default storage engine since version 3.2 for better performance and compression.Step 2: Compare options
MMAPv1 is older, InMemory is for volatile data, RocksDB is not default in MongoDB.Final Answer:
WiredTiger -> Option AQuick Check:
Default engine = WiredTiger [OK]
- Confusing MMAPv1 as default
- Thinking InMemory is default
- Assuming RocksDB is default
mongod.conf?Solution
Step 1: Check correct case for engine name
The engine name is case-sensitive and must be 'wiredTiger' with lowercase 'w' and capital 'T'.Step 2: Validate YAML syntax
storage: engine: WT uses unrecognized abbreviation; C uses all lowercase; D uses incorrect capitalization.Final Answer:
storage: engine: wiredTiger -> Option CQuick Check:
Correct engine name is wiredTiger [OK]
- Using all lowercase 'wiredtiger'
- Using 'WiredTiger' with capital W
- Using abbreviations like 'WT'
mongod.conf snippet:storage:
engine: WiredTiger
wiredTiger:
engineConfig:
cacheSizeGB: 2What does the
cacheSizeGB setting control?Solution
Step 1: Understand cacheSizeGB meaning
cacheSizeGB sets how much RAM WiredTiger uses to cache data in memory for faster access.Step 2: Eliminate other options
It does not control disk space, CPU cores, or network bandwidth.Final Answer:
The amount of RAM WiredTiger uses for caching data -> Option BQuick Check:
cacheSizeGB = RAM cache size [OK]
- Thinking it controls disk space
- Confusing with CPU or network settings
- Ignoring memory tuning importance
cacheSizeGB: 0.5 in mongod.conf but MongoDB starts with poor performance. What is the likely cause?Solution
Step 1: Check WiredTiger cache size limits
WiredTiger performs poorly if cacheSizeGB is less than 1 GB.Step 2: Validate config placement and value type
Decimal values are allowed; placement under wiredTiger.engineConfig is correct; it is not ignored.Final Answer:
cacheSizeGB must be at least 1 GB -> Option AQuick Check:
Minimum cacheSizeGB = 1 GB [OK]
- Using decimal values thinking they are invalid
- Placing cacheSizeGB under wrong config section
- Assuming cacheSizeGB is optional for startup
cacheSizeGB setting is best for WiredTiger, considering MongoDB and OS need memory?Solution
Step 1: Understand memory needs
MongoDB needs memory for cache and other operations; OS and other apps also need RAM.Step 2: Choose balanced cache size
Setting cacheSizeGB to about half or slightly more (8 GB) leaves enough RAM for OS and avoids swapping.Step 3: Evaluate other options
14 or 16 GB risks OS starvation; 2 GB is too low for good performance.Final Answer:
Set cacheSizeGB to 8 to leave memory for OS and other processes -> Option DQuick Check:
Balance cache and OS memory = 8 GB [OK]
- Assigning all RAM to cache causing OS issues
- Setting too low cacheSizeGB hurting performance
- Ignoring OS memory needs
Ready to prove it?
Pass the test and this pattern moves unknown
