Choosing a good shard key in MongoDB - Time & Space Complexity
When we choose a shard key in MongoDB, it affects how fast queries run as data grows.
We want to know how the choice of shard key changes the work needed to find data.
Analyze the time complexity of querying a sharded collection using a shard key.
// Assume a sharded collection with shard key "userId"
// Query to find documents for a specific userId
const result = db.collection.find({ userId: 12345 });
This query uses the shard key to target a specific shard and find matching documents.
Look at what repeats when the query runs:
- Primary operation: Searching documents on one shard by userId.
- How many times: The search happens once on the targeted shard, scanning matching documents.
As the total data grows, the query only looks at one shard thanks to the shard key.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 10 documents on one shard |
| 100 | About 100 documents on one shard |
| 1000 | About 1000 documents on one shard |
Pattern observation: The work grows with the number of documents on the shard, not the whole database.
Time Complexity: O(m)
This means the query time grows with the number of documents on the shard holding the key, not the total data.
[X] Wrong: "Choosing any shard key will make queries fast everywhere."
[OK] Correct: If the shard key is not selective or balanced, queries may hit many shards or scan large parts, slowing down.
Understanding shard keys helps you design databases that stay fast as they grow, a key skill for real projects.
"What if we changed the shard key to a field with many repeated values? How would the time complexity change?"
Practice
Solution
Step 1: Understand shard key purpose
A shard key is used to split data across servers to balance load and improve speed.Step 2: Identify key characteristic for even distribution
A good shard key has many unique values to avoid data being stored unevenly on shards.Final Answer:
It has many unique values to distribute data evenly. -> Option CQuick Check:
Unique values = balanced shards [OK]
- Thinking shard key must be string
- Choosing small fields regardless of uniqueness
- Assuming numeric only keys are best
{ userId: 1 } in MongoDB?Solution
Step 1: Recall syntax for sharding a collection
The correct command issh.shardCollection(namespace, shardKey), where namespace is 'database.collection'.Step 2: Match options to syntax
sh.shardCollection('mydb.users', { userId: 1 }) uses full namespace 'mydb.users' and correct shard key object { userId: 1 }.Final Answer:
sh.shardCollection('mydb.users', { userId: 1 }) -> Option DQuick Check:
Full namespace + shard key object = correct syntax [OK]
- Using db.shardCollection instead of sh.shardCollection
- Passing shard key as string instead of object
- Omitting database name in namespace
{ country: 1 }, which query will benefit most from the shard key?Solution
Step 1: Understand shard key usage in queries
Queries that include the shard key field can target specific shards, improving speed.Step 2: Identify query with shard key field
Only db.users.find({ country: 'USA' }) filters bycountry, the shard key, so it benefits most.Final Answer:
db.users.find({ country: 'USA' }) -> Option BQuick Check:
Query includes shard key field = faster query [OK]
- Assuming any query runs faster on sharded collection
- Ignoring shard key field in query
- Confusing shard key with indexed fields
{ userId: 1 } but notice all data is stored on one shard. What is the likely cause?Solution
Step 1: Understand shard key distribution
If the shard key has few unique values, data will cluster on few shards causing imbalance.Step 2: Analyze options
Low cardinality ofuserIdcauses data to be stored on one shard, matching the problem.Final Answer:
The userId field has low cardinality (few unique values). -> Option AQuick Check:
Low uniqueness = data imbalance [OK]
- Thinking shard key order affects distribution
- Assuming collection is not sharded without checking
- Ignoring missing shard key fields in documents
orderId, customerId, and orderDate. You want to shard to optimize queries filtering by customerId and range queries on orderDate. Which shard key is best?Solution
Step 1: Identify query patterns
Queries filter bycustomerIdand also use range onorderDate.Step 2: Choose shard key matching query patterns
A compound shard key with{ customerId: 1, orderDate: 1 }supports both equality and range queries efficiently.Final Answer:
{ customerId: 1, orderDate: 1 } -> Option AQuick Check:
Compound shard key matches query filters [OK]
- Choosing single field shard key ignoring query patterns
- Using orderId which is not queried
- Not using compound keys for combined filters
Ready to prove it?
Pass the test and this pattern moves unknown
