When not to index in MongoDB - Mini Project: Build & Apply

When Not to Index in MongoDB

📖 Scenario: You are managing a MongoDB database for a small online bookstore. You want to understand when it is better not to create indexes on certain fields to keep the database efficient.

🎯 Goal: Learn to create a collection with sample book data, add a configuration variable to decide when to index, write conditional logic to create an index only if the document count is above the threshold, and finalize the collection setup without unnecessary indexes.

📋 What You'll Learn

Create a MongoDB collection named books with specific documents

Add a variable minIndexCount to decide the minimum number of documents before indexing

Write conditional logic to create an index on genre only if the number of documents is above minIndexCount

Ensure the collection does not have an index on genre if the document count is low

💡 Why This Matters

🌍 Real World

In real applications, creating indexes on small collections can waste storage and slow down writes. This project shows how to avoid unnecessary indexes.

💼 Career

Database administrators and backend developers must know when to create indexes to optimize performance and resource use.

1

Create the books collection with sample data

Create a MongoDB collection called books and insert exactly these three documents: { title: "Book A", genre: "Fiction", pages: 200 }, { title: "Book B", genre: "Non-Fiction", pages: 150 }, and { title: "Book C", genre: "Fiction", pages: 300 }.

MongoDB

// Insert the three specified documents into the books collection

Hint

Use insertMany to add multiple documents at once.

2

Add a variable minIndexCount to control indexing

Create a variable called minIndexCount and set it to 5. This variable will decide the minimum number of documents needed before creating an index.

MongoDB

db.books.insertMany([
  { title: "Book A", genre: "Fiction", pages: 200 },
  { title: "Book B", genre: "Non-Fiction", pages: 150 },
  { title: "Book C", genre: "Fiction", pages: 300 }
])

// Create minIndexCount variable

Hint

Use const to declare the variable minIndexCount.

3

Write a conditional index creation logic

Write code that counts documents in books and creates an index on genre only if the count is greater than or equal to minIndexCount. Use db.books.countDocuments() and db.books.createIndex({ genre: 1 }).

MongoDB

db.books.insertMany([
  { title: "Book A", genre: "Fiction", pages: 200 },
  { title: "Book B", genre: "Non-Fiction", pages: 150 },
  { title: "Book C", genre: "Fiction", pages: 300 }
])

const minIndexCount = 5

// Add conditional index creation code here

Hint

Use countDocuments() to get the number of documents, then an if statement to check if it meets minIndexCount.

4

Finalize collection without unnecessary indexes

Ensure the books collection does not have an index on genre if the document count is less than minIndexCount. Do not create the index manually.

MongoDB

db.books.insertMany([
  { title: "Book A", genre: "Fiction", pages: 200 },
  { title: "Book B", genre: "Non-Fiction", pages: 150 },
  { title: "Book C", genre: "Fiction", pages: 300 }
])

const minIndexCount = 5

const count = db.books.countDocuments()
if (count >= minIndexCount) {
  db.books.createIndex({ genre: 1 })
}

// Finalize collection setup without unnecessary indexes

Hint

Do not create the index manually if the count is below the threshold.

Practice

1. Which of the following is a good reason not to create an index on a MongoDB collection?

easy

A. The collection is very small and queries are fast without indexes.

B. The field is frequently used in queries to filter data.

C. The collection has millions of documents and needs fast lookups.

D. The field has many unique values and is often sorted.

Solution

1. Step 1: Understand index impact on small collections

   Indexes add overhead and use space, so on very small collections, queries are already fast without them.

2. Step 2: Compare with other options

   The other options describe good reasons to create indexes: frequent filtering, large collections, and fields with many unique values used in sorting.

3. Final Answer:

   The collection is very small and queries are fast without indexes. -> Option A

4. Quick Check:

   Small collections often don't need indexes [OK]

Hint: Avoid indexing tiny collections to save space and speed [OK]

Common Mistakes:

• Thinking all collections always need indexes
• Ignoring index overhead on small data
• Confusing frequent query fields with rare ones

2. Which MongoDB command correctly creates an index on the email field of the users collection?

easy

A. db.users.create_index(email)

B. db.users.createIndex({email: 1})

C. db.users.index({email: 'asc'})

D. db.users.addIndex('email')

Solution

1. Step 1: Recall MongoDB index creation syntax

   The correct method is createIndex with a document specifying field and order (1 for ascending).

2. Step 2: Check each option

   db.users.createIndex({email: 1}) matches the correct syntax. The distractors use wrong method names or formats: create_index(email) (incorrect casing, underscore, and argument style), index({email: 'asc'}) (non-existent method), addIndex('email') (wrong method).

3. Final Answer:

   db.users.createIndex({email: 1}) -> Option B

4. Quick Check:

   Use createIndex({field: 1}) syntax [OK]

Hint: Use createIndex({field: 1}) to create ascending index [OK]

Common Mistakes:

• Using wrong method names like create_index
• Passing field name as string instead of object
• Confusing ascending with string 'asc'

3. Given a collection logs with a field status that has only two values: 'success' or 'fail', what is the likely effect of creating an index on status?

medium

A. The index will use extra space but provide no significant speedup.

B. The index will cause errors because of low cardinality.

C. Queries filtering by status will be much faster due to the index.

D. The index will automatically compress the data to save space.

Solution

1. Step 1: Understand low cardinality fields and indexing

   Fields with few distinct values (low cardinality) like 'success'/'fail' do not benefit much from indexes because many documents share the same value.

2. Step 2: Analyze options

   Claims of much faster queries overestimate benefits for low cardinality. No errors occur from low cardinality indexes. Automatic data compression does not happen. The index uses extra space with no significant speedup.

3. Final Answer:

   The index will use extra space but provide no significant speedup. -> Option A

4. Quick Check:

   Low cardinality fields rarely benefit from indexes [OK]

Hint: Avoid indexing fields with few unique values [OK]

Common Mistakes:

• Assuming all indexes speed up queries
• Believing low cardinality causes errors
• Thinking indexes compress data automatically

4. You created an index on the category field of a MongoDB collection, but queries filtering by category are still slow. What is a likely cause?

medium

A. MongoDB does not support indexing on string fields.

B. The index was created with the wrong field name syntax.

C. The category field has very few distinct values causing low index efficiency.

D. The collection is empty, so indexes do not work.

Solution

1. Step 1: Consider index usefulness on low distinct values

   If category has few unique values, the index won't help much because many documents share the same value.

2. Step 2: Evaluate other options

   Wrong field name syntax is unlikely if the index exists; MongoDB supports indexing on string fields; empty collections have no data to slow down queries.

3. Final Answer:

   The category field has very few distinct values causing low index efficiency. -> Option C

4. Quick Check:

   Low distinct values reduce index speedup [OK]

Hint: Check field cardinality if index doesn't speed queries [OK]

Common Mistakes:

• Assuming all indexes always speed queries
• Believing MongoDB can't index strings
• Thinking empty collections cause index failure

5. You have a MongoDB collection orders with 100 documents. The status field has values 'pending', 'shipped', 'delivered'. You want to optimize queries filtering by status. What is the best indexing strategy?

hard

A. Create multiple indexes on each possible status value separately.

B. Create a single-field index on status to speed up queries.

C. Create a compound index on status and orderDate even if orderDate is rarely queried.

D. Do not create an index because the collection is small and status has few distinct values.

Solution

1. Step 1: Analyze collection size and field cardinality

   The collection is very small (100 documents), and status has only three distinct values, so indexing will add overhead without much benefit.

2. Step 2: Evaluate indexing options

   Create a single-field index on status to speed up queries. creates an index but likely unnecessary here. Create a compound index on status and orderDate even if orderDate is rarely queried. adds complexity with rarely used field. Create multiple indexes on each possible status value separately. is invalid as MongoDB does not create separate indexes per value.

3. Final Answer:

   Do not create an index because the collection is small and status has few distinct values. -> Option D

4. Quick Check:

   Small collections and low cardinality fields often don't need indexes [OK]

Hint: Skip indexes on small collections with few unique values [OK]

Common Mistakes:

• Creating unnecessary indexes on small data
• Misunderstanding compound index benefits
• Trying to index each value separately