Learn About The Concept of Covered Queries in MongoDB

1
4611
Covered Queries

Covered Queries

In this article, we are going to discuss MongoDB’s concept of covered queries. In the earlier articles, we used various approaches to retrieve data from the MongoDB by using projections and ordinary queries. But comparatively, the covered queries are different from these ordinary queries because they operates on the following two conditions.

  • In the covered queries, all the fields should be the part of an index.
  • And, all the returned fields by the queries should be present in the same index.

In the covered queries, the matching of the query condition is done by MongoDB based on the index without looking inside the actual fields of the documents as all the fields given in the covered query are the part of an index. As we know, the data retrieval through the database indexes is always faster than the data retrieved through scanning of all the documents from a collection. Therefore, the covered queries are very fast in their retrieval operation as compared to ordinary MongoDB’s data retrieval queries (ordinary queries).

Implementation of Covered Queries in MongoDB
In the following example, we are going to use covered queries in order to retrieve the required data based on the condition which uses the indexed fields of the documents in a collection named as ‘covered_queries’.

Step 1: – Prepare a ‘save ()’ method in MongoDB on the collection name as ‘covered_queries’. The document has the fields as follows: name, gender, occupation, city, and country. Given below is the save query for MongoDB using above fields to store 5 documents in the collection.

Step 2: – Next, we are creating database index on the three fields as follows: name, gender, and occupation by using the ‘ensureIndex ()’ method as shown below.

Step 3: – Next, we are going to write a covered query in order to retrieve name and gender based on the condition on the occupation field as ‘Employed’ as shown below.

Alternatively, we could write another covered query in order to retrieve name and occupation based on the condition on the gender field as ‘F’ as shown below.

The speciality of the both queries above is the matching condition field and the returned result fields are the part of index created on the documents present in the collection ‘covered_queries’. As a result, the MongoDB will never do the lookup into the actual documents present in this collection instead it will retrieve the result very quickly only with the help of the database index only.

We can also observe that the default ‘ObjectId’ being thrown in the return result by the MongoDB for the above covered queries. We can suppress the ObjectId’ with the help of the following filtering condition as shown below.

Points to remember
We should note that an index cannot cover a query under the following conditions.

  • If any of the indexed fields for the documents in a collection is an array.
  • If any of the indexed fields for the documents in a collection is a subdocument.

Conclusion: –
In this chapter, we discussed the covered queries concept of the MongoDB. We demonstrated a covered query example to analyze the retrieval speed of the covered queries which is faster than the ordinary queries as MongoDB do not scan all the documents present in the collection but prepare the result from the database index only.

1 COMMENT

  1. > db.covered_queries.find ({occupation: “Employed”}, {name: 1, gender: 1}) I ran the above command with adding a explainable object i.e, db.covered_queries.explain().find ({occupation: “Employed”}, {name: 1, gender: 1}) to see the execution plans. It seems like the queries does a collection scan not an index scan.
    I also checked if my index is correct not but the index is correct as well.
    {
    “v” : 1,
    “key” : {
    “gender” : 1,
    “name” : 1,
    “occupation” : 1
    },
    “name” : “gender_1_name_1_occupation_1”,
    “ns” : “week5.covered_queries”
    }
    When i ran the query with explainable method, i got the following

    },
    “winningPlan” : {
    “stage” : “PROJECTION”,
    “transformBy” : {
    “name” : 1,
    “gender” : 1
    },
    “inputStage” : {
    “stage” : “COLLSCAN”,
    “filter” : {
    “occupation” : {
    “$eq” : “Employed”
    }
    },
    “direction” : “forward”
    }
    },

LEAVE A REPLY

Please enter your comment!
Please enter your name here