So if I have a query that does the following (in pseudo code)
find(a nearby x, b > y).sort(c)
where a is a geo column, b is type of long, and c is also a type of long
Would the compound index on (a:2d, b:1, c:1) work and suggested?
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Geospatial queries have their own index category (as you mention), and the geohashing greatly improves the index performance of the first key lookup–it’s better than a range if you can set it up right. In any case, I think your strategy will work: the key will be setting $maxDistance to something fairly small.
I inserted 10 million random geo records to match your description, like so:
With the maxDistance at something below 10 the performance is really quite good.
If you leave out maxDistance it starts to suffer quite a bit. Some of the queries took up to 60 seconds to run. The secondary range parameter doesn’t seem to help much, even if the range is fairly narrow–it seems to be all about the maxDistance.
I recommend you play around with it to get a feel for how the geospatial index performs. Here is my test insert loop. You can try limiting the bits as well for less resolution