简体   繁体   English

ElasticSearch RANGE 查询未按预期工作

[英]ElasticSearch RANGE query doesn't work as expected

I am trying to run RANGE query on nested document using ES 7.7 Java API. I noticed that it is not filtering data as expected.我正在尝试使用 ES 7.7 Java API 对嵌套文档运行 RANGE 查询。我注意到它没有按预期过滤数据。 When I put debug statements on the actual query that ES runs, I am not able to get the appropriate results back mainly for "to" section of range query.当我将调试语句放在 ES 运行的实际查询上时,我无法主要针对范围查询的“to”部分获得适当的结果。 I have noticed that GT or GTE works fine by LT and LTE is not working as expected as well.我注意到 GT 或 GTE 在 LT 上工作正常,而 LTE 也没有按预期工作。

Below is the simple Java code for this range query.下面是这个范围查询的简单 Java 代码。 Please note that weight within the nested document is defined as float like ""weight": {"type": "float"}," .请注意,嵌套文档中的权重被定义为浮点数,如""weight": {"type": "float"},"

query.must(QueryBuilders.nestedQuery(fields[0], QueryBuilders.rangeQuery(c.getField()).from(c.getValues().get(0)).to(c.getValues().get(1)),ScoreMode.None).innerHit(innerHitBuilder));

Below is the Java API code example for LT.以下是 LT 的 Java API 代码示例。

query.must(QueryBuilders.nestedQuery(fields[0], QueryBuilders.rangeQuery(c.getField()).lt(c.getValue()), ScoreMode.None).innerHit(innerHitBuilder));

Below is the query that ES actually runs for the above statement RANGE query statement.下面是ES对上面语句RANGE查询语句实际运行的查询。

{
   "from":0,
   "size":50,
   "query":{
      "bool":{
         "must":[
            {
               "match_phrase":{
                  "fundsponsor":{
                     "query":"vanguard group inc",
                     "slop":0,
                     "zero_terms_query":"NONE",
                     "boost":1.0
                  }
               }
            },
            {
               "nested":{
                  "query":{
                     "match_phrase":{
                        "holdings.componentticker":{
                           "query":"baba",
                           "slop":0,
                           "zero_terms_query":"NONE",
                           "boost":1.0
                        }
                     }
                  },
                  "path":"holdings",
                  "ignore_unmapped":false,
                  "score_mode":"none",
                  "boost":1.0,
                  "inner_hits":{
                     "name":"holdings.componenttickerbaba",
                     "ignore_unmapped":false,
                     "from":0,
                     "size":100,
                     "version":false,
                     "seq_no_primary_term":false,
                     "explain":false,
                     "track_scores":false
                  }
               }
            },
            {
               "nested":{
                  "query":{
                     "range":{
                        "holdings.weight":{
                           "from":1.0,
                           "to":2.0,
                           "include_lower":true,
                           "include_upper":true,
                           "boost":1.0
                        }
                     }
                  },
                  "path":"holdings",
                  "ignore_unmapped":false,
                  "score_mode":"none",
                  "boost":1.0,
                  "inner_hits":{
                     "name":"holdings.weightnull",
                     "ignore_unmapped":false,
                     "from":0,
                     "size":100,
                     "version":false,
                     "seq_no_primary_term":false,
                     "explain":false,
                     "track_scores":false
                  }
               }
            }
         ],
         "adjust_pure_negative":true,
         "boost":1.0
      }
   },
   "_source":{
      "includes":[
         "fundsymbol",
         "fundsponsor",
         "fundname",
         "componentcount",
         "holdings.componentticker",
         "holdings.weight"
      ],
      "excludes":[



      ]
   }
}

Please pay attention to the below section which is the culprit here.请注意下面的部分,这是这里的罪魁祸首。 Everything else works as expected.其他一切都按预期工作。 As I have mentioned above, "from" works as expected and it gets converted to GTE as expected but "to" doesn't work and neither does "LT" or "LTE" for some weird reason.正如我上面提到的,“from”按预期工作,并按预期转换为 GTE,但“to”不起作用,出于某种奇怪的原因,“LT”或“LTE”也不起作用。

               "nested":{
                  "query":{
                     "range":{
                        "holdings.weight":{
                           "from":1.0,
                           "to":2.0,
                           "include_lower":true,
                           "include_upper":true,
                           "boost":1.0
                        }
                     }
                  },

First, from and to are not range query properties.首先, fromto不是范围查询属性。 Range query expects lte , le , gte and ge .范围查询需要ltelegtege The query should look like:查询应如下所示:

{
    "query": {
        "nested": {
            "path": "holdings",
            "query": {
                "range": {
                    "holdings.weight": {
                        "gte": 1,
                        "lte": 2
                    }
                }
            }
        }
    }
}

Second, check your index mapping and make sure that holdings is mapped as a nested and that weight is mapped as float .其次,检查您的索引映射并确保holdings被映射为nested并且weight被映射为float

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM