Horizontal scaling mental model in MongoDB - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to specify the shard key for horizontal scaling in MongoDB.

MongoDB

sh.shardCollection("mydb.mycollection", { [1]: 1 })

Drag options to blanks, or click blank then click option'

AuserId

Bdatabase

Ctimestamp

Dlocation

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing a field that is not present in all documents

Using a field with low cardinality

The shard key determines how data is distributed across shards. Using userId is common for user-based data partitioning.

2fill in blank

medium

Complete the code to add a new shard to the MongoDB cluster.

MongoDB

sh.addShard("[1]")

Drag options to blanks, or click blank then click option'

Amongos:27017

Badmin:27017

Cconfigsvr:27019

Dshard0001/mongo1:27017

Attempts:

3 left

💡 Hint

Common Mistakes

Using mongos or config server address instead of shard address

The addShard command requires the shard's replica set name and host address, like shard0001/mongo1:27017.

3fill in blank

hard

Fix the error in the command to enable sharding on a database.

MongoDB

sh.enableSharding("[1]")

Drag options to blanks, or click blank then click option'

Aadmin

Bmydb

Cconfig

Dlocal

Attempts:

3 left

💡 Hint

Common Mistakes

Trying to shard system databases like admin or config

Sharding is enabled on user databases like mydb. System databases like admin, config, and local cannot be sharded.

4fill in blank

hard

Fill both blanks to create a shard key with a compound index for better data distribution.

MongoDB

sh.shardCollection("mydb.orders", { [1]: 1, [2]: 1 })

Drag options to blanks, or click blank then click option'

AcustomerId

BorderDate

Cstatus

Dregion

Attempts:

3 left

💡 Hint

Common Mistakes

Using unrelated fields that don't help distribute data evenly

A compound shard key with customerId and orderDate helps distribute data by user and time, improving balance and query efficiency.

5fill in blank

hard

Fill all three blanks to configure a MongoDB sharded cluster with a config server, shard, and mongos router.

MongoDB

config = new Mongo("[1]")
sh.addShard("[2]")
mongos = new Mongo("[3]")

Drag options to blanks, or click blank then click option'

Aconfigsvr1:27019

Bshard0002/mongo2:27017

Cmongos1:27017

Dadmin:27017

Attempts:

3 left

💡 Hint

Common Mistakes

Mixing up ports or using admin database address

The config server runs on configsvr1:27019, the shard is shard0002/mongo2:27017, and the mongos router is mongos1:27017.

Practice

1. What does horizontal scaling in MongoDB primarily involve?

easy

A. Adding more servers to share the data load

B. Increasing the CPU power of a single server

C. Using faster disks on the existing server

D. Compressing data to save space

Solution

1. Step 1: Understand horizontal scaling concept

   Horizontal scaling means adding more machines to handle more data or users.

2. Step 2: Apply to MongoDB context

   MongoDB uses sharding to distribute data across multiple servers, which is horizontal scaling.

3. Final Answer:

   Adding more servers to share the data load -> Option A

4. Quick Check:

   Horizontal scaling = adding servers [OK]

Hint: Horizontal scaling means more servers, not bigger servers [OK]

Common Mistakes:

• Confusing horizontal scaling with vertical scaling
• Thinking faster disks alone is horizontal scaling
• Mixing data compression with scaling

2. Which MongoDB feature is used to implement horizontal scaling?

easy

A. Sharding

B. Indexing

C. Replication

D. Aggregation

Solution

1. Step 1: Recall MongoDB scaling features

   Replication copies data for backup and availability, not scaling data horizontally.

2. Step 2: Identify horizontal scaling feature

   Sharding splits data across servers to scale horizontally.

3. Final Answer:

   Sharding -> Option A

4. Quick Check:

   Horizontal scaling = Sharding [OK]

Hint: Sharding splits data across servers horizontally [OK]

Common Mistakes:

• Confusing replication with sharding
• Thinking indexing scales data horizontally
• Mixing aggregation with scaling

3. Given a MongoDB cluster with 3 shards, each holding 1 million documents, what happens when you add a 4th shard?

medium

A. The cluster stops working until manually rebalanced

B. New data only goes to the 4th shard, old data stays on first 3

C. All data duplicates on the 4th shard

D. Data automatically redistributes to balance across all 4 shards

Solution

1. Step 1: Understand shard addition effect

   Adding a shard triggers MongoDB to redistribute chunks to balance data load.

2. Step 2: Analyze options

   Data automatically redistributes to balance across all 4 shards matches MongoDB's automatic balancing; others describe incorrect behaviors.

3. Final Answer:

   Data automatically redistributes to balance across all 4 shards -> Option D

4. Quick Check:

   Shard addition triggers auto-balancing [OK]

Hint: Adding shards triggers automatic data balancing [OK]

Common Mistakes:

• Assuming new shard only gets new data
• Thinking data duplicates on new shard
• Believing manual rebalance is always required

4. You configured a MongoDB sharded cluster but notice all queries hit only one shard. What is the likely cause?

medium

A. Replication is not enabled

B. Shard key is not properly chosen or missing

C. Indexes are missing on all shards

D. The cluster has too many shards

Solution

1. Step 1: Understand shard key role

   The shard key determines how data is distributed and which shard handles queries.

2. Step 2: Diagnose query routing issue

   If all queries hit one shard, shard key is likely missing or poorly chosen, causing no data distribution.

3. Final Answer:

   Shard key is not properly chosen or missing -> Option B

4. Quick Check:

   Shard key controls query distribution [OK]

Hint: Proper shard key ensures queries spread across shards [OK]

Common Mistakes:

• Blaming replication for query routing
• Assuming indexes affect shard routing
• Thinking too many shards cause single shard hits

5. You have a MongoDB cluster with 5 shards. Your application experiences uneven load because one shard stores much more data than others. What is the best solution to fix this?

hard

A. Increase RAM on the overloaded shard server

B. Add more replicas to the overloaded shard

C. Choose a better shard key that evenly distributes data

D. Disable sharding and use a single server

Solution

1. Step 1: Identify cause of uneven load

   Uneven data distribution usually means the shard key does not distribute data evenly.

2. Step 2: Select best fix

   Changing to a better shard key balances data and load across shards, improving performance.

3. Final Answer:

   Choose a better shard key that evenly distributes data -> Option C

4. Quick Check:

   Balanced shard key = even load [OK]

Hint: Good shard key balances data evenly across shards [OK]

Common Mistakes:

• Adding replicas does not fix data imbalance
• Increasing RAM only helps performance, not distribution
• Disabling sharding removes scaling benefits