Hash-based sharding in MongoDB - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is hash-based sharding in MongoDB?

Hash-based sharding is a method where MongoDB uses a hash of the shard key's value to distribute data evenly across shards. This helps balance the load by spreading documents uniformly.

beginner

Why does MongoDB use a hash of the shard key for sharding?

Using a hash of the shard key ensures data is spread evenly across shards, preventing hotspots where one shard gets too much data or traffic.

intermediate

How does hash-based sharding differ from range-based sharding?

Hash-based sharding distributes data by hashing the shard key, creating a uniform spread. Range-based sharding divides data into ranges of shard key values, which can lead to uneven distribution if data is skewed.

beginner

What is a shard key in MongoDB's hash-based sharding?

A shard key is a field or set of fields in a document that MongoDB uses to determine how to distribute data across shards. In hash-based sharding, the hash of this key decides the shard placement.

intermediate

What is a potential downside of hash-based sharding?

Hash-based sharding can make range queries less efficient because data is spread randomly, so related data might be on different shards.

What does MongoDB use to decide where to place data in hash-based sharding?

A The range of shard key values

B The document's creation date

C The size of the document

D A hash of the shard key value

MongoDB hashes the shard key value to distribute data evenly across shards.

Which is a benefit of hash-based sharding?

A Data always stored on a single shard

B Faster range queries

C Even data distribution across shards

D Data stored in sorted order

Hash-based sharding spreads data evenly to avoid hotspots.

What is a shard key in MongoDB?

A A password for database access

B A field used to split data across shards

C The name of the database

D The size limit of a shard

The shard key determines how MongoDB distributes data among shards.

What is a downside of hash-based sharding?

A Range queries can be slower

B Data is not evenly distributed

C It only works with numeric keys

D It requires manual data balancing

Because data is spread randomly, range queries may need to check multiple shards.

How does hash-based sharding compare to range-based sharding?

A Hash-based spreads data evenly; range-based can cause uneven distribution

B Range-based always spreads data evenly; hash-based does not

C Both methods store data in sorted order

D Hash-based sharding is slower in all cases

Hash-based sharding uses hashing to balance data, while range-based can lead to uneven data if values cluster.

Explain how hash-based sharding works in MongoDB and why it is used.

Think about how hashing helps spread data evenly.

Describe one advantage and one disadvantage of using hash-based sharding.

Consider how data is spread and how queries might be affected.

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