Choosing a good shard key in MongoDB - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a shard key in MongoDB?

A shard key is a field or set of fields that determines how data is distributed across different shards in a MongoDB cluster.

beginner

Why should a shard key have high cardinality?

High cardinality means many unique values, which helps distribute data evenly across shards and avoids hotspots.

beginner

What happens if a shard key has low cardinality?

Data may cluster on a few shards causing uneven load and poor performance.

intermediate

How does a shard key affect query performance?

A good shard key allows queries to target specific shards, reducing the amount of data scanned and improving speed.

intermediate

What is a common mistake when choosing a shard key?

Choosing a shard key that is monotonically increasing, like a timestamp or ObjectId, can cause all writes to go to one shard, creating a bottleneck.

Which property is important for a good shard key?

A High cardinality

B Low cardinality

C Always the _id field

D A field with only a few distinct values

A good shard key should have high cardinality to distribute data evenly.

What is a risk of using a monotonically increasing shard key?

A Shards automatically balance

B Data is evenly spread

C Queries become faster

D All writes go to one shard causing a hotspot

Monotonically increasing keys cause writes to target one shard, creating a bottleneck.

How does a good shard key improve query performance?

A By targeting queries to specific shards

B By duplicating data on all shards

C By ignoring the shard key in queries

D By making queries scan all shards

A good shard key lets queries target only relevant shards, speeding up queries.

Which shard key choice can cause uneven data distribution?

A A field with many unique values

B A field with few unique values

C A hashed shard key

D A compound shard key

Few unique values cause data to cluster on few shards, leading to imbalance.

What is a compound shard key?

A A shard key that is always _id

B A shard key with only one field

C A shard key made of multiple fields

D A shard key that changes over time

A compound shard key uses multiple fields to improve data distribution.

Explain what makes a shard key good for MongoDB sharding.

Think about how data spreads and how queries use the shard key.

Describe the problems caused by choosing a monotonically increasing shard key.

Consider how data is inserted over time.

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