📖 Scenario: You are managing a large online store database using MongoDB. To handle the growing number of orders efficiently, you want to distribute the data across multiple servers using sharding. Choosing the right shard key is very important to keep the database fast and balanced.
🎯 Goal: Build a simple MongoDB sharded collection setup by selecting an appropriate shard key and enabling sharding on the database and collection.
📋 What You'll Learn
Create a database called storeDB
Create a collection called orders inside storeDB
Enable sharding on the storeDB database
Shard the orders collection using the orderDate field as the shard key
💡 Why This Matters
🌍 Real World
Large databases need sharding to handle lots of data and traffic efficiently. Choosing the right shard key helps keep the database fast and balanced.
💼 Career
Database administrators and backend engineers often configure sharding to scale applications. Understanding shard keys is essential for managing distributed databases.
Progress0 / 4 steps
1
Create the database and collection
Create a database called storeDB and a collection called orders inside it.
MongoDB
Hint
Use use storeDB to switch to the database, then db.createCollection('orders') to create the collection.
2
Enable sharding on the database
Enable sharding on the storeDB database using the command sh.enableSharding('storeDB').
MongoDB
Hint
Use the sh.enableSharding() command with the database name as a string.
3
Select the shard key
Choose the orderDate field as the shard key for the orders collection by defining the shard key object and creating an index on it. This helps distribute data based on order dates.
MongoDB
Hint
Define a variable shardKey as an object with orderDate set to 1 for ascending order. Then create the index with db.orders.createIndex(shardKey).
4
Shard the collection using the shard key
Shard the orders collection in storeDB using the orderDate field as the shard key with sh.shardCollection('storeDB.orders', shardKey).
MongoDB
Hint
Use sh.shardCollection() with the full collection name and the shard key variable.
Practice
(1/5)
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
Step 1: Understand shard key role
The shard key determines how data is split across multiple servers in a cluster.
Step 2: Importance of even distribution
A good shard key ensures data is balanced, preventing some servers from being overloaded.
Final Answer:
It helps distribute data evenly across servers. -> Option C
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
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).
Step 2: Match correct option
sh.shardCollection('mydb.users', { userId: 1 }) uses the correct format: database.collection and shard key as document with 1.
Final Answer:
sh.shardCollection('mydb.users', { userId: 1 }) -> Option A
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
Step 1: Understand shard key query targeting
Queries that include the shard key field can be routed directly to the relevant shard.
Step 2: Identify query with shard key
Only the query filtering by orderId uses the shard key, so it benefits most.
Final Answer:
db.orders.find({ orderId: 12345 }) -> Option D
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
Step 1: Analyze shard key cardinality
Shard keys with few unique values (low cardinality) cause uneven data distribution.
Step 2: Identify cause of imbalance
Country likely has few distinct values, so one shard holds most data.
Final Answer:
The shard key has low cardinality causing data imbalance. -> Option B
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
Step 1: Evaluate shard key uniqueness
A good shard key has many unique values to distribute data evenly.
Step 2: Match shard key to query patterns
UserId is unique and commonly used in queries, improving efficiency.
Step 3: Avoid low cardinality keys
Country and status have few distinct values, causing imbalance; signupDate is sequential, causing chunk hotspots.
Final Answer:
Use { userId: 1 } because it has many unique values and is in queries. -> Option A
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
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.