How to speed up mongodb geo queries with multiple criteria?

Status:

As I understand it, after reading the mongodb documentation and also playing around with indexes, queries, and monitoring results, my understanding of how geolocation queries in mongodb work is as follows:

• Start at a given place
• Look at EVERY document from close range.
• keep matching query criteria until reached number_limit
  
  ordistance_limit
  
  

Example

To show what we are trying to do: Let's take the example mongodb tutorial as a base: https://docs.mongodb.com/manual/tutorial/geospatial-tutorial/

Suppose we have a list of restaurants with the location and more information from the top, for example established_at

, type

(Chinese, Thai, Italian, ...), priceOfACoke

, numberOfWaiters

, wheelchairAccess

, ...

Problem:

Let's say you want to request a collection of all restaurants in the US from A to return all Italian restaurants near downtown Pittsburgh that were created between 2-5 years ago with wheel access and 50+ waiters where coke is less than $ 1 ...

This is a geo-query with restrictive additional criteria and a distance limit; and since "waiters> 50 coke cheaper than $ 1" filter out most / all results, this query seems to go through the entire collection and take a very long time.

If you run without "geoNear", assuming there is a merged index of the corresponding fields, this query is quite fast, even if there are only 10 results out of 1 million documents.

However, once it geoNear

comes into play, the performance is terrible

From what I understand, there can only be one geographic index in the collection and only ONE additional property in the geo-information, so there isn't much to do to help mongodb find results with multiple criteria as the traditional index doesn't seem to be used. In addition, when using an aggregate, geo must be the first filter ...

Are there any hints or pointers to speed up queries like this?

If possible, I would rather not get the "Use ElasticSearch" or "Use multiple collections" responses. I still hope there is another way to help mongodb reduce the number of documents to check before it starts acting as geoNear.