Optimization - The Definitive Guide to MongoDB - page 246

for getting to the opposite corner. However, if one of the routes has two stop signs and the other has none, then the
former approach is a more expensive plan, while the latter approach is the best plan to use. Collection scans would
qualify as potential stop signs when executing your queries.
MongoDB ships with a component called the query analyzer. This component takes a query and the collection
the query targets and then produces a set of plans for MongoDB to execute. The explain() function described earlier
in this chapter lists both the plan used and the set of alternative plans produced for a given query.
MongoDB also ships with a query optimizer component. The job of this component is to select which execution
plan is best suited to run a particular query. In most relational database systems, a query optimizer uses statistics
about the distribution of keys in a table, the number of records, the available indexes, the effectiveness of previous
choices, and an assortment of weighting factors to calculate the cost of each approach. It then selects the least
expensive plan to use.
The query optimizer in MongoDB is simultaneously dumber and smarter than the typical RDBMS query
analyzer. For example, it does not use a cost-based method of selecting an execution plan; instead, it runs all of them
in parallel and uses the one that returns the results fastest, terminating all the others after the winner crosses the
finish line. Thus, the query analyzer in MongoDB uses a simple mechanism (dumb) to ensure that it always gets the
fastest result (smart) and the results of these plans are cached and reused for the next 1000 writes, until an explain is
executed or any indexes are added, removed, or reindexed on that collection.
Using hint( ) to Force Using a Specific Index
The query optimizer in MongoDB selects the best index from the set of candidate indexes for a query. It uses the
methods just outlined to try to match the best index or set of indexes to a given query. There may be cases, however,
where the query optimizer does not make the correct choice, in which case it may be necessary to give the component
a helping hand.
You can provide a hint to the query optimizer in such cases, nudging the component into making a different
choice. For example, if you have used explain() to show which indexes are being used by your query, and you think
you would like it to use a different index for a given query, then you can force the query optimizer to do so.
Let's look at an example. Assume that you have an index on a subdocument called author with name and email
fields inside it. Also assume that you have the following defined index:
>db.posts.ensureIndex({author.name:1, author.email:1})
You can use the following hint to force the query optimizer to use the defined index:
>db.posts.find({author:{name:'joe', email: ' [e-mail] ' }}).hint({author.name:1, author.
email:1})
If for some reason you want to force a query to use no indexes, that is, if you want to use collection document
scanning as the means of selecting records, you can use the following hint to do this:
>db.posts.find({author:{name: 'joe', email: ' [e-mail] ' }}).hint({$natural:1})
Optimizing the Storage of Small Objects
Indexes are the key to speeding up data queries. But another factor that can affect the performance of your application
is the size of the data it accesses. Unlike database systems with fixed schemas, MongoDB stores all the schema data for
each record inside the record itself. Thus, for large records with large data contents per field, the ratio of schema data
to record data is low; however, for small records with small data values, this ratio can grow surprisingly large.