Index Creation for Production Server: MongoDB

We know the uses of index, how to create indexes, how to delete indexes – now its time to learn the right way of creating index/key in MongoDB for its optimum usage.

temp: database name
stu: collection name

Inserting 10 Million Documents

use temp
switched to db temp
 
for(i=1; i < = 10000000; i++)
db.no.insert({"student_id": i});

This inserts 10 Million documents inside "stu" collection. It takes atleast a minute or so to complete the insertion - patience is key!

index creation in the foreground

> db.stu.ensureIndex({student_id: 1});
{
        "createdCollectionAutomatically" : false,
        "numIndexesBefore" : 1,
        "numIndexesAfter" : 2,
        "ok" : 1
}

Since there are 10 Million documents inside “stu” collection, it takes some time to create index on “student_id” key.

Things to note:
1. By default, index creation in MongoDB takes place in the foreground.
2. It’s faster than background index creation.
3. It blocks other write operation
4. Ideal to use when in development system – as you’re the only one writing to the server(database). Also ideal to use when you’ve replica sets – where you’ll have multiple set of mongod with same data set to operate on, in which case you can have index information on a separate replica set which helps in faster and efficient index creation.

Background Index Creation: MongoDB

index creation in the background

> db.stu.ensureIndex({student_id: 1}, {background: true});
{
        "createdCollectionAutomatically" : false,
        "numIndexesBefore" : 1,
        "numIndexesAfter" : 2,
        "ok" : 1
}

Simply pass in the option in second parameter to ensureIndex() method – {background: true}

It takes time to complete the process, as there are 10 Million documents in the collection.

Things to note:
1. It’s slower than foreground index creation method.
2. It does not block any other write operation.
3. Ideal in production server/system. As there’ll be other people who’ll be performing read and write operation on the same database server.
4. Ideal when you’re not making use of replica sets yet.