Choosing a good shard key in MongoDB - Step-by-Step Execution

Concept Flow - Choosing a good shard key

Start: Need to shard collection

↓

Analyze data access patterns

↓

Identify candidate shard keys

↓

Evaluate shard key properties

↓

Shard collection using chosen key

↓

Monitor performance and rebalance if needed

This flow shows how to pick a shard key by analyzing data and queries, then choosing a key that balances data and query load well.

Execution Sample

MongoDB

db.orders.createIndex({ orderDate: 1 })
db.orders.createIndex({ customerId: 1 })
db.orders.createIndex({ region: 1 })

// Choose shard key based on query and data
sh.shardCollection("shop.orders", { customerId: 1 })

This example creates indexes and chooses customerId as the shard key for balanced distribution and query efficiency.

Execution Table

Step	Action	Evaluation	Result
1	Analyze query patterns	Queries mostly filter by customerId	customerId is a good candidate
2	Check cardinality	customerId has many unique values	High cardinality confirmed
3	Check data distribution	Orders spread evenly across customers	Even data distribution
4	Check write frequency	Writes are frequent per customer	Shard key supports write scaling
5	Choose shard key	customerId meets all criteria	Shard key set to customerId
6	Shard collection	Run sh.shardCollection command	Collection sharded on customerId
7	Monitor	Check chunk distribution and query performance	Balanced load observed
8	Exit	Shard key chosen and applied	Sharding setup complete

💡 Shard key chosen after confirming it supports balanced data and query load

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
candidateShardKey	none	customerId	customerId	customerId	customerId	customerId
cardinality	unknown	unknown	high	high	high	high
dataDistribution	unknown	unknown	unknown	even	even	even
writeFrequency	unknown	unknown	unknown	unknown	frequent	frequent

Key Moments - 3 Insights

Why is high cardinality important for a shard key?

High cardinality means many unique values, which helps distribute data evenly across shards, as shown in execution_table step 2.

Can a shard key with low query usage still be good?

No, a shard key should be used often in queries to route requests efficiently, as seen in step 1 where query patterns guide the choice.

What happens if data distribution is uneven?

Uneven distribution causes some shards to be overloaded, reducing performance. Step 3 checks for even distribution to avoid this.

Visual Quiz - 3 Questions

Look at the execution_table, what is the candidate shard key after Step 1?

A orderDate

B customerId

C region

D none

💡 Hint

Check the 'Evaluation' column in Step 1 of execution_table

At which step does the evaluation confirm high cardinality?

A Step 1

B Step 3

C Step 2

D Step 4

💡 Hint

Look at the 'Evaluation' column for the step mentioning cardinality

If queries mostly filtered by region instead of customerId, what would change in the variable_tracker?

A candidateShardKey would be 'region'

B cardinality would be 'low'

C dataDistribution would be 'uneven'

D writeFrequency would be 'infrequent'

💡 Hint

Refer to candidateShardKey values in variable_tracker and how query patterns affect it

Concept Snapshot

Choosing a good shard key:
- Analyze query patterns and data
- Pick a key with high cardinality
- Ensure even data distribution
- Use a key frequently in queries
- Shard collection with chosen key
- Monitor and rebalance if needed

Full Transcript

Choosing a good shard key in MongoDB involves analyzing how data is accessed and distributed. First, look at which fields queries use most often. Then check if those fields have many unique values (high cardinality) to spread data evenly. Also, ensure data is balanced across shards to avoid hotspots. Finally, pick a shard key that supports your write and read patterns well. This process helps keep your database fast and scalable.

Practice

1. Which of the following is the most important characteristic of a good shard key in MongoDB?

easy

A. It is the smallest field in the document.

B. It is always a string type.

C. It has many unique values to distribute data evenly.

D. It contains only numeric values.

Solution

1. Step 1: Understand shard key purpose

   A shard key is used to split data across servers to balance load and improve speed.

2. Step 2: Identify key characteristic for even distribution

   A good shard key has many unique values to avoid data being stored unevenly on shards.

3. Final Answer:

   It has many unique values to distribute data evenly. -> Option C

4. Quick Check:

   Unique values = balanced shards [OK]

Hint: Choose shard keys with many unique values for balance [OK]

Common Mistakes:

• Thinking shard key must be string
• Choosing small fields regardless of uniqueness
• Assuming numeric only keys are best

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')

B. db.shardCollection('users', { userId: 1 })

C. sh.shardCollection('users', { userId: 1 })

D. sh.shardCollection('mydb.users', { userId: 1 })

Solution

1. Step 1: Recall syntax for sharding a collection

   The correct command is sh.shardCollection(namespace, shardKey), where namespace is 'database.collection'.

2. Step 2: Match options to syntax

   sh.shardCollection('mydb.users', { userId: 1 }) uses full namespace 'mydb.users' and correct shard key object { userId: 1 }.

3. Final Answer:

   sh.shardCollection('mydb.users', { userId: 1 }) -> Option D

4. Quick Check:

   Full namespace + shard key object = correct syntax [OK]

Hint: Use full 'db.collection' name and shard key object [OK]

Common Mistakes:

• Using db.shardCollection instead of sh.shardCollection
• Passing shard key as string instead of object
• Omitting database name in namespace

3. Given a collection sharded on { country: 1 }, which query will benefit most from the shard key?

medium

A. db.users.find({ age: { $gt: 30 } })

B. db.users.find({ country: 'USA' })

C. db.users.find({ name: 'Alice' })

D. db.users.find({ city: 'New York' })

Solution

1. Step 1: Understand shard key usage in queries

   Queries that include the shard key field can target specific shards, improving speed.

2. Step 2: Identify query with shard key field

   Only db.users.find({ country: 'USA' }) filters by country, the shard key, so it benefits most.

3. Final Answer:

   db.users.find({ country: 'USA' }) -> Option B

4. Quick Check:

   Query includes shard key field = faster query [OK]

Hint: Queries with shard key filter run faster [OK]

Common Mistakes:

• Assuming any query runs faster on sharded collection
• Ignoring shard key field in query
• Confusing shard key with indexed fields

4. You created a shard key on { userId: 1 } but notice all data is stored on one shard. What is the likely cause?

medium

A. The userId field has low cardinality (few unique values).

B. The shard key was created with descending order { userId: -1 }.

C. The collection is not sharded yet.

D. The shard key field is missing in some documents.

Solution

1. Step 1: Understand shard key distribution

   If the shard key has few unique values, data will cluster on few shards causing imbalance.

2. Step 2: Analyze options

   Low cardinality of userId causes data to be stored on one shard, matching the problem.

3. Final Answer:

   The userId field has low cardinality (few unique values). -> Option A

4. Quick Check:

   Low uniqueness = data imbalance [OK]

Hint: Low unique shard key values cause data to cluster [OK]

Common Mistakes:

• Thinking shard key order affects distribution
• Assuming collection is not sharded without checking
• Ignoring missing shard key fields in documents

5. You have a large collection of orders with fields orderId, customerId, and orderDate. You want to shard to optimize queries filtering by customerId and range queries on orderDate. Which shard key is best?

hard

A. { customerId: 1, orderDate: 1 }

B. { orderDate: 1 }

C. { orderId: 1 }

D. { customerId: 1 }

Solution

1. Step 1: Identify query patterns

   Queries filter by customerId and also use range on orderDate.

2. Step 2: Choose shard key matching query patterns

   A compound shard key with { customerId: 1, orderDate: 1 } supports both equality and range queries efficiently.

3. Final Answer:

   { customerId: 1, orderDate: 1 } -> Option A

4. Quick Check:

   Compound shard key matches query filters [OK]

Hint: Use compound shard key for multiple query filters [OK]

Common Mistakes:

• Choosing single field shard key ignoring query patterns
• Using orderId which is not queried
• Not using compound keys for combined filters