Choosing a good shard key in MongoDB - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why is a shard key important in MongoDB?

Imagine you have a huge collection of documents in MongoDB. You want to split this data across many servers to keep things fast and balanced. Why do you need a shard key for this?

A It stores user passwords securely.

B It decides how data is split and helps queries find data quickly.

C It compresses data to save disk space.

D It backs up data automatically every hour.

💡 Hint

Think about how data is divided and found in many places.

The shard key determines how MongoDB divides data across servers. It helps keep data balanced and makes queries efficient by knowing where to look.

❓ query_result

intermediate

What happens if you choose a shard key with low cardinality?

You have a collection where the shard key is a field with only two possible values. What is the likely result when you shard the collection on this key?

A Queries will run faster because of fewer shard key values.

B Data will be perfectly balanced across all servers.

C MongoDB will reject the shard key due to low cardinality.

D Data will be unevenly distributed, causing some servers to hold most data.

💡 Hint

Think about how many different values the shard key has and how data spreads.

Low cardinality means few distinct values. This causes data to cluster on few shards, leading to imbalance and slower performance.

📝 Syntax

advanced

Which shard key definition is valid and efficient for a collection with user activity logs?

You want to shard a collection storing user activity logs. Each document has a userId and a timestamp. Which shard key is best to balance load and support queries filtering by user and time?

MongoDB

db.activity.createIndex({ userId: 1, timestamp: 1 })

A { timestamp: 1 }

B { userId: 1 }

C { userId: 1, timestamp: 1 }

D { activityType: 1 }

💡 Hint

Consider which key helps distribute data and supports common queries.

Using a compound shard key with userId and timestamp balances data by user and supports queries filtering by user and time range.

❓ optimization

advanced

How to avoid hotspotting with a shard key in MongoDB?

You notice one shard is overloaded because many writes target the same shard key value. What is a good way to avoid this hotspotting?

A Choose a shard key with high cardinality and randomness.

B Use a shard key with only a few distinct values.

C Shard on a field that never changes.

D Disable sharding and use a single server.

💡 Hint

Think about spreading writes evenly across shards.

High cardinality and randomness in the shard key help distribute writes evenly, preventing one shard from becoming a hotspot.

🔧 Debug

expert

Why does this shard key choice cause unbalanced data?

A collection is sharded on the country field. Most documents have country set to 'USA'. What problem arises and why?

A Most data goes to one shard, causing imbalance and slow queries.

B MongoDB automatically balances data evenly regardless of shard key.

C The shard key causes data duplication across shards.

D Queries fail because <code>country</code> is not indexed.

💡 Hint

Think about how many documents share the same shard key value.

When most documents share the same shard key value, data clusters on one shard. This causes imbalance and reduces performance.

Practice

1. Which of the following is the most important characteristic of a good shard key in MongoDB?

easy

A. It is the smallest field in the document.

B. It is always a string type.

C. It has many unique values to distribute data evenly.

D. It contains only numeric values.

Solution

1. Step 1: Understand shard key purpose

   A shard key is used to split data across servers to balance load and improve speed.

2. Step 2: Identify key characteristic for even distribution

   A good shard key has many unique values to avoid data being stored unevenly on shards.

3. Final Answer:

   It has many unique values to distribute data evenly. -> Option C

4. Quick Check:

   Unique values = balanced shards [OK]

Hint: Choose shard keys with many unique values for balance [OK]

Common Mistakes:

• Thinking shard key must be string
• Choosing small fields regardless of uniqueness
• Assuming numeric only keys are best

2. Which of the following is the correct syntax to create a sharded collection with shard key { userId: 1 } in MongoDB?

easy

A. sh.shardCollection('mydb.users', 'userId')

B. db.shardCollection('users', { userId: 1 })

C. sh.shardCollection('users', { userId: 1 })

D. sh.shardCollection('mydb.users', { userId: 1 })

Solution

1. Step 1: Recall syntax for sharding a collection

   The correct command is sh.shardCollection(namespace, shardKey), where namespace is 'database.collection'.

2. Step 2: Match options to syntax

   sh.shardCollection('mydb.users', { userId: 1 }) uses full namespace 'mydb.users' and correct shard key object { userId: 1 }.

3. Final Answer:

   sh.shardCollection('mydb.users', { userId: 1 }) -> Option D

4. Quick Check:

   Full namespace + shard key object = correct syntax [OK]

Hint: Use full 'db.collection' name and shard key object [OK]

Common Mistakes:

• Using db.shardCollection instead of sh.shardCollection
• Passing shard key as string instead of object
• Omitting database name in namespace

3. Given a collection sharded on { country: 1 }, which query will benefit most from the shard key?

medium

A. db.users.find({ age: { $gt: 30 } })

B. db.users.find({ country: 'USA' })

C. db.users.find({ name: 'Alice' })

D. db.users.find({ city: 'New York' })

Solution

1. Step 1: Understand shard key usage in queries

   Queries that include the shard key field can target specific shards, improving speed.

2. Step 2: Identify query with shard key field

   Only db.users.find({ country: 'USA' }) filters by country, the shard key, so it benefits most.

3. Final Answer:

   db.users.find({ country: 'USA' }) -> Option B

4. Quick Check:

   Query includes shard key field = faster query [OK]

Hint: Queries with shard key filter run faster [OK]

Common Mistakes:

• Assuming any query runs faster on sharded collection
• Ignoring shard key field in query
• Confusing shard key with indexed fields

4. You created a shard key on { userId: 1 } but notice all data is stored on one shard. What is the likely cause?

medium

A. The userId field has low cardinality (few unique values).

B. The shard key was created with descending order { userId: -1 }.

C. The collection is not sharded yet.

D. The shard key field is missing in some documents.

Solution

1. Step 1: Understand shard key distribution

   If the shard key has few unique values, data will cluster on few shards causing imbalance.

2. Step 2: Analyze options

   Low cardinality of userId causes data to be stored on one shard, matching the problem.

3. Final Answer:

   The userId field has low cardinality (few unique values). -> Option A

4. Quick Check:

   Low uniqueness = data imbalance [OK]

Hint: Low unique shard key values cause data to cluster [OK]

Common Mistakes:

• Thinking shard key order affects distribution
• Assuming collection is not sharded without checking
• Ignoring missing shard key fields in documents

5. You have a large collection of orders with fields orderId, customerId, and orderDate. You want to shard to optimize queries filtering by customerId and range queries on orderDate. Which shard key is best?

hard

A. { customerId: 1, orderDate: 1 }

B. { orderDate: 1 }

C. { orderId: 1 }

D. { customerId: 1 }

Solution

1. Step 1: Identify query patterns

   Queries filter by customerId and also use range on orderDate.

2. Step 2: Choose shard key matching query patterns

   A compound shard key with { customerId: 1, orderDate: 1 } supports both equality and range queries efficiently.

3. Final Answer:

   { customerId: 1, orderDate: 1 } -> Option A

4. Quick Check:

   Compound shard key matches query filters [OK]

Hint: Use compound shard key for multiple query filters [OK]

Common Mistakes:

• Choosing single field shard key ignoring query patterns
• Using orderId which is not queried
• Not using compound keys for combined filters