Hash-based sharding in MongoDB - Step-by-Step Execution

Concept Flow - Hash-based sharding

Start: Insert Document

↓

Extract Shard Key Value

↓

Apply Hash Function

↓

Compute Hash Value

↓

Modulo by Number of Shards

↓

Determine Target Shard

↓

Store Document in Target Shard

↓

End

Documents are assigned to shards by hashing the shard key value, then using the hash to pick the shard.

Execution Sample

MongoDB

shardKey = "user_id"
doc = {"user_id": 12345, "name": "Alice"}
hashValue = hash(doc[shardKey])
shardNumber = hashValue % 3
store(doc, shardNumber)

This code hashes the user_id to decide which of 3 shards stores the document.

Execution Table

Step	Action	Input	Hash Value	Modulo Result	Target Shard
1	Extract shard key value	user_id=12345
2	Apply hash function	12345	67890
3	Modulo by number of shards	67890 % 3	67890	0
4	Determine target shard	Modulo result=0			Shard 0
5	Store document	doc in Shard 0			Shard 0

💡 Document stored in Shard 0 based on hash modulo 3 result

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
shardKey	"user_id"	"user_id"	"user_id"	"user_id"	"user_id"	"user_id"
doc	{}	{"user_id":12345,"name":"Alice"}	{"user_id":12345,"name":"Alice"}	{"user_id":12345,"name":"Alice"}	{"user_id":12345,"name":"Alice"}	{"user_id":12345,"name":"Alice"}
hashValue			67890	67890	67890	67890
shardNumber				0	0	0

Key Moments - 3 Insights

Why do we use a hash function on the shard key value?

The hash function converts the shard key into a number that evenly distributes documents across shards, as shown in execution_table step 2.

What does the modulo operation do in hash-based sharding?

Modulo limits the hash value to the number of shards, deciding the exact shard to store the document, as seen in execution_table step 3.

Can two different shard key values end up in the same shard?

Yes, different keys can hash to values that modulo to the same shard number, so multiple keys can be stored in one shard (execution_table steps 3 and 4).

Visual Quiz - 3 Questions

Look at the execution_table, what is the hashValue after applying the hash function?

A 12345

B 67890

C 0

D 3

💡 Hint

Check the 'Hash Value' column at step 2 in the execution_table.

At which step is the target shard determined?

A Step 4

B Step 3

C Step 2

D Step 5

💡 Hint

Look for the step where 'Target Shard' column is filled in execution_table.

If the number of shards changes from 3 to 4, how does the modulo result change for the same hashValue?

A It becomes 1

B It remains 0

C It becomes 2

D It becomes 3

💡 Hint

Calculate 67890 % 4 and compare with the modulo result in execution_table step 3.

Concept Snapshot

Hash-based sharding assigns documents to shards by:
1. Extracting the shard key value.
2. Applying a hash function to it.
3. Using modulo by shard count to pick the shard.
This evenly distributes data and balances load.

Full Transcript

Hash-based sharding in MongoDB works by taking the shard key from a document, applying a hash function to convert it into a numeric hash value, then using modulo division by the number of shards to decide which shard stores the document. This method helps distribute data evenly across shards. The execution steps show extracting the shard key 'user_id' with value 12345, hashing it to 67890, then modulo 3 gives 0, so the document is stored in Shard 0. Variables like shardKey, doc, hashValue, and shardNumber change step by step as the document moves through the process. Key points include why hashing is used for distribution, how modulo picks the shard, and that different keys can map to the same shard. The quiz questions check understanding of hash values, step order, and effects of changing shard count.

Practice

1.

What is the main purpose of hash-based sharding in MongoDB?

easy

A. To store data in sorted order on each shard

B. To compress data before storing it

C. To replicate data for backup purposes

D. To evenly distribute data across shards using a hash function

Solution

1. Step 1: Understand hash-based sharding concept

   Hash-based sharding uses a hash function on the shard key to distribute data evenly.

2. Step 2: Compare options with concept

   Only To evenly distribute data across shards using a hash function describes even distribution using hashing, which matches the concept.

3. Final Answer:

   To evenly distribute data across shards using a hash function -> Option D

4. Quick Check:

   Hash-based sharding = even data distribution [OK]

Hint: Hash-based sharding means even spread by hashing key [OK]

Common Mistakes:

• Confusing hash-based with range-based sharding
• Thinking it sorts data on shards
• Mixing sharding with replication

2.

Which of the following is the correct way to create a hashed shard key on the field userId in MongoDB?

sh.shardCollection("mydb.users", { ??? })

easy

A. { userId: 1 }

B. { userId: "hashed" }

C. { userId: -1 }

D. { userId: true }

Solution

1. Step 1: Recall syntax for hashed shard key

   MongoDB requires the shard key field to be set to "hashed" as a string to enable hash-based sharding.

2. Step 2: Match options with syntax

   Only { userId: "hashed" } uses the correct syntax: { userId: "hashed" }.

3. Final Answer:

   { userId: "hashed" } -> Option B

4. Quick Check:

   Hashed shard key syntax = { field: "hashed" } [OK]

Hint: Hashed keys use string "hashed" in shard key spec [OK]

Common Mistakes:

• Using 1 or -1 instead of "hashed"
• Using boolean true instead of string
• Omitting quotes around hashed

3.

Given a collection sharded by { userId: "hashed" }, which shard will store the document { userId: 42, name: "Alice" }?

Assume the hash function maps 42 to a hash value that falls into shard 2's range.

medium

A. Shard 2

B. Cannot determine without full hash map

C. Shard 3

D. Shard 1

Solution

1. Step 1: Understand hashed shard key routing

   Documents are routed to shards based on the hash of the shard key value.

2. Step 2: Use given hash mapping

   The problem states the hash of 42 falls into shard 2's range, so the document goes to shard 2.

3. Final Answer:

   Shard 2 -> Option A

4. Quick Check:

   Hash value maps to shard 2 [OK]

Hint: Hash value decides shard, not raw key [OK]

Common Mistakes:

• Assuming shard based on userId value directly
• Choosing 'Cannot determine' when info is given
• Confusing shard ranges with key values

4.

Consider this command to shard a collection:

sh.shardCollection("mydb.orders", "orderId: hashed")

After running this, you get an error: "Error: shard key must be an object". What is the likely cause?

medium

A. The shard key argument must be an object, but a string was passed

B. The shard key value should be 1 or -1, not "hashed"

C. The command syntax is correct; the error is from elsewhere

D. The database name is missing in the command

Solution

1. Step 1: Check shardCollection syntax

   The shard key must be an object specifying the field and type, e.g., { orderId: "hashed" }.

2. Step 2: Identify error cause

   The error says shard key must be an object, so likely the argument passed was not an object but a string or other type.

3. Final Answer:

   The shard key argument must be an object, but a string was passed -> Option A

4. Quick Check:

   Shard key must be an object [OK]

Hint: Shard key must be an object, not a string [OK]

Common Mistakes:

• Passing shard key as string instead of object
• Confusing shard key with database name
• Ignoring error message details

5.

You want to shard a collection by email using hash-based sharding. However, you notice some shards have much more data than others. What could be a reason for this uneven distribution?

hard

A. The shard key was set to { email: 1 } instead of hashed

B. Hash-based sharding always causes uneven data distribution

C. The email field has many duplicate values causing hash collisions

D. The collection is too small to distribute evenly

Solution

1. Step 1: Understand hash-based sharding behavior

   Hash-based sharding usually distributes data evenly unless many documents share the same shard key value.

2. Step 2: Analyze cause of uneven data

   If many documents have the same email, their hash is the same, so they go to the same shard, causing imbalance.

3. Final Answer:

   The email field has many duplicate values causing hash collisions -> Option C

4. Quick Check:

   Duplicate keys cause uneven shard data [OK]

Hint: Duplicates in shard key cause uneven shard sizes [OK]

Common Mistakes:

• Assuming hash sharding always balances perfectly
• Confusing range-based with hash-based sharding
• Ignoring data distribution of shard key values