Optimization - The Definitive Guide to MongoDB - page 241

Compound indexes provide a good way to keep down the number of indexes you have on a collection, allowing
you to combine multiple fields into a single index, so you should try to use compound indexes wherever possible.
There are two main types of compound indexes: subdocument indexes and manually defined compound indexes.
MongoDB has some rules that allow it to use compound indexes for queries that do not use all of the component
keys. Understanding these rules enables you to construct a set of compound indexes that cover all of the queries
you wish to perform against the collection, without having to individually index each element (thereby avoiding the
attendant impact on insert/update performance mentioned earlier).
One area where compound indexes may not be useful is when using the index in a sort. Sorting is not good at
using the compound index unless the list of terms and sort directions exactly matches the index structure.
When you use a subdocument as an index key, the order of the elements used to build the multi-key index
matches the order in which they appear in the subdocument's internal BSON representation. In many cases, this does
not give you sufficient control over the process of creating the index.
To get around this limitation while guaranteeing that the query uses an index constructed in the desired fashion,
you need to make sure you use the same subdocument structure to create the index that you used when forming the
query, as in the following example:
>db.articles.find({author:{name: 'joe', email: ' [e-mail] ' }))
You can also create a compound index explicitly by naming all the fields that you wish to combine in the index,
and then specifying the order in which to combine them. The following example illustrates how to construct a
compound index manually:
>db.posts.ensureIndex({"author.name":1, "author.email":1})
Specifying Index Options
You can specify several interesting options when creating an index, such as creating unique indexes or enabling
background indexing; you'll learn more about these options in the upcoming sections. You specify these options as
additional parameters to the ensureIndex() function, as in the following example:
>db.posts.ensureIndex({author:1}, {option1:true, option2:true, ..... })
Creating an Index in the Background with {background:true}
When you instruct MongoDB to create an index by using the ensureIndex() function for the first time, the server
must read all the data in the collection and create the specified index. By default, index builds are done in the
foreground, and all operations on the collection's database are blocked until the index operation completes.
MongoDB also includes a feature that allows this initial build of indexes to be performed in the background.
Operations by other connections on that database are not blocked while that index is being built. No queries will
use the index until it has been built, but the server will allow read and write operations to continue. Once the index
operation has been completed, all queries that require the index will immediately start using it. It's worth noting that
while an index can be built in the background, it will take longer to complete.
Therefore, you may wish to look at other strategies for building your indexes. Probably the best strategy is to
perform the build in rotation within a replica set. To do this, you stop one secondary at a time and start it without its
--replSet argument and on a different port, temporarily making it a stand-alone node. You can then perform the
index build on this secondary without fear. Once the index build is finished, start the secondary as normal and have
it rejoin the replica set and catch up. Repeat this process for all secondary members. Finally, stop the primary and
perform the same removal of --replSet and build an index process for it, then have it rejoin the replica set as usual.
By rotating through your replica set in this fashion you can build an index without downtime or interruption!