My problem about Geo-bounding box query indexed

Elastic Stack Elasticsearch
1

Hi, I encountered 2 problems when following the doc, ES version is 7.9.

  1. As the doc when use type="indexed" option in bounding box query, the geo-point type must have lat and lon indexed, but I want to know how to do it? (when I set "lat_lon"=true in mapping, will cause a error "Mapping definition for [location] has unsupported parameters: [lat_lon : true]")

    WeChate52401730d884f885ab18495f903c7a0
    WeChate52401730d884f885ab18495f903c7a01632×372 133 KB

  2. I use this query :

{
  "query": {
    "bool": {
      "must": {
        "match_all": {}
      },
      "filter": {
        "geo_bounding_box": {
          "pin.location": {
            "top_left": {
              "lat": 40.73,
              "lon": -74.1
            },
            "bottom_right": {
              "lat": 40.10,
              "lon": -71.12
            }
          },
          "type": "indexed"
        }
      }
    }
  }
}

to filter this data in ES:

{
                "_index": "my_locations",
                "_type": "_doc",
                "_id": "5",
                "_score": 0.0,
                "_source": {
                    "pin": {
                        "location": [
                            [
                                -71.34,
                                40.12
                            ],
                            [
                                -80,
                                86
                            ]
                        ]
                    }
                }
            }

As the doc ES don't support multi locations per document field when I use type="indexed" option in my query, but actually I got this unexpected data whose location field has 2 pair of geo-point. Is my understanding right? I 'm confused about this.

Thank you for help in advance!:slight_smile:

2

I am not sure anyone will be able to help unless you describe the problems you faced well enough so someone can recreate the issues.

4

I described the 2 problems, could you pls help me solve it? thanks :slight_smile:

5

I open the following issue:

The documentation is stale and actually the parameter has no effect whatsoever in the results of the query. You can safely ignore it.

6

It seems recommend not to use this type parameter, right? But in my local test 500,000 data, I find if I use type=indexed, the bounding box query is faster.

geo-query filter performance(ms) performance(ms) performance(ms)
BoundingBoxQuery 4,127 3,367 4,911
BoundingBoxQueryIndexed 21 14 26

Could you pls tell me why this happened? Does this parameter affect the query speed? :slight_smile: Thank you for help in advance!

7

Could you explain how did you get those numbers? It sounds to me that in one case the query is cached.

8

No,I think is not catched, because I tested a few times and calculate average value.

I have 500,000 data of a index in my local ES, and I use this 2 queryBuilder:

GeoBoundingBoxQueryBuilder geo_bbox_qb = QueryBuilders.geoBoundingBoxQuery("location")
                .setCorners(40.99, -71,
                        40, -69);

GeoBoundingBoxQueryBuilder geo_bbox_qb = QueryBuilders.geoBoundingBoxQuery("location")
                .setCorners(40.99, -71,
                        40, -69).type("indexed");

This 2 query both can get 495,049 data, but for the indexed query, it was faster as above table shows.
Could you pls explain that why you abandon the type parameter, after all it has a better performance through I tested.

9

You are just running the query once? the first time it will run the query but the second time it will use the cache. Therefore the timing difference.

10

You can check by yourself that when building the Lucene query, the type parameter is not used so in both cases you are running exactly the same query:

There is something not right in your methodology. You should use tools like rally to benchmark Elasticsearch.

Maybe you can try reversing the order you are executing your queries and see if the results are consistent?

11

Thank you for your answer! I reversed the query order then this 2 query have similar speed, you are right, before difference caused by cache.:slight_smile:

1 Like
12

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.