Is there a way to force mongodb to store a specific index in ram?

Question

I have a collection with a relatively large index (but less than it has), and looking at the search performance in this collection and the amount of free bar in my system given by htop, it seems that mongo does not store the full index in RAM. Is there a way to get mongo to store this particular index in ram?

Request example:

> db.barrels.find({"tags":{"$all": ["avi"]}}).explain() { "cursor" : "BtreeCursor tags_1", "nscanned" : 300393, "nscannedObjects" : 300393, "n" : 300393, "millis" : 55299, "indexBounds" : { "tags" : [ [ "avi", "avi" ] ] } } 

Not all objects are tagged with avi:

 > db.barrels.find().explain() { "cursor" : "BasicCursor", "nscanned" : 823299, "nscannedObjects" : 823299, "n" : 823299, "millis" : 46270, "indexBounds" : { } } 

Without "$ all":

 db.barrels.find({"tags": ["avi"]}).explain() { "cursor" : "BtreeCursor tags_1 multi", "nscanned" : 300393, "nscannedObjects" : 300393, "n" : 0, "millis" : 43440, "indexBounds" : { "tags" : [ [ "avi", "avi" ], [ [ "avi" ], [ "avi" ] ] ] } } 

This also happens when I look for two or more tags (it scans each element as if there was no index):

 > db.barrels.find({"tags":{"$all": ["avi","mp3"]}}).explain() { "cursor" : "BtreeCursor tags_1", "nscanned" : 300393, "nscannedObjects" : 300393, "n" : 6427, "millis" : 53774, "indexBounds" : { "tags" : [ [ "avi", "avi" ] ] } } 

Answer 1

Not. MongoDB allows the system to control what is stored in RAM.

With that said, you can save the index in RAM by running queries against indexes (check the query hint ) periodically so that they do not become obsolete.

Useful links:

• Checking server memory usage

• Indexing Guidelines and Frequently Asked Questions

In addition, Kristina Chodorov provides this excellent answer on the relationship between MongoDB Indexes and RAM

---

UPDATE:

After updating to provide .explain () output, I see the following:

• The request falls into the index.
• nscanned is the number of items (documents or index entries).
• nscannedObjects - the number of documents checked
• n is the number of documents matching the specified criteria
• Your data set is 300,393 records, which is the total number of elements in the index and the corresponding results.

Perhaps I am reading this incorrectly, but what I am reading is that all the elements in your collection are real results. Without knowing your data, it would seem that each element contains an "avi" tag. Another thing is that this means that this indicator is almost useless; indexes provide the most value when they work to narrow the resulting field as much as possible.

From MongoDB " Indexing Tips and FAQs ":

Understanding the explanation of the conclusion. There are three main fields: when checking the output of an explanation command:

• cursor: the value for the cursor can be either BasicCursor or BtreeCursor. The second one indicates that the given query uses an index.
• nscanned: number of documents scanned.
• n: the number of documents returned by the request. You want the n value to be close to the nscanned value. What you want to avoid is scanning the collection, that is, when each document in the collection is accessed. This is the case when nscanned is equal to the number of documents in the collection.
• millis: the number of milliseconds required to complete the request. This value is useful for comparing indexing strategies indexed versus unindexed queries, etc.

Answer 2

Is there a way to get mongo to store this particular index in ram?

Of course, you can only go around an index with an index. This will force MongoDB to load each block of the index. But it should be "only for index", otherwise you will also download all related documents.

The only advantage it will give is to make some potential future queries faster if those parts of the index are required.

However, if there are parts of the index that are not already running queries, why change this?