elasticsearch篇:RestClient查询

   日期:2024-12-26    作者:paint01 移动:http://mip.riyuangf.com/mobile/quote/42198.html

文档的查询同样适用 RestHighLevelClient对象,基本步骤包括

elasticsearch篇:RestClient查询

  • 1)准备Request对象

  • 2)准备请求参数

  • 3)发起请求

  • 4)解析响应

我们以match_all查询为例

1.1.1. 发起查询请求

代码解读

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

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

    • :代表查询条件,利用构建一个match_all查询的DSL

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

这里关键的API有两个,一个是,其中包含了查询、排序、分页、高亮等所有功能

另一个是,其中包含match、term、function_score、bool等各种查询

1.1.2.解析响应

响应结果的解析

elasticsearch返回的结果是一个JSON字符串,结构包含

  • :命中的结果

    • :总条数,其中的value是具体的总条数值

    • :所有结果中得分最高的文档的相关性算分

    • :搜索结果的文档数组,其中的每个文档都是一个json对象

      • :文档中的原始数据,也是json对象

因此,我们解析响应结果,就是逐层解析JSON字符串,流程如下

  • :通过response.getHits()获取,就是JSON中的最外层的hits,代表命中的结果

    • :获取总条数信息

    • :获取SearchHit数组,也就是文档数组

      • :获取文档结果中的_source,也就是原始的json文档数据

1.1.3.完整代码

完整代码如下

 

1.1.4.小结

查询的基本步骤是

  1. 创建SearchRequest对象

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

    ① QueryBuilders来构建查询条件

    ② 传入Request.source() 的 query() 方法

  3. 发送请求,得到结果

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

全文检索的match和multi_match查询与match_all的API基本一致。差别是查询条件,也就是query的部分。

因此,Java代码上的差异主要是request.source().query()中的参数了。同样是利用QueryBuilders提供的方法

而结果解析代码则完全一致,可以抽取并共享。

完整代码如下

 
 

精确查询主要是两者

  • term:词条精确匹配

  • range:范围查询

与之前的查询相比,差异同样在查询条件,其它都一样。

查询条件构造的API如下

布尔查询是用must、must_not、filter等方式组合其它查询,代码示例如下

可以看到,API与其它查询的差别同样是在查询条件的构建,QueryBuilders,结果解析等其他代码完全不变。

完整代码如下

 

结果如下

搜索结果的排序和分页是与query同级的参数,因此同样是使用request.source()来设置。

对应的API如下

完整代码示例

 
 

高亮的代码与之前代码差异较大,有两点

  • 查询的DSL:其中除了查询条件,还需要添加高亮条件,同样是与query同级。

  • 结果解析:结果除了要解析_source文档数据,还要解析高亮结果

1.6.1. 高亮请求构建

高亮请求的构建API如下

上述代码省略了查询条件部分,但是大家不要忘了:高亮查询必须使用全文检索查询,并且要有搜索关键字,将来才可以对关键字高亮。

完整代码如下

 

1.6.2.高亮结果解析

高亮的结果与查询的文档结果默认是分离的,并不在一起。

因此解析高亮的代码需要额外处理

代码解读

  • 第一步:从结果中获取source。hit.getSourceAsString(),这部分是非高亮结果,json字符串。还需要反序列为HotelDoc对象

  • 第二步:获取高亮结果。hit.getHighlightFields(),返回值是一个Map,key是高亮字段名称,值是HighlightField对象,代表高亮值

  • 第三步:从map中根据高亮字段名称,获取高亮字段值对象HighlightField

  • 第四步:从HighlightField中获取Fragments,并且转为字符串。这部分就是真正的高亮字符串了

  • 第五步:用高亮的结果替换HotelDoc中的非高亮结果

完整代码如下

 
 

下面,我们通过黑马旅游的案例来实战演练一下之前学习的知识

我们实现四部分功能

  • 酒店搜索和分页

  • 酒店结果过滤

  • 我周边的酒店

  • 酒店竞价排名

启动我们提供的hotel-demo项目,其默认端口是8089,访问http://localhost:8090,就能看到项目页面了

案例需求:实现黑马旅游的酒店搜索功能,完成关键字搜索和分页

2.1.1. 需求分析

在项目的首页,有一个大大的搜索框,还有分页按钮

点击搜索按钮,可以看到浏览器控制台发出了请求

由此可以知道,我们这个请求的信息如下

  • 请求方式:POST

  • 请求路径:/hotel/list

  • 请求参数:JSON对象,包含4个字段

    • key:搜索关键字

    • page:页码

    • size:每页大小

    • sortBy:排序,目前暂不实现

  • 返回值:分页查询,需要返回分页结果PageResult,包含两个属性

    • :总条数

    • :当前页的数据

因此,我们实现业务的流程如下

  • 步骤一:定义实体类,接收请求参数的JSON对象

  • 步骤二:编写controller,接收页面的请求

  • 步骤三:编写业务实现,利用RestHighLevelClient实现搜索、分页

2.1.2. 定义实体类

实体类有两个,一个是前端的请求参数实体,一个是服务端应该返回的响应结果实体。

1)请求参数

前端请求的json结构如下

 

因此,我们在包下定义一个实体类

 

2)返回值

分页查询,需要返回分页结果PageResult,包含两个属性

  • :总条数

  • :当前页的数据

因此,我们在中定义返回结果

 

2.1.3.定义controller

定义一个HotelController,声明查询接口,满足下列要求

  • 请求方式:Post

  • 请求路径:/hotel/list

  • 请求参数:对象,类型为RequestParam

  • 返回值:PageResult,包含两个属性

    • :总条数

    • :酒店数据

因此,我们在中定义HotelController

 

2.1.4. 实现搜索业务

我们在controller调用了IHotelService,并没有实现该方法,因此下面我们就在IHotelService中定义方法,并且去实现业务逻辑。

1)在中的接口中定义一个方法

 

2)实现搜索业务,肯定离不开RestHighLevelClient,我们需要把它注册到Spring中作为一个Bean。在中的中声明这个Bean

 

3)在中的中实现search方法

 
 

需求:添加品牌、城市、星级、价格等过滤功能

2.2.1. 需求分析

在页面搜索框下面,会有一些过滤项

传递的参数如图

包含的过滤条件有

  • brand:品牌值

  • city:城市

  • minPrice~maxPrice:价格范围

  • starName:星级

我们需要做两件事情

  • 修改请求参数的对象RequestParams,接收上述参数

  • 修改业务逻辑,在搜索条件之外,添加一些过滤条件

2.2.2. 修改实体类

修改在包下的实体类RequestParams

 

2.2.3. 修改搜索业务

在HotelService的search方法中,只有一个地方需要修改:requet.source().query( ... )其中的查询条件。

在之前的业务中,只有match查询,根据关键字搜索,现在要添加条件过滤,包括

  • 品牌过滤:是keyword类型,用term查询

  • 星级过滤:是keyword类型,用term查询

  • 价格过滤:是数值类型,用range查询

  • 城市过滤:是keyword类型,用term查询

多个查询条件组合,肯定是boolean查询来组合

  • 关键字搜索放到must中,参与算分

  • 其它过滤条件放到filter中,不参与算分

因为条件构建的逻辑比较复杂,这里先封装为一个函数

buildBasicQuery的代码如下

 
 

需求:显示我附近的酒店

2.3.1.需求分析

在酒店列表页的右侧,有一个小地图,点击地图的定位按钮,地图会找到你所在的位置

并且,在前端会发起查询请求,将你的坐标发送到服务端

我们要做的事情就是基于这个location坐标,然后按照距离对周围酒店排序。实现思路如下

  • 修改RequestParams参数,接收location字段

  • 修改search方法业务逻辑,如果location有值,添加根据geo_distance排序的功能

2.3.2. 修改实体类

修改在包下的实体类RequestParams

 

2.3.3. 距离排序的API

我们以前学习过排序功能,包括两种

  • 普通字段排序

  • 地理坐标排序

我们只讲了普通字段排序对应的java写法。地理坐标排序只学过DSL语法,如下

 

对应的java代码示例

2.3.4. 添加距离排序

在的的方法中,添加一个排序功能

完整代码

 

2.3.5. 排序距离显示

重启服务后,测试我的酒店功能

发现确实可以实现对我附近酒店的排序,不过并没有看到酒店到底距离我多远,这该怎么办

排序完成后,页面还要获取我附近每个酒店的具体距离,这个值在响应结果中是独立的

因此,我们在结果解析阶段,除了解析source部分以外,还要得到sort部分,也就是排序的距离,然后放到响应结果中。

我们要做两件事

  • 修改HotelDoc,添加排序距离字段,用于页面显示

  • 修改HotelService类中的handleResponse方法,添加对sort值的获取

1)修改HotelDoc类,添加距离字段

 

2)修改HotelService中的handleResponse方法

重启后测试,发现页面能成功显示距离了

需求:让指定的酒店在搜索结果中置顶

2.4.1.需求分析

要让指定酒店在搜索结果中排名置顶,效果如图

页面会给指定的酒店添加广告标记。

那怎样才能让指定的酒店排名置顶呢

我们之前学习过的function_score查询可以影响算分,算分高了,自然排名也就高了。而function_score包含3个要素

  • 过滤条件:哪些文档要加分

  • 算分函数:如何计算function score

  • 加权方式:function score 与 query score如何运算

这里的需求是:让指定酒店排名靠前。因此我们需要给这些酒店添加一个标记,这样在过滤条件中就可以根据这个标记来判断,是否要提高算分

比如,我们给酒店添加一个字段:isAD,Boolean类型

  • true:是广告

  • false:不是广告

这样function_score包含3个要素就很好确定了

  • 过滤条件:判断isAD 是否为true

  • 算分函数:我们可以用最简单暴力的weight,固定加权值

  • 加权方式:可以用默认的相乘,大大提高算分

因此,业务的实现步骤包括

  1. 给HotelDoc类添加isAD字段,Boolean类型

  2. 挑选几个你喜欢的酒店,给它的文档数据添加isAD字段,值为true

  3. 修改search方法,添加function score功能,给isAD值为true的酒店增加权重

2.4.2. 修改HotelDoc实体

给包下的HotelDoc类添加isAD字段

2.4.3. 添加广告标记

接下来,我们挑几个酒店,添加isAD字段,设置为true

 

2.4.4. 添加算分函数查询

接下来我们就要修改查询条件了。之前是用的boolean 查询,现在要改成function_socre查询。

function_score查询结构如下

对应的JavaAPI如下

我们可以将之前写的boolean查询作为原始查询条件放到query中,接下来就是添加过滤条件算分函数加权模式了。所以原来的代码依然可以沿用。

修改包下的类中的方法,添加算分函数查询


 

特别提示:本信息由相关用户自行提供,真实性未证实,仅供参考。请谨慎采用,风险自负。


举报收藏 0评论 0
0相关评论
相关最新动态
推荐最新动态
点击排行
{
网站首页  |  关于我们  |  联系方式  |  使用协议  |  隐私政策  |  版权隐私  |  网站地图  |  排名推广  |  广告服务  |  积分换礼  |  网站留言  |  RSS订阅  |  违规举报  |  鄂ICP备2020018471号