Database Reference
In-Depth Information
Consequently, if you want your backups to include indexes, then you'll want to opt
for backing up the MongoDB data files themselves. More details about this, and gen-
eral instructions for backups, can be found in chapter 10.
C
OMPACTION
If your application heavily updates existing data, or performs a lot of large deletions,
then you may end up with a highly fragmented index. B-trees will coalesce on their
own somewhat, but this isn't always sufficient to offset a high delete volume. The pri-
mary symptom of a fragmented index is an index size much larger than you'd expect
for the given data size. This fragmented state can result in indexes using more
RAM
than necessary. In these cases, you may want to consider rebuilding one or more
indexes. You can do this by dropping and recreating individual indexes or by running
the
reIndex
command, which will rebuild all indexes for a given collection:
db.values.reIndex();
Be careful about reindexing: the command will take out a write lock for the duration
of the rebuild, temporarily rendering your MongoDB instance unusable. Reindexing
is best done offline, as described earlier for building indexes on a secondary. Note
that the
compact
command, discussed in chapter 10, will also rebuild indexes for the
collection on which it's run.
7.3
Query optimization
Query optimization is the process of identifying slow queries, discovering why they're
slow, and then taking steps to speed them up. In this section, we'll look at each step of
the query optimization process in turn so that by the time you finish reading, you'll
have a framework for addressing problematic queries on any MongoDB installation.
Before diving in, I must warn that the techniques presented here can't be used to
solve
every
query performance problem. The causes of slow queries vary too much.
Poor application design, inappropriate data models, and insufficient physical hard-
ware are all common culprits, and their remedies require a significant time invest-
ment. Here we'll look at ways to optimize queries by restructuring the queries
themselves and by building the most useful indexes. I'll also describe other avenues
for investigation when these techniques fail to deliver.
7.3.1
Identifying slow queries
If your MongoDB-based application feels sluggish, then it's past time to start profiling
your queries. Any disciplined approach to application design should include a query
audit; given how easy MongoDB makes this there's no excuse. Though the require-
ments will vary per application, it's safe to assume that for most apps, queries
shouldn't take much longer than 100 milliseconds. The MongoDB logger has this
assumption ingrained, since it prints a warning whenever any operation, including a
query, takes more than 100 ms. The logs, therefore, are the first place you should look
for slow queries.
