Is there any way to force a find() or aggregate() query to refer/see a particular existing index in MongoDB. I am asking about the the scenario when a collection has more than one compound indexes.
Yes, $hint is there for that. As mentioned in the documentation, you can use it like that:
db.users.find().hint( { age: 1 } )
What you put in argument is the definition of the index, and not its name. This query would force the use of the index on the age field. I'm not sure though whether it works for aggreate() call as well or not.
Aggregation does not support $hint. There is a open item in MongoDB
https://jira.mongodb.org/browse/SERVER-7944
Related
I have the following MongoDB collection.
[{A:1, B:2}, {A:1, B:1}]
Is there a way to use the property "B" something as the following?
db.myCollection.find({A: '$B'})
I read that there is an approach that calculates the diff of A and B, but what I really want to know is if I can reference document fields when matching documents. This is important for me to understand what I can do and what I cannot do.
I don't believe there is a quick way of doing this. If you want to do it, you can specify a custom $where though, for example:
db.myCollection.find({"$where": "this.A == this.B"})
As noted in the manual though, this will require running that Javascript code for every record in the collection, so this won't be the fastest query in the world.
Hi how can check what index use , and number of scanned objects in aggregate query , something similar to
db.collection.find().explain() ?
Right now, there is no explain functionality for aggregate() yet. However, in general indexes are only used for certain operators if they are the first element in the aggregation operator pipeline. For example, $match and $geoNear.
So in order to figure out which index is being used, simply run the explain() on a find() where the query matches your first $match options.
explain() functionality for aggregate() is an issue in JIRA: https://jira.mongodb.org/browse/SERVER-4504 — I would suggest you vote for the issue on JIRA as well.
I am making an application using pymongo wrapper for which my schema is like:
{
_id: <some_id>,
name: <some_name>,
my_tags: [<list_of_tags>]
}
Now I want to return those entries which falls under the user specified tags. For example,
I want to have entries where my_tags should be atleast ["college", "USA", "engineering"]. For that I read $all construct can be used. Now what I want to know is, would it be of any use making an index on my_tags. For my app, this type of queries are used extensively.
would it be of any use making an index on my_tags. For my app, this type of queries are used extensively.
Yes $all will use an index so it is still good to make one there however there are still optimisations that can be done for it: https://jira.mongodb.org/browse/SERVER-5331 and https://jira.mongodb.org/browse/SERVER-1000
Normally the docs will only warn you of when something can not use an index.
The syntax for the $all query is:
db.collection.find({'my_tags': {'$all': ['college', 'USA', 'engineering']}})
The documentation can be found at:
http://www.mongodb.org/display/DOCS/Advanced+Queries#AdvancedQueries-%24all
I know certain commends need the hashmap / dictionary to be ordered, but does the actual BSON document in MongoDB matter and would the index still work?
E.g.
db.people.ensureIndex({LName:1, FName:1});
Would it work on both:
{LName:"abc", FName:"def"},
{FName:"ghi", LName:"jkl"}
?
Thanks
The order of a document's properties does not affect indexing.
You can see this for yourself by running this query:
db.people.find({LName: "abc"}).explain()
and then this query:
db.people.find({LName: "jkl"}).explain()
you should see that MongoDB will use the index in both cases (the cursor property should be something like "BtreeCursor LName_1_FName_1").
If I write a query and filter results using $where on an indexed field, will it use the index or will it scan into each document? For example?:
function () { return this.indexed_field > 5 }
..and yes I'm well aware I could get away with using $gt in this particular instance =)
No, an index won't be used in that case. You can run an explain() to verify.