Range-based sharding in MongoDB - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

Find the shard key range for a given document

Given a MongoDB sharded collection with a range-based shard key on the field age, which shard will store the document { "name": "Alice", "age": 25 } if the shard ranges are:

- Shard1: age < 20
- Shard2: 20 ≤ age < 40
- Shard3: age ≥ 40

Choose the correct shard that will contain Alice's document.

A Shard2

B Shard1

C Shard3

D None of the above

💡 Hint

Check which range the age 25 falls into.

Since Alice's age is 25, it falls within the range 20 ≤ age < 40, which belongs to Shard2.

🧠 Conceptual

intermediate

Understanding range-based shard key distribution

Why is range-based sharding potentially problematic if the incoming data is mostly increasing in the shard key value?

Choose the best explanation.

A It evenly distributes writes across all shards.

B It causes all writes to go to a single shard, leading to unbalanced load.

C It causes queries to be slower because all shards must be scanned.

D It prevents any shard from storing data.

💡 Hint

Think about what happens if new data always has a higher shard key value.

If data mostly increases in shard key value, all new writes go to the shard holding the highest range, causing that shard to be overloaded.

📝 Syntax

advanced

Identify the correct MongoDB command to enable range-based sharding

Which of the following MongoDB shell commands correctly enables sharding on the users collection using age as the shard key with range-based sharding?

A sh.shardCollection("mydb.users", "age")

B sh.enableSharding("mydb.users", { age: 1 })

C sh.shardCollection("mydb", { users: { age: 1 } })

D sh.shardCollection("mydb.users", { age: 1 })

💡 Hint

The command to shard a collection requires the namespace and shard key as an object.

The correct syntax is sh.shardCollection("database.collection", { shardKey: 1 }) to enable range-based sharding on the shard key.

❓ optimization

advanced

Optimizing range-based shard key selection

You have a collection where most queries filter by region and timestamp. Which shard key choice will best optimize query performance and data distribution using range-based sharding?

A { region: 1, timestamp: 1 }

B { timestamp: 1 }

C { region: 1 }

D { _id: 1 }

💡 Hint

Consider which fields are used in queries and how combining them affects shard distribution.

Using a compound shard key on region and timestamp allows queries filtering on both fields to target specific shards and balances data by region and time.

🔧 Debug

expert

Diagnose the cause of unbalanced shards in range-based sharding

A MongoDB cluster uses range-based sharding on the orderDate field. Over time, one shard stores 90% of the data, causing performance issues. What is the most likely cause?

A The shard key is not indexed.

B The cluster has too many shards configured.

C The shard key <code>orderDate</code> is monotonically increasing, causing all new inserts to go to one shard.

D The data is evenly distributed but queries are slow.

💡 Hint

Think about how range-based sharding handles sequential values.

A monotonically increasing shard key causes all new data to be routed to the last shard range, leading to unbalanced data and load.

Practice

1. What is the main idea behind range-based sharding in MongoDB?

easy

A. Data is randomly distributed across shards.

B. Data is split into ranges based on shard key values.

C. Data is duplicated on all shards for backup.

D. Data is stored only on a single shard.

Solution

1. Step 1: Understand range-based sharding concept

   Range-based sharding divides data into continuous ranges based on shard key values.

2. Step 2: Compare with other options

   Random distribution or duplication are not characteristics of range-based sharding.

3. Final Answer:

   Data is split into ranges based on shard key values. -> Option B

4. Quick Check:

   Range-based sharding = Data split by ranges [OK]

Hint: Remember: range-based means splitting by value ranges [OK]

Common Mistakes:

• Confusing range-based with hash-based sharding
• Thinking data is duplicated on all shards
• Assuming data is randomly distributed

2. Which of the following is the correct way to enable range-based sharding on a collection in MongoDB?

easy

A. sh.shardRangeCollection("db.collection", { "field": 1 })

B. sh.enableRangeSharding("db.collection")

C. db.collection.shardRange({ "field": 1 })

D. sh.shardCollection("db.collection", { "field": 1 })

Solution

1. Step 1: Recall MongoDB sharding command

   The correct command to shard a collection by a key is sh.shardCollection() with the shard key.

2. Step 2: Verify syntax correctness

   sh.shardCollection("db.collection", { "field": 1 }) uses the correct syntax: sh.shardCollection("db.collection", { "field": 1 }). Other options are invalid commands.

3. Final Answer:

   sh.shardCollection("db.collection", { "field": 1 }) -> Option D

4. Quick Check:

   Use sh.shardCollection() to enable sharding [OK]

Hint: Use sh.shardCollection() with shard key object [OK]

Common Mistakes:

• Using non-existent commands like sh.enableRangeSharding
• Incorrect method names like shardRangeCollection
• Passing wrong parameters or missing shard key

3. Given a collection sharded by the field age with ranges: { age: { $lt: 20 } }, { age: { $gte: 20, $lt: 40 } }, and { age: { $gte: 40 } }, which shard will store a document with { age: 35 }?

medium

A. Shard with range { age: { $gte: 20, $lt: 40 } }

B. Shard with range { age: { $lt: 20 } }

C. Shard with range { age: { $gte: 40 } }

D. Document will be stored on all shards

Solution

1. Step 1: Identify the correct range for age 35

   Age 35 fits in the range where age is greater or equal to 20 and less than 40.

2. Step 2: Match the range to the shard

   The shard with range { age: { $gte: 20, $lt: 40 } } will store the document.

3. Final Answer:

   Shard with range { age: { $gte: 20, $lt: 40 } } -> Option A

4. Quick Check:

   35 is between 20 and 40, so goes to that shard [OK]

Hint: Match value to shard range boundaries carefully [OK]

Common Mistakes:

• Choosing the shard with $lt: 20 incorrectly
• Assuming document is stored on all shards
• Confusing range boundaries (gte vs lt)

4. You have a range-based sharded collection on score with ranges: { score: { $lt: 50 } } and { score: { $gte: 50 } }. You try to insert { score: "high" } but get an error. What is the likely cause?

medium

A. The shard key ranges overlap causing conflict.

B. The shard key field is missing in the document.

C. The shard key value type does not match the defined range type.

D. MongoDB does not support string values in shard keys.

Solution

1. Step 1: Understand shard key type requirements

   Shard key values must match the type used in range definitions. Here, ranges expect numeric scores.

2. Step 2: Identify the error cause

   Inserting a string "high" for a numeric shard key causes a type mismatch error.

3. Final Answer:

   The shard key value type does not match the defined range type. -> Option C

4. Quick Check:

   Shard key types must match range types [OK]

Hint: Shard key values must match range data types [OK]

Common Mistakes:

• Assuming missing shard key field causes this error
• Thinking overlapping ranges cause insert errors
• Believing MongoDB disallows strings in shard keys

5. You want to shard a large user collection by signupDate using range-based sharding. Which shard key choice will best support queries filtering users by recent signup dates?

hard

A. Use { signupDate: 1 } as shard key to split by date ranges.

B. Use { userId: 1 } as shard key for even data distribution.

C. Use { signupDate: "hashed" } to hash dates for randomness.

D. Use { lastLogin: 1 } as shard key for login-based queries.

Solution

1. Step 1: Identify query pattern

   Queries filter users by recent signup dates, so shard key should support range queries on signupDate.

2. Step 2: Choose shard key matching query pattern

   Using { signupDate: 1 } enables range-based sharding by date, optimizing these queries.

3. Step 3: Evaluate other options

   Hashing or using unrelated fields won't support efficient range queries on signupDate.

4. Final Answer:

   Use { signupDate: 1 } as shard key to split by date ranges. -> Option A

5. Quick Check:

   Shard key matches query field for best performance [OK]

Hint: Match shard key to common query field for range queries [OK]

Common Mistakes:

• Choosing hashed shard key when range queries are needed
• Picking unrelated fields like userId or lastLogin
• Ignoring query patterns when selecting shard key