ElasticSearch的DSL查询④(DSL查询、RestClient的DSL查询)

news2024/9/21 22:49:13

目录

一、DSL查询

1.1 快熟入门

1.2 叶子查询

1.2.1 全文检索查询

1)match查询

2)multi_match查询

1.2.2 精确查询

1)term查询

2)range查询

3)ids查询

1.3 复合查询

1.3.1 bool查询

1.3.2 算分函数查询

1)基本语法:

2)运行流程:

3)示例:

4)执行结果:

1.4 排序

1.5 分页

1.5.1 基础分页 

1.5.2 深度分页问题

1.6 高亮显示 

1.6.1 高亮原理

1.6.2 实现高亮

1.7 总结

二、RestClient查询

2.1 快速入门

2.1.1 发送请求

2.1.2 解析响应结果

2.1.3.总结

2.2 叶子查询

2.2.1 match查询和multi_match查询

2.2.2 term查询和range查询 

2.3 复合查询

2.4 排序和分页

2.5 高亮显示


        在之前的学习中,我们已经导入了大量数据到elasticsearch中,实现了商品数据的存储。不过查询商品数据时依然采用的是根据id查询,而非模糊搜索。

        所以今天,我们来研究下elasticsearch的数据搜索功能。Elasticsearch提供了基于JSON的DSL(Domain Specific Language)语句来定义查询条件,其JavaAPI就是在组织DSL条件。

        因此,我们先学习DSL的查询语法,然后再基于DSL来对照学习JavaAPI,就会事半功倍。

一、DSL查询

Elasticsearch的查询可以分为两大类:

  • 叶子查询(Leaf query clauses):一般是在特定的字段里查询特定值,属于简单查询,很少单独使用。

  • 复合查询(Compound query clauses):以逻辑方式组合多个叶子查询或者更改叶子查询的行为方式。

在查询以后,还可以对查询的结果做处理,包括:

  • 排序:按照1个或多个字段值做排序
  • 分页:根据from和size做分页,类似MySQL
  • 高亮:对搜索结果中的关键字添加特殊样式,使其更加醒目
  • 聚合:对搜索结果做数据统计以形成报表 

1.1 快熟入门

我们依然在Kibana的DevTools中学习查询的DSL语法。首先来看查询的语法结构: 

GET /{索引库名}/_search
{
  "query": {
    "查询类型": {
      // .. 查询条件
    }
  }
}

说明:GET /{索引库名}/_search:其中的_search是固定路径,不能修改

例如,我们以最简单的无条件查询为例,无条件查询的类型是:match_all,因此其查询语句如下:

GET /goods/_search
{
  "query": {
    "match_all": {
      
    }
  }
}

由于match_all无条件,所以条件位置不写即可。

执行结果如下: 

你会发现虽然是match_all,但是响应结果中并不会包含索引库中的所有文档,而是最多仅有10条。这是因为处于安全考虑,elasticsearch设置了默认的查询页数。 

1.2 叶子查询

叶子查询的类型也可以做进一步细分,这里列举一些常见的,例如:

全文检索查询(Full Text Queries):利用分词器对用户输入搜索条件先分词,得到词条,然后再利用倒排索引搜索词条。例如:

  • match
  • multi_match

精确查询(Term-level queries):不对用户输入搜索条件分词,根据字段内容精确值匹配。但只能查找keyword、数值、日期、boolean类型的字段。例如:

  • ids
  • term
  • range

地理坐标查询:用于搜索地理位置,搜索方式很多,例如:

  • geo_bounding_box:按矩形搜索
  • geo_instance:按点和半径搜索 

Query DSL | Elasticsearch Guide [7.12] | Elastic详情大家可以查看官方文档:Query DSL | Elasticsearch Guide [7.12] | Elastic

1.2.1 全文检索查询

1)match查询

全文检索查询的一种,会对用户输入内容分词,然后去倒排索引库检索。语法:

GET /{索引库名}/_search
{
  "query": {
    "match": {
      "字段名": "搜索关键子"
    }
  }
}

示例:

注意:在使用全问检索查询时,由于用户输入了搜索关键子,这里必然就会有一个问题就是,哪一些文档跟用户输入的关键子关联度更高、匹配度更高。

        那么在全文检索查询默认情况下,它会按照这个匹配度去做一个排名,匹配度越高的就会越往前。

        它内部会有一套打分的机制,它会给每个文档匹配的内容进行打分。可以看到在搜索结果里有一个 “_score” 属性,这个就是匹配度的分数,分数越高排名越靠前。

2)multi_match查询

与match查询类似,区别在于可以同时对多个字段搜索,而且多个字段都要满足,语法示例:

GET /{索引库名}/_search
{
  "query": {
    "multi_match": {
      "query": "搜索关键子",
      "fields": ["字段1", "字段2"]
    }
  }
}

示例:

全文检索的种类也很多,详情可以参考官方文档:

Full text queries | Elasticsearch Guide [7.12] | Elastic

1.2.2 精确查询

        精确查询,英文是Term-level query,顾名思义,词条级别的查询。也就是说不会对用户输入的搜索条件再分词,而是作为一个词条,与搜索的字段内容精确值匹配。因此推荐查找keyword、数值、日期、boolean类型的字段。例如: id、price、城市、地名、人名等作为一个整体才有含义的字段。

1)term查询

语法如下:

GET /{索引库名}/_search
{
  "query": {
    "term": {
      "字段名": {
        "value": "搜索关键子"
      }
    }
  }
}

示例:

当你输入的搜索条件不是词条,而是短语时,由于不做分词,你反而搜索不到: 

2)range查询

语法如下:

GET /{索引库名}/_search
{
  "query": {
    "range": {
      "字段名": {
        "gte": {最小值},
        "lte": {最大值}
      }
    }
  }
}

示例:

range是范围查询,对于范围筛选的关键字有:

  • gte:大于等于
  • gt:大于
  • lte:小于等于
  • lt:小于
3)ids查询

根据文档的id查询,语法如下:

{
  "query": {
    "ids": {
      "values": ["文档id01","文档id02"]
    }
  }
}

示例:

总结:

match和multi_match的区别是说明?

  • match:根据一个字段查询
  • multi_match:根据多个字段查询,参与查询字段越多,查询性能越差

精确查询常见的有哪些?

  • term查询:根据词条精确匹配,一般搜索keyword类型、数值类型、布尔类型、日期类型字段。
  • range查询:根据属性方范围查询,可以是数值、日期的范围。
  • ids查询:根据文档id查询

1.3 复合查询

1.3.1 bool查询

bool查询,即布尔查询。就是利用逻辑运算来组合一个或多个查询子句的组合。

bool查询支持的逻辑运算有:

  • must:必须匹配每个子查询,类似“与”

  • should:选择性匹配子查询,类似“或”

  • must_not:必须不匹配,不参与算分,类似“非”

  • filter:必须匹配,不参与算分

        出于性能考虑,与搜索关键字无关的查询尽量采用must_not或filter逻辑运算,避免参与相关性算分。

        如输入框的搜索条件肯定要参与相关性算分,可以采用match。但是价格范围过滤、品牌过滤、分类过滤等尽量采用filter,不要参与相关性算分。

示例:比如我们要搜索手机,品牌可以是华为和vivo,评论数不等于300的,价格必须是900~1000,那么可以这样写:

GET /goods/_search
{
  "query": {
    "bool": {
      "must": [
        {"match": {"name": "手机"}}
      ],
      "should": [
        {"term": {"brand": { "value": "华为" }}},
        {"term": {"brand": { "value": "vivo" }}}
      ],
      "must_not": [
        {"term": {"commentCount": { "value": 300 }}}
      ], 
      "filter": [
        {"range": {"price": {"gte":900,"lte": 1000}}}
      ]
    }
  }
}

搜索结果:

1.3.2 算分函数查询

        当我们利用match查询时,文档结果会根据与搜索词条的关联度打分_score),返回结果时按照分值降序排列。

例如,我们搜索 "手机",结果如下:

从elasticsearch5.1开始,采用的相关性打分算法是BM25算法,公式如下: 

        基于这套公式,就可以判断出某个文档与用户搜索的关键字之间的关联度,还是比较准确的。但是,在实际业务需求中,常常会有竞价排名的功能。不是相关度越高排名越靠前,而是掏的钱多的排名靠前。 

要想控制相关性算分,就需要利用elasticsearch中的 function score 查询了。 

1)基本语法:

function score 查询中包含四部分内容:

原始查询条件:query部分,基于这个条件搜索文档,并且基于BM25算法给文档打分,原始算分(query score)

过滤条件:filter部分,符合该条件的文档才会重新算分

算分函数:符合filter条件的文档要根据这个函数做运算,得到的函数算分(function score),有四种函数

  • weight:函数结果是常量

  • field_value_factor:以文档中的某个字段值作为函数结果

  • random_score:以随机数作为函数结果

  • script_score:自定义算分函数算法

运算模式:算分函数的结果、原始查询的相关性算分,两者之间的运算方式,包括:

  • multiply:相乘

  • replace:用function score替换query score

  • 其它,例如:sum、avg、max、min

2)运行流程:

function score的运行流程如下:

1)根据原始条件查询搜索文档,并且计算相关性算分,称为原始算分(query score)

2)根据过滤条件,过滤文档

3)符合过滤条件的文档,基于算分函数运算,得到函数算分(function score)

4)将原始算分(query score)和函数算分(function score)基于运算模式做运算,得到最终结果,作为相关性算分。

因此,其中的关键点是: 

  • 过滤条件:决定哪些文档的算分被修改

  • 算分函数:决定函数算分的算法

  • 运算模式:决定最终算分结果

3)示例:

给vivo这个品牌的手机算分提高十倍,分析如下:

  • 过滤条件:品牌必须为vivo

  • 算分函数:常量weight,值为10

  • 算分模式:相乘multiply

对应代码:

GET /goods/_search
{
  "query": {
    "function_score": {
      "query": {
        "match": {
          "name": "华为手机"
        }
      }, // 原始查询,可以是任意条件
      "functions": [ // 算分函数
        {
          "filter": { // 满足的条件,品牌必须是Iphone
            "term": {
              "brand": "vivo"
            }
          },
          "weight": 10 // 算分权重为2
        }
      ],
      "boost_mode": "multiply" // 加权模式,求乘积
    }
  }
}
4)执行结果:

1.4 排序

        elasticsearch默认是根据相关度算分(_score)来排序,但是也支持自定义方式对搜索结果排序。不过分词字段无法排序,能参与排序字段类型有:keyword类型、数值类型、地理坐标类型、日期类型等。

语法说明:

跟query参数同级的sort参数就是用来排序的

GET /indexName/_search
{
  "query": {
    "match_all": {}
  },
  "sort": [
    {
      "排序字段": "排序方式asc和desc"
    }
  ]
}

示例,我们先按照商品价格升序排序,然后再按照销量排序 

GET /goods/_search
{
  "query": {
    "match_all": {}
  },
  "sort": [
    {
      "price": "asc" // 根据价格升序
    },
    {
      "sold": "desc" // 根据销量降序
    }
  ]
}

结果:小米手机和华为手机的价格一样,当时小米手机的销量比华为的高,所以比较靠前

1.5 分页

elasticsearch 默认情况下只返回top10的数据。而如果要查询更多数据就需要修改分页参数了。

1.5.1 基础分页 

elasticsearch中通过修改fromsize参数来控制要返回的分页结果:

  • from:从第几个文档开始

  • size:总共查询几个文档

类似于mysql中的limit ?, ?

语法如下: 

GET /items/_search
{
  "query": {
    "match_all": {}
  },
  "from": 0, // 分页开始的位置,默认为0
  "size": 10,  // 每页文档数量,默认10
  "sort": [
    {
      "price": "desc"
    }
  ]
}

示例:每页10条数据,查询第1页的数据。(第1页则表示起始位置为0,数据为0~9。第2页则起始位置是10,数据为10~19)

1.5.2 深度分页问题

elasticsearch的数据一般会采用分片存储,也就是把一个索引中的数据分成N份,存储到不同节点上。这种存储方式比较有利于数据扩展,但给分页带来了一些麻烦。 

比如一个索引库中有100000条数据,分别存储到4个分片,每个分片25000条数据。现在查询第100页,每页查询10条。那么分页查询的条件如下: 

GET /goods/_search
{
  "from": 990, // 从第990条开始查询
  "size": 10, // 每页查询10条
  "sort": [
    {
      "price": "asc"
    }
  ]
}

那么问题来了,ES是怎么从这些分片中找到前1000名的最后10名的?想要找前1000名的最后10名是不是得先知道前1000名是谁。所以肯定是先排个序,先找到前1000名,然后才能找到最后排名的那10名。

实现思路:

  1. 对数据排序
  2. 找出第990~1000名

从实现思路来分析,肯定是将所有数据排序,找出前1000名,截取其中的990~1000的部分。但问题来了,我们如何才能找到所有数据中的前1000名呢?

        这里举一个通俗的例子,比如说现在有个学校,年级里有10个班级,想找出年级前10名。要找年级前10名,难道说这10个班级,每个班的第1名拿过来就是年级前10名了吗,显然不是吧。因为每个班级都有学的好学的差的,班级的程度不一样,有可能这个班级的第一名跑到另一个班级连前10名都进不去,所以有可能就不是年级前10。

        那想找年级前10名怎么办,是不是应该把所有学生合一起做排序找前10。其实也不用,有一种做法是这样的,我们只需要把每个班级的前10名找出来放在一起去比较就行了,就算是极端的情况有一个班级学习特别好,年级的前10名就是这个班的前10。所以只需要把每个班级的前10名也能找出来年级前10名。

        与此类型,我们要找前1000,只需要在每个分片里都找出各自的前1000名,最终整体的前1000一定在这4000个里面。然后对这4000个进行重新排序,筛选前1000个截取我们想要的那部分就可以了。

        那大家思考下,这时候就会有有一个问题,我们查100页还好说,那如果查的是第1000页呢,按照刚刚分析的,是不是得先找出前10000名,那么就得先从每个分片都找出前10000名最后聚合。如果查的是第10000页,就得从每个分片查出前10万条。那么这个数据量就很恐怖了,如果查询的分页深度更深,很有可能内存就直接炸裂了。

        这就是深度分页问题,查询的页码越深,每个分片要查的数据量就会越多,最终内存压力也会越大,性能也会越差。

因此elasticsearch会禁止from和size相加超过10000的请求。

解决方案

针对深度分页,elasticsearch提供了两种解决方案:

1)search after分页时需要排序,原理是从上一次的排序值开始,查询下一页数据。官方推荐使用的方式。

        由于是做了排序的,所以每一条数据都有一个排序值,那么查完第一页的时候,记住第一页最后一条数据的排序值,那么在第二页查的时候就可以直接从这个排序值开始获取后面10条的数据,并且记录第二页最后一条数据的排序值。

  • 优点:没有查询上限,支持深度分页。
  • 缺点:只能向后在逐页查询,不能随机翻页。
  • 场景:数据迁移、手机滚动查询。

2)scroll原理将排序后的文档id形成快照,保存下来,基于快照做分页。官方已经不推荐使用。

详情见文档:Paginate search results | Elasticsearch Guide [7.12] | Elastic

总结:

大多数情况下,我们采用普通分页就可以了。查看百度、京东等网站,会发现其分页都有限制。例如百度最多支持77页,每页不足20条。京东最多100页,每页最多60条。

因此,一般我们采用限制分页深度的方式即可,无需实现深度分页

1.6 高亮显示 

1.6.1 高亮原理

什么是高亮显示呢?

我们在百度,京东搜索时,关键字会变成红色,比较醒目,这个便是高亮显示:

观察页面源码,你会发现两件事情:

  • 高亮词条都被加了<em>标签

  • <em>标签都添加了红色样式 

css样式肯定是前端实现页面的时候写好的,但是前端编写页面的时候是不知道页面要展示什么数据的,不可能给数据加标签。而服务端实现搜索功能,要是有elasticsearch做分词搜索,是知道哪些词条需要高亮的。 因此词条的高亮标签肯定是由服务端提供数据的时候已经加上的

因此实现高亮的思路就是:

  • 用户输入搜索关键字搜索数据

  • 服务端根据搜索关键字到elasticsearch搜索,并给搜索结果中的关键字词条添加html标签

  • 前端提前给约定好的html标签添加CSS样式

1.6.2 实现高亮

事实上elasticsearch已经提供了给搜索关键字加标签的语法,无需我们自己编码。 

基本语法如下: 

GET /{索引库名}/_search
{
  "query": {
    "match": {
      "搜索字段": "搜索关键字"
    }
  },
  "highlight": {
    "fields": {
      "高亮字段名称": { // 指定要高亮的字段
        "pre_tags": "<em>",  // 高亮的前置标签
        "post_tags": "</em>" // 高亮的后置标签
      }
    }
  }
}

示例:

_source的文档信息是不会有任何变化的,可以看到多了一个highlight的属性,里面的name值加上了高亮的标签了 

注意

  • 搜索必须有查询条件,而且是全文检索类型的查询条件,例如match

  • 参与高亮的字段必须是text类型的字段

  • 默认情况下参与高亮的字段要与搜索字段一致,除非添加:required_field_match=false

1.7 总结

查询的DSL是一个大的JSON对象,包含下列常用属性:

  • query:查询条件

  • fromsize:分页条件

  • sort:排序条件

  • highlight:高亮条件

GET /goods/_search
{
  "query": {
    "match": {
      "name": "华为"
    }
  },
  "from": 0, // 分页开始的位置
  "size": 20, // 分页的文档数量
  "sort": [ // 排序
    {
      "price": "desc"
    }
  ], 
  "highlight": {
    "fields": {
      "name": { // 高亮字段
        "pre_tags": "<em>", // 高亮字段的前置标签 
        "post_tags": "</em>" // 高亮字段的后置标签
      }
    }
  }
}

二、RestClient查询

        之前说过,由于Elasticsearch对外暴露的接口都是Restful风格的接口,因此JavaAPI调用就是在发送Http请求。而我们核心要做的就是利用利用Java代码组织请求参数解析响应结果

        这个参数的格式完全参考DSL查询语句的JSON结构,因此我们在学习的过程中,会不断的把JavaAPI与DSL语句对比。大家在学习记忆的过程中,也应该这样对比学习。

文档的查询依然使用之前学习的RestHighLevelClient对象,查询的基本步骤如下

  1. 创建request对象,这次是搜索,所以是SearchRequest
  2. 准备请求参数,也就是查询DSL对应的JSON参数
  3. 发起请求
  4. 解析响应,响应结果相对复杂,需要逐层解析

2.1 快速入门

2.1.1 发送请求

首先以match_all查询为例,其DSL和JavaAPI的对比如图:

代码解读:

  • 第一步,创建SearchRequest对象,指定索引库名

  • 第二步,利用request.source()构建DSL,DSL中可以包含查询、分页、排序、高亮等

    • query():代表查询条件,利用QueryBuilders.matchAllQuery()构建一个match_all查询的DSL

  • 第三步,利用client.search()发送请求,得到响应

 这里关键的API有两个,一个是request.source(),它构建的就是DSL中的完整JSON参数。其中包含了querysortfromsizehighlight等所有功能:

另一个是QueryBuilders,其中包含了我们学习过的各种叶子查询复合查询等: 

2.1.2 解析响应结果

在发送请求以后,得到了响应结果SearchResponse,这个类的结构与我们在kibana中看到的响应结果JSON结构完全一致:

格式化之后: 

 因此,我们解析SearchResponse的代码就是在解析这个JSON结果,对比如下:

2.1.3.总结

文档搜索的基本步骤是:

  1. 创建SearchRequest对象

  2. 准备request.source(),也就是DSL。

    1. QueryBuilders来构建查询条件

    2. QueryBuilders构建的查询条件传入request.source() query() 方法

  3. 发送请求,得到结果

  4. 解析结果(参考JSON结果,从外到内,逐层解析)

完整代码如下:

    @Test
    public void matchAllTest() throws IOException {
        // 1.准备Request对象,参数为要查询的索引库名称
        SearchRequest request = new SearchRequest("goods");
        // 2.组织DSL参数
        request.source().query(QueryBuilders.matchAllQuery());
        // 3.发送请求,得到响应结果
        SearchResponse response = restHighLevelClient.search(request, RequestOptions.DEFAULT);
        // 4.解析响应结果
        parseResponseResult(response);
    }

    private static void parseResponseResult(SearchResponse response) {
        SearchHits searchHits = response.getHits();
        // 1.获取总条数
        long total = searchHits.getTotalHits().value;
        System.out.println("共搜索到" + total + "条数据");
        // 2.遍历结果数组
        SearchHit[] hits = searchHits.getHits();
        for (SearchHit hit : hits) {
            // 3.得到_source,也就是原始json文档
            String source = hit.getSourceAsString();
            // 4.反序列化并打印
            GoodsDoc goodsDoc = JSONUtil.toBean(source, GoodsDoc.class);
            System.out.println(goodsDoc);
        }
    }

2.2 叶子查询

        所有的查询条件都是由QueryBuilders来构建的,叶子查询也不例外。因此整套代码中变化的部分仅仅是query条件构造的方式,其它不动。 

2.2.1 match查询和multi_match查询

matchQuery:第一个参数是要搜索的字段,第二参数是搜索的关键子。

multiMatchQuery:第一个参数是搜索的关键子,后面是可变参数,表示多个要搜索的字段。

match查询示例:

    @Test
    void testMatch() throws IOException {
        // 1.创建Request
        SearchRequest request = new SearchRequest("goods");
        // 2.组织请求参数
        request.source().query(QueryBuilders.matchQuery("name", "牛奶"));
        // 3.发送请求
        SearchResponse response = restHighLevelClient.search(request, RequestOptions.DEFAULT);
        // 4.解析响应
        parseResponseResult(response);
    }

multi_match查询示例:

    @Test
    void testMultiMatch() throws IOException {
        // 1.创建Request
        SearchRequest request = new SearchRequest("goods");
        // 2.组织请求参数
        request.source().query(QueryBuilders.multiMatchQuery("手机", "name", "category"));
        // 3.发送请求
        SearchResponse response = restHighLevelClient.search(request, RequestOptions.DEFAULT);
        // 4.解析响应
        parseResponseResult(response);
    }

2.2.2 term查询和range查询 

termQuery:第一个参数是要搜索的字段,第二参数是搜索的关键子。 

rangeQuery:第一个参数是要搜索的字段,后面用链式调用传入最小值和最大值。 

term查询:

    @Test
    void testTerm() throws IOException {
        // 1.创建Request
        SearchRequest request = new SearchRequest("goods");
        // 2.组织请求参数
        request.source().query(QueryBuilders.termQuery("brand", "华为"));
        // 3.发送请求
        SearchResponse response = restHighLevelClient.search(request, RequestOptions.DEFAULT);
        // 4.解析响应
        parseResponseResult(response);
    }

range查询:

    @Test
    void testRange() throws IOException {
        // 1.创建Request
        SearchRequest request = new SearchRequest("goods");
        // 2.组织请求参数
        request.source().query(QueryBuilders.rangeQuery("price").gte(1000).lte(2000));
        // 3.发送请求
        SearchResponse response = restHighLevelClient.search(request, RequestOptions.DEFAULT);
        // 4.解析响应
        parseResponseResult(response);
    }

2.3 复合查询

复合查询也是由QueryBuilders来构建,我们以bool查询为例,DSL和JavaAPI的对比如图: 

案例:利用JavaRestClient实现搜索功能,条件如下:

  • 搜索关键字为 “手机” 
  • 品牌必须为华为
  • 价格必须小于1000

代码如下:

    @Test
    public void testSearch() throws IOException {
        // 1.创建Request对象
        SearchRequest request = new SearchRequest("goods");
        // 2.构建请求参数
        BoolQueryBuilder boolQueryBuilder = QueryBuilders.boolQuery();
        // 2.1 搜索关键字为 “手机”
        boolQueryBuilder.must(
                QueryBuilders.matchQuery("name", "手机")
        );
        // 2.2 品牌必须为华为
        boolQueryBuilder.filter(
                QueryBuilders.termQuery("brand", "华为")
        );
        // 2.3 价格必须小于1000
        boolQueryBuilder.filter(
                QueryBuilders.rangeQuery("price").lt(1000)
        );
        request.source().query(boolQueryBuilder);
        
        // 3.发送请求
        SearchResponse response = restHighLevelClient.search(request, RequestOptions.DEFAULT);
        // 4.解析响应
        parseResponseResult(response);
    }

查询结果:可以看到都是符合条件的

2.4 排序和分页

之前说过,requeset.source()就是整个请求JSON参数,所以排序、分页都是基于这个来设置,其DSL和JavaAPI的对比如下: 

完整示例代码: 

    @Test
    void testPageAndSort() throws IOException {
        // 模拟前端传递的分页参数
        int pageNo = 1, pageSize = 5;
        // 1.创建Request
        SearchRequest request = new SearchRequest("goods");
        // 2.组织请求参数
        // 2.1.搜索条件参数
        request.source().query(QueryBuilders.matchAllQuery());
        // 2.2.排序参数
        request.source().sort("price", SortOrder.ASC);
        // 2.3.分页参数
        request.source().from((pageNo - 1) * pageSize).size(pageSize);
        // 3.发送请求
        SearchResponse response = restHighLevelClient.search(request, RequestOptions.DEFAULT);
        // 4.解析响应
        parseResponseResult(response);
    }

2.5 高亮显示

高亮查询与前面的查询有两点不同:

  • 条件同样是在request.source()中指定,只不过高亮条件要基于HighlightBuilder来构造

  • 高亮响应结果与搜索的文档结果不在一起,需要单独解析

首先来看高亮条件构造,其DSL和JavaAPI的对比如图:

示例代码如下:

    @Test
    void testHighlight() throws IOException {
        // 1.创建Request
        SearchRequest request = new SearchRequest("goods");
        // 2.组织请求参数
        // 2.1.query条件
        request.source().query(QueryBuilders.matchQuery("name", "华为"));
        // 2.2.高亮条件
        /* request.source().highlighter(
                SearchSourceBuilder.highlight()
                        .field("name")
                        .preTags("<em>")
                        .postTags("</em>")
        );*/
        // ES默认请款下高亮的标签就是 <em></em>,所以可以省略不写
        request.source().highlighter(
                SearchSourceBuilder.highlight().field("name")
        );
        // 3.发送请求
        SearchResponse response = restHighLevelClient.search(request, RequestOptions.DEFAULT);
        // 4.解析响应
        parseResponseResult(response);
    }


    private static void parseResponseResult(SearchResponse response) {
        // 4.解析响应结果
        SearchHits searchHits = response.getHits();
        // 1.获取总条数
        long total = searchHits.getTotalHits().value;
        System.out.println("共搜索到" + total + "条数据");
        // 2.遍历结果数组
        SearchHit[] hits = searchHits.getHits();
        for (SearchHit hit : hits) {
            // 3.得到_source,也就是原始json文档
            String source = hit.getSourceAsString();
            // 4.反序列化并打印
            GoodsDoc goodsDoc = JSONUtil.toBean(source, GoodsDoc.class);
            // 5.获取高亮结果
            Map<String, HighlightField> hfs = hit.getHighlightFields();
            // 5.1 判断是否有高亮结果
            if (CollUtil.isNotEmpty(hfs)) {
                // 5.2 有高亮结果,获取name的高亮结果
                HighlightField hf = hfs.get("name");
                if (hf != null) {
                    StringBuilder hfName = new StringBuilder();
                    // 5.3 获取、遍历高亮结果数组,就是商品名称的高亮值
                    Text[] fragments = hf.getFragments();
                    for (Text fragment : fragments) {
                        hfName.append(fragment.string());
                    }
                    // 5.4 重新赋值
                    goodsDoc.setName(hfName.toString());
                }
            }
            System.out.println(goodsDoc);
        }
    }

 执行结果:

这里需要注意:高亮内容需要单独解析出来,其DSL和JavaAPI的对比如图:

为什么name高亮的值是一个数组呢?

        因为ES高亮的时候需要对原始的字段内容进行切割,找到对应高亮的内容加标签。那么在处理的过程中会有一个阈值,当你的字段值过长,就会把这个原本的字符串切成几个片段, 然后放到一个数组当中,形成高亮字符串的一个数组。这种情况下就需要取出所有片段拼装在一起才能得到完整的内容。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/2122805.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

9月10号的学习

//界面1 头文件 signals://界面1的自定义信号void my_signal(); private slots:void on_pushButton_2_clicked();void on_pushButton_clicked(); //界面1 .cpp文件 void Widget::on_pushButton_2_clicked() {QMessageBox msg(QMessageBox::Warning,"警告","是否…

Linux学习-ELK(一)

配置三台elasticsearch服务器 安装包 elasticsearch.j2 报错 #---执行rsync命令报以下错误 [rootes1 ~]# rsync -av /etc/hosts 192.168.29.172:/etc/hosts root192.168.29.172s password: bash: rsync: 未找到命令 rsync: connection unexpectedly closed (0 bytes receive…

【Unity面经】性能优化篇

&#x1f468;‍&#x1f4bb;个人主页&#xff1a;元宇宙-秩沅 &#x1f468;‍&#x1f4bb; hallo 欢迎 点赞&#x1f44d; 收藏⭐ 留言&#x1f4dd; 加关注✅! &#x1f468;‍&#x1f4bb; 本文由 秩沅 原创 &#x1f468;‍&#x1f4bb; 专栏交流&#x1f9e7;&…

MySQL 查询优化秘籍:让你的数据库查询飞起来

《MySQL 查询优化秘籍&#xff1a;让你的数据库查询飞起来》 在数据库应用中&#xff0c;高效的查询性能至关重要。MySQL 作为广泛使用的关系型数据库&#xff0c;掌握一些常用的查询优化方法可以极大地提升系统的响应速度和性能。今天&#xff0c;我们就来一起探讨常用的优化…

WORD批量转换器MultiDoc Converter

WORD批量转换器MultiDoc Converter https://www.52pojie.cn/thread-1318745-1-1.html 可批量将doc、docx等文件格式转成doc、docx、pdf、rtf、txt、html、epub等格式。 安装包下载地址&#xff1a;https://wws.lanzouj.com/irvVbiz0pkd 最终下载文件打包地址&#xff08;未作成…

QT Creater实现国庆节主题项目【0基础完成版】

本文适用对象 想要学习qt creater的小白;想要学习c++制作软件的编程爱好者。可以先下载这篇博客绑定的资源,然后一边操作,一边学习,会更高效~0. 创建初始项目 一步步来操作吧,首先下载qt creter,之前发布过相关资源,大家直接查找下载,或者自行下载。 1. 初始代码 mai…

C++竞赛初阶L1-15-第六单元-多维数组(34~35课)555: T456505 矩阵乘法

题目内容 计算两个矩阵的乘法。nm 阶的矩阵 A 乘以 mk 阶的矩阵 B 得到的矩阵 C 是 nk 阶的,且 C[i][j]=A[i][0]B[0][j]+A[i][1]B[1][j]+ …… +A[i][m−1]B[m−1][j](C[i][j] 表示 C 矩阵中第 i 行第 j 列元素)。 输入格式 第一行为 n,m,k,表示 A 矩阵是 n 行 m 列,B 矩…

如何使用 ONNX 结合 GPU 加速推理(CUDA 与 cuDNN 简明指南)

前言 在深度学习模型推理中,使用 GPU 进行加速是提升模型推理速度的关键方式之一。 本文将带大家一步步了解如何使用 ONNX Runtime 结合 NVIDIA 的 CUDA 和 cuDNN 进行 GPU 加速。 一、查找ONNX、CUDA与cuDNN之间的对应版本 首先,我们需要确保 ONNX Runtime 与 CUDA 和 cu…

数据流图例题

答案&#xff1a;A A 解析&#xff1a;DFD是数据流图 ERD是实体流程图&#xff0c;也就是ER图 数据流图的元素 数据流&#xff1a;、由一组固定成分的数据组成&#xff0c;表示数据的流向。每个数据流通常有一个合适的名词&#xff0c;反映数据流的含义 加工&#xff1a;加…

(计算机网络)运输层

一.运输层的作用 运输层&#xff1a;负责将数据统一的交给网络层 实质&#xff1a;进程在通信 TCP&#xff08;有反馈&#xff09;UDP&#xff08;无反馈&#xff09; 二.复用和分用 三. TCP和UDP的特点和区别 进程号--不是固定的 端口号固定--mysql--3306 端口--通信的终点 …

认识保护模式

认识保护模式 为什么需要保护模式 Intel 8086是16位CPU,它有着16位的寄存器,16位的数据总线以及20位的地址总线和1MB的寻址能力。从80386开始CPU进入32位时代,寻址能力达到4GB,无法使用16位寄存器完成寻址 GDT(global descriptor table) 而保护模式下&#xff0c;虽然段值仍…

《王者荣耀世界》不止在苹果16优化 多终端优化也在进行

易采游戏网9月10日消息&#xff1a;随着iPhone16的发布&#xff0c;全球手游玩家的目光再次聚焦于这款全新设备的性能表现。而作为国内游戏界的代表作之一&#xff0c;《王者荣耀世界》也将迎来一波重大的体验升级。这一次的优化并不只局限于iPhone16&#xff0c;实际上&#x…

客服宝:专业跨平台快捷回复软件

在这个信息爆炸的时代&#xff0c;客服工作的重要性不言而喻。然而&#xff0c;面对多渠道、高频率的咨询与互动&#xff0c;客服团队如何保持高效、专业且富有人情味的对话呢&#xff1f;客服宝——一款专业的跨平台快捷回复软件&#xff0c;以其独特的功能优势&#xff0c;为…

第三部分:4---进程地址空间

目录 数组的空间分配解析&#xff1a; 物理地址和虚拟地址&#xff1a; 虚拟地址空间&#xff1a; 进程地址空间的本质&#xff1a; 为什么要有进程地址空间&#xff1f; 页表对进程访问内存的检查&#xff1a; 进程地址空间和页表如何关联起来&#xff1f; 进程的独立…

源荷储再创新!小论文轻松发!基于雨流计数法的源-荷-储双层协同优化配置研究程序代码!

前言 如何实现源与荷信息互通&#xff0c;将传统的供需信息由静态传递向能源互联转变&#xff0c;形成能源互联网&#xff0c;是今后能源革命的变革方向。新电改的出台推动了能源互联网的发展&#xff0c;储能技术作为能源互联网发展中的关键元素&#xff0c;由于储能系统投资…

每个python程序员都应该早点知道的 6 个 Python 函数

在编程中&#xff0c;默认参数的引入使得函数调用更为灵活&#xff0c;不仅允许开发者在特定情况下省略某些非必需参数&#xff0c;同时也强调了对参数与实际传递值&#xff08;即论点&#xff09;之间区别的理解&#xff0c;这对于掌握函数工作机制至关重要。 此外&#xff0…

PCL-统计滤波

本篇内容 讲解统计滤波作用及原理通过pcl实现统计滤波强烈推荐在点云处理最开始使用&#xff0c;统计滤波处理&#xff0c;再送入其他算法进行处理&#xff01;&#xff01;&#xff01; 效果&#xff1a; 1 主要原理 手动设置半径大小或者邻域点数量N&#xff08;若设置的…

“论剑”智算时代,长沙已经站在计算产业的“华山之巅”

文 | 智能相对论 作者 | 陈泊丞 共赴全新十年之约&#xff0c;长沙又来搞大事情了&#xff01; 2024互联网岳麓峰会以“AI汇湘江 数智领航未来”为主题&#xff0c;全面聚焦在“AI”时代把握数字化、网络化、智能化发展机遇&#xff0c;积极响应当前人工智能技术迅猛发展的势…

【Qt笔记】QTableWidget控件详解

目录 引言 一、QTableWidget的特点 二、QTableWidget基础 2.1 引入QTableWidget 2.2 基本属性 三、代码示例&#xff1a;初始化QTableWidget 四、编辑功能 4.1 设置单元格为只读 4.2 响应内容更改 五、选择模式 六、样式定制 七、与其他控件的交互 7.1 在单元格…

网络工程师学习笔记——无线通信网(二)

MAC子层 包含逻辑链路层&#xff08;LLC&#xff09;和介质访问控制层&#xff08;MAC&#xff09;两个子层 无线访问机制 MAC子层是提供访问机制控制 <1>CSMA/CA是类似于802.3当中的CSMA/CD且支持竞争访问 为何不适用CSMA/CD ,因为有隐藏的节点和暴露的节点&#xf…