Performance....Performance!! Quite a headache for the engineers :) But, it anyhow helps to deliver the quality products with client satisfaction. And, at the end that's what all we need!!!
In this article, I will try to cover key considerations for achieving performance at scale using INDEXING.
So, to get it right…..here are the best practices to help you.
Indexes in MongoDB
In any database, indexes support the efficient execution of queries. Without them, the database must scan every document in a collection or table to select those that match the query statement. If an appropriate index exists for a query, the database can use the index to limit the number of documents it must inspect.
MongoDB offers a broad range of index types and features with language-specific sort orders to support complex access patterns to your data. MongoDB indexes can be created and dropped on-demand to accommodate evolving application requirements and query patterns and can be declared on any field within your documents, including fields nested within arrays.
So let's cover how you make the best use of indexes in MongoDB.
Use Compound Indexes
Compound indexes are indexes composed of several different fields. For example, instead of having one index on "Last name" and another on "First name", it is typically most efficient to create an index that includes both "Last name" and "First name" if you query against both of the names. Compound index can still be used to filter queries that specify the last name only.
Follow the ESR rule
For compound indexes, ESR rule of thumb is helpful in deciding the order of fields in the index:
- Add those fields against which Equality queries are run (Filter stage or Match stage)
- The next fields to be indexed should reflect the Sort order of the query (Sort stage)
- The last fields represent the Range of data to be accessed (Project stage)
Use Covered Queries When Possible
Covered queries return results from an index directly without having to access the source documents, and are therefore very efficient.
For a query to be covered all the fields needed for filtering, sorting and/or being returned to the client must be present in an index. To determine whether a query is a covered query, use the explain() method. If the explain() output displays totalDocsExamined as 0, this shows the query is covered by an index.
A common gotcha when trying to achieve covered queries is that the _id field is always returned by default. You need to explicitly exclude it from query results, or add it to the index.
In sharded clusters, MongoDB internally needs to access the fields of the shard key. This means covered queries are only possible when the shard key is part of the index. It is usually a good idea to do this anyway.
Make a note to "Eliminate Unnecessary Indexes" Indexes are resource-intensive: even with compression in the MongoDB WiredTiger storage engine, they consume RAM and disk. As fields are updated, associated indexes must be maintained, incurring additional CPU and disk I/O overhead.
Take Advantage of Multi-Key Indexes for Querying Arrays
If your query patterns require accessing individual array elements, use a multi-key index. MongoDB creates an index key for each element in the array and can be constructed over arrays that hold both scalar values and nested documents.
Recommended indexes are accompanied by sample queries, grouped by query shape (i.e., queries with a similar predicate structure, sort, and projection), that were run against a collection that would benefit from the addition of a suggested index.
If you are happy with the recommendation, you can then roll out the new indexes automatically, without incurring any application downtime :)
Hope you find this post helpful!! Please feel free to leave your views/insights below in comments section. You can connect with me on LinkedIn
Thanks for reading!