[on hold] add hard distance filter to short focus.point queries

[orangejulius]

Background

Short autocomplete inputs are very difficult to serve in a performant and low-latency way. With shorter inputs, many more documents match for just about any input string.

In our testing, one to three character input texts generally match up to 100 million documents out of a 560 million document full planet build.

There's really no way to make scoring 100 million documents fast, so in order to achieve acceptable performance (ideally, <100ms P99 latency), it's worth looking at ways to either avoid querying Elasticsearch or reducing the scope of autocomplete queries.

Short autocomplete queries without a focus.point parameter can be cached. There are only 47,000 possible 1-3 character alphanumerical inputs. At this time, caching is outside the scope of Pelias itself but can easily be implemented with Varnish, Nginx, Fastly, Cloudfront, and lots of other tools and services.

Queries with a focus.point are effectively uncachable however, since the coordinate chosen will often be unique.

Changes

This PR is a prototype of using the focus.point coordinate to build a hard filter limiting the search to documents only within a certain radius of the coordinate. This can reduce the number of documents searched and improve performance, while still returning results that are useful.

As it stands, the code essentially takes two values into consideration:

• the input text length below which results will be filtered (currently 4)
• the base filter distance (in kilometers) to be used, which is multiplied by the text length to get the actual filter distance.

In other words, results are currently filtered as follows:

text length	max distance
1	50km
2	100km
3	150km
4+	unlimited

These parameters will eventually be configurable.

Testing, thoughts, and benchmarks appreciated.

[orangejulius]

Here's some benchmark data showing p50 and p99 latency for autocomplete queries of various input lengths as it stands now.

[missinglink]

this looks great, we should add one more commit to make the constants 4 and 50 variable via a config value.

another option to consider alongside this code is to add a layer filter which excludes the address layer up to a certain character count, since it's ~90% the index it would have a huge impact.

Maybe we can enable that for one-token autocomplete queries regardless of whether they have a focus point or not.

[orangejulius]

Yeah, I'm thinking about how we could make this even more powerful in the future.

I think the first thing we need to do is either create a layer or other identifying property unique to airports and then, we could build logic something like this:

• filter all records in layers except admin and airports (in other words: address, street, venue, custom)
• that exceed the focus.point distance currently calculated in this PR

That would allow us to always return admin areas and airports from anywhere, as well as nearby records of all types. That would be the ultimate filter I think, and would allow us to use it on character lengths well beyond 2.

Thoughts?

[Joxit]

50 should not be distanceMultplier ?

[missinglink]

After our discussion last week, we should totally revive this PR!

We discussed varying the geo filter based on layer (which can get a bit messy when dealing with filter combinations) but could actually be much simpler and powerful based on population and popularity.

An example ES query would be something like this (note: it is in the filter clause so it's non-scoring and cachable):

{
    "query": {
        "bool": {
            "filter": [
                {
                    "bool": {
                        "minimum_should_match": 1,
                        "should": [
                            {
                                "range": {
                                    "population": {
                                        "gte": 1000000
                                    }
                                }
                            },
                            {
                                "range": {
                                    "popularity": {
                                        "gte": 1000000
                                    }
                                }
                            },
                            {
                                "geo_distance": {
                                    "distance": "200km",
                                    "center_point": {
                                        "lat": 40,
                                        "lon": -70
                                    }
                                }
                            }
                        ]
                    }
                }
            ]
        }
    }
}

There are two variables which can be varied depending on the length of the test, the population/popularity score is one and the other one is the geo distance (only when a focus point is provided).

I think it would be a fairly simple task to create a new view which considers the length of the input text and sets these variables accordingly.

One other thing we discussed last week, before I forget, was that we don't currently ask for a 'zoom' with our focus point, so it's impossible to know if the user is zoomed out looking at the whole of Australia or zoomed in on a small town in the center.

So I think the distance parameter steps should be fairly large, at the largest it could cover an area as large as 1/5 the planet (or thereabouts), this would still offer a massive performance benefit.

[missinglink]

It would also be great if it was easy to configure the 'steps' and under which conditions they apply, input length alone might not be the only factor to consider.

We should also emit a warning in the geojson response to let users know that a filter has been applied and which variables were used.

[orangejulius]

This was a little too strict in its filtering, and will be replaced either by #1323 or another filtering improvement PR