Shard key selection importance in MongoDB - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why is shard key selection important in MongoDB?

In MongoDB, choosing the right shard key affects how data is distributed and accessed. Which of the following best explains why selecting an appropriate shard key is crucial?

A It controls the encryption level of the data stored in the cluster.

B It sets the backup frequency for each shard automatically.

C It determines how data is partitioned across shards, impacting query speed and cluster balance.

D It decides the maximum size of each document in the database.

💡 Hint

Think about how data is split and accessed in a distributed system.

The shard key defines how MongoDB distributes data across shards. A good shard key ensures even data distribution and efficient queries. Other options relate to different database features.

❓ query_result

intermediate

What is the output of this shard key usage scenario?

Consider a MongoDB collection sharded on the field userId. If queries mostly filter by userId, what is the expected effect on query performance?

A Queries will be efficient because they target specific shards based on <code>userId</code>.

B Queries will be slow because all shards must be scanned for <code>userId</code>.

C Queries will fail because <code>userId</code> is not a valid shard key.

D Queries will be efficient only if <code>userId</code> is indexed but not sharded.

💡 Hint

Think about how shard keys help route queries.

When queries filter by the shard key, MongoDB routes the query to the relevant shard(s), improving performance. Scanning all shards happens if the shard key is not used in the query filter.

📝 Syntax

advanced

Identify the correct shard key creation command

Which MongoDB command correctly creates a sharded collection with orderId as the shard key?

MongoDB

sh.enableSharding("salesDB");
sh.shardCollection("salesDB.orders", {orderId: 1});

A sh.shardCollection("salesDB.orders", {orderId: "asc"})

B sh.shardCollection("salesDB.orders", "orderId")

C sh.shardCollection("salesDB.orders", {orderId})

D sh.shardCollection("salesDB.orders", {orderId: 1})

💡 Hint

Look for the correct syntax for specifying shard keys as a document with field and direction.

The shard key must be specified as a document with the field name and sort order (1 for ascending). Option D uses the correct syntax. Option D uses a string instead of a document. Option D is invalid syntax. Option D uses a string instead of 1 or -1.

❓ optimization

advanced

Which shard key choice leads to better cluster balance?

You have a collection with a status field that has only three possible values: 'new', 'processing', and 'done'. You want to shard this collection. Which shard key choice will likely lead to better data distribution?

A Shard on a compound key: <code>{status: 1, createdAt: 1}</code>.

B Shard on <code>status</code> field alone.

C Shard on <code>createdAt</code> field alone.

D Shard on a constant value field.

💡 Hint

Think about how many unique values the shard key has and how that affects distribution.

Sharding on status alone causes only three chunks, leading to uneven distribution. Adding createdAt creates many unique shard key values, improving balance. Sharding on createdAt alone can cause hotspotting if data is inserted in order. Sharding on a constant value is invalid.

🔧 Debug

expert

Why does this shard key choice cause a performance problem?

A collection is sharded on the timestamp field, which is always increasing. Over time, queries slow down and one shard becomes overloaded. What is the main reason for this problem?

A The shard key has too many unique values, causing overhead.

B The shard key is monotonically increasing, causing all inserts to go to one shard, creating a hotspot.

C The shard key is not indexed, causing slow queries.

D The shard key is a compound key, which MongoDB does not support.

💡 Hint

Consider how data is distributed when the shard key values increase over time.

Using a monotonically increasing shard key like timestamp causes all new data to be routed to the same shard, creating a hotspot and unbalanced load. This slows down queries and affects cluster performance. MongoDB supports compound keys and indexing is automatic on shard keys.

Practice

1. Why is choosing a good shard key important in MongoDB?

easy

A. It reduces the number of collections.

B. It increases the size of each document.

C. It helps distribute data evenly across servers.

D. It makes the database schema simpler.

Solution

1. Step 1: Understand shard key role

   The shard key determines how data is split across multiple servers in a cluster.

2. Step 2: Importance of even distribution

   A good shard key ensures data is balanced, preventing some servers from being overloaded.

3. Final Answer:

   It helps distribute data evenly across servers. -> Option C

4. Quick Check:

   Shard key = data distribution [OK]

Hint: Shard key controls data spread, pick for balance [OK]

Common Mistakes:

• Thinking shard key changes document size
• Confusing shard key with schema design
• Believing shard key reduces collections

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: 1 })

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

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

D. sh.shardCollection('mydb.users', ['userId'])

Solution

1. Step 1: Review shardCollection syntax

   The correct syntax requires the namespace string and a document specifying the shard key fields with direction (1 or -1).

2. Step 2: Match correct option

   sh.shardCollection('mydb.users', { userId: 1 }) uses the correct format: database.collection and shard key as document with 1.

3. Final Answer:

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

4. Quick Check:

   shardCollection needs {field: 1} format [OK]

Hint: Shard key must be a document with field and 1 or -1 [OK]

Common Mistakes:

• Passing shard key as string instead of document
• Using array instead of document for shard key
• Using 'asc' instead of 1 for direction

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

medium

A. db.orders.find({ customerName: 'Alice' })

B. db.orders.find({ total: { $gt: 100 } })

C. db.orders.find({ status: 'shipped' })

D. db.orders.find({ orderId: 12345 })

Solution

1. Step 1: Understand shard key query targeting

   Queries that include the shard key field can be routed directly to the relevant shard.

2. Step 2: Identify query with shard key

   Only the query filtering by orderId uses the shard key, so it benefits most.

3. Final Answer:

   db.orders.find({ orderId: 12345 }) -> Option D

4. Quick Check:

   Query with shard key = targeted query [OK]

Hint: Queries with shard key filter hit one shard fast [OK]

Common Mistakes:

• Assuming any query benefits from shard key
• Confusing shard key with indexed fields
• Ignoring shard key presence in query

4. You created a shard key on { country: 1 } but notice one shard stores 90% of data. What is the likely problem?

medium

A. The shard key syntax was incorrect.

B. The shard key has low cardinality causing data imbalance.

C. The collection is not sharded properly.

D. The shard key field is missing in documents.

Solution

1. Step 1: Analyze shard key cardinality

   Shard keys with few unique values (low cardinality) cause uneven data distribution.

2. Step 2: Identify cause of imbalance

   Country likely has few distinct values, so one shard holds most data.

3. Final Answer:

   The shard key has low cardinality causing data imbalance. -> Option B

4. Quick Check:

   Low cardinality shard key = data imbalance [OK]

Hint: Low unique shard keys cause uneven data spread [OK]

Common Mistakes:

• Blaming syntax without checking data
• Assuming collection is unsharded
• Ignoring shard key field presence

5. You want to shard a large user collection. Which shard key choice is best to keep data balanced and queries efficient?

hard

A. Use { userId: 1 } because it has many unique values and is in queries.

B. Use { country: 1 } because it groups users by location.

C. Use { signupDate: 1 } because dates are sequential.

D. Use { status: 1 } because it has few distinct values.

Solution

1. Step 1: Evaluate shard key uniqueness

   A good shard key has many unique values to distribute data evenly.

2. Step 2: Match shard key to query patterns

   UserId is unique and commonly used in queries, improving efficiency.

3. Step 3: Avoid low cardinality keys

   Country and status have few distinct values, causing imbalance; signupDate is sequential, causing chunk hotspots.

4. Final Answer:

   Use { userId: 1 } because it has many unique values and is in queries. -> Option A

5. Quick Check:

   High cardinality + query use = best shard key [OK]

Hint: Pick shard key with many unique values and query use [OK]

Common Mistakes:

• Choosing sequential or low cardinality fields
• Ignoring query patterns when selecting shard key
• Assuming grouping fields balance data well