Why sharding is needed in MongoDB - Visual Breakdown

Concept Flow - Why sharding is needed

Start: Data grows large

↓

Single server struggles

↓

Performance drops

↓

Need to split data

↓

Implement sharding

↓

Data split across servers

↓

Improved performance & scalability

As data grows, one server can't handle it well, so we split data across servers using sharding to keep performance good.

Execution Sample

MongoDB

db.collection.insertMany([{_id:1,data:'A'}, {_id:2,data:'B'}, /* ... */])
// Data grows large
// Single server slows down
// Shard data across servers
// Queries go to correct shard

Shows data growing, single server slowing, then sharding data to improve query speed.

Execution Table

Step	Data Size	Server Load	Action	Result
1	Small	Low	Insert data	Fast insert and query
2	Medium	Moderate	Insert more data	Slightly slower queries
3	Large	High	Insert more data	Queries slow, server overloaded
4	Large	Overloaded	Decide to shard	Plan data split
5	Large	Distributed	Split data across shards	Load balanced, queries faster
6	Very Large	Distributed	Continue inserting	System scales well, performance stable

💡 Sharding distributes data to avoid overload and keep performance stable as data grows

Variable Tracker

Variable	Start	After Step 2	After Step 4	After Step 6
Data Size	Small	Medium	Large	Very Large
Server Load	Low	Moderate	Overloaded	Distributed
Query Speed	Fast	Slightly slower	Slow	Fast

Key Moments - 3 Insights

Why does the server load increase as data size grows?

Because more data means more work for the server to store and search, shown in execution_table steps 1 to 3.

Why can't we just keep adding data to one server?

One server has limits in memory, CPU, and disk speed, so performance drops as seen in step 3 where queries slow down.

How does sharding help improve performance?

Sharding splits data across servers, balancing load and making queries faster, as shown in steps 5 and 6.

Visual Quiz - 3 Questions

Look at the execution_table, what is the server load at step 3?

A High

B Moderate

C Low

D Distributed

💡 Hint

Check the 'Server Load' column in row for step 3 in execution_table

At which step does the system decide to shard the data?

A Step 2

B Step 4

C Step 3

D Step 6

💡 Hint

Look for the 'Action' column mentioning 'Decide to shard' in execution_table

If data size stayed small, what would happen to server load and query speed?

A Server load moderate, query speed slow

B Server load high, query speed slow

C Server load low, query speed fast

D Server load distributed, query speed fast

💡 Hint

Refer to step 1 in execution_table and variable_tracker for small data size

Concept Snapshot

Why Sharding is Needed:
- Data grows beyond single server capacity
- Server load increases, slowing queries
- Sharding splits data across servers
- Balances load and improves speed
- Enables system to scale with data size

Full Transcript

When data in a database grows large, a single server can struggle to handle all the data and queries. This causes the server load to increase and query speed to slow down. To fix this, we use sharding, which splits the data across multiple servers. This balances the load and keeps queries fast even as data grows. The execution table shows how data size and server load change step by step, and how sharding improves performance.

Practice

1. Why is sharding needed in MongoDB?

easy

A. To split large data across multiple servers for better performance

B. To backup data automatically

C. To encrypt data for security

D. To create indexes on collections

Solution

1. Step 1: Understand the purpose of sharding

   Sharding divides large datasets into smaller parts stored on different servers.

2. Step 2: Identify the benefit of sharding

   This division helps the database handle more data and users efficiently.

3. Final Answer:

   To split large data across multiple servers for better performance -> Option A

4. Quick Check:

   Sharding = splitting data for speed [OK]

Hint: Sharding means splitting data to keep speed fast [OK]

Common Mistakes:

• Confusing sharding with backup
• Thinking sharding is for security
• Mixing sharding with indexing

2. Which of the following is the correct way to enable sharding on a database named mydb in MongoDB shell?

easy

A. sh.enableSharding('mydb')

B. db.enableSharding('mydb')

C. sh.shardEnable('mydb')

D. enableSharding('mydb')

Solution

1. Step 1: Recall the MongoDB shell command for enabling sharding

   The correct command uses the sh object with enableSharding() method.

2. Step 2: Match the correct syntax

   Only sh.enableSharding('mydb') matches the official syntax.

3. Final Answer:

   sh.enableSharding('mydb') -> Option A

4. Quick Check:

   sh.enableSharding() is correct syntax [OK]

Hint: Use sh.enableSharding('dbName') to enable sharding [OK]

Common Mistakes:

• Using db instead of sh
• Wrong method name like shardEnable
• Calling enableSharding without sh prefix

3. Consider a MongoDB cluster with sharding enabled. If a collection is not sharded, what happens when data grows very large?

medium

A. The data is automatically split across shards

B. All data stays on a single server, causing slow queries

C. MongoDB deletes old data to save space

D. The cluster crashes immediately

Solution

1. Step 1: Understand sharding effect on collections

   Only sharded collections split data across servers; unsharded collections stay on one server.

2. Step 2: Predict behavior when data grows large

   Large unsharded collections cause slow queries because one server handles all data.

3. Final Answer:

   All data stays on a single server, causing slow queries -> Option B

4. Quick Check:

   Unsharded = single server, slow queries [OK]

Hint: Unsharded data stays on one server, slowing queries [OK]

Common Mistakes:

• Assuming data auto-splits without sharding
• Thinking MongoDB deletes data automatically
• Believing cluster crashes immediately

4. You tried to shard a collection but got an error: "shard key not found". What is the likely cause?

medium

A. Sharding is not enabled on the cluster

B. The collection is empty

C. You used the wrong database name

D. You did not create an index on the shard key field

Solution

1. Step 1: Understand shard key requirements

   MongoDB requires an index on the shard key field before sharding a collection.

2. Step 2: Identify cause of error

   The error "shard key not found" usually means the shard key field lacks an index.

3. Final Answer:

   You did not create an index on the shard key field -> Option D

4. Quick Check:

   Shard key needs index [OK]

Hint: Shard key must have an index before sharding [OK]

Common Mistakes:

• Ignoring index creation on shard key
• Assuming empty collection causes error
• Confusing database name with shard key

5. A company has a MongoDB database with a collection growing rapidly. They want to keep queries fast and handle many users. Which approach best uses sharding to solve this?

hard

A. Do not shard and increase RAM on the single server

B. Shard the collection using a field with few unique values

C. Shard the collection using a field with high cardinality and evenly distributed values

D. Shard the collection randomly without a shard key

Solution

1. Step 1: Identify good shard key characteristics

   A good shard key has many unique values (high cardinality) and distributes data evenly.

2. Step 2: Evaluate options for sharding

   Using a field with few unique values causes unbalanced shards; random sharding is not possible without a shard key.

3. Step 3: Consider scaling alternatives

   Increasing RAM alone won't handle very large data or many users efficiently.

4. Final Answer:

   Shard the collection using a field with high cardinality and evenly distributed values -> Option C

5. Quick Check:

   Good shard key = high cardinality, even distribution [OK]

Hint: Choose shard key with many unique, evenly spread values [OK]

Common Mistakes:

• Picking shard key with few unique values
• Trying to shard without a shard key
• Relying only on hardware upgrades