目录
一、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,就会事半功倍。
Elasticsearch的查询可以分为两大类:
叶子查询(Leaf query clauses):一般是在特定的字段里查询特定值,属于简单查询,很少单独使用。
复合查询(Compound query clauses):以逻辑方式组合多个叶子查询或者更改叶子查询的行为方式。
在查询以后,还可以对查询的结果做处理,包括:
我们依然在Kibana的DevTools中学习查询的DSL语法。首先来看查询的语法结构:
GET /{索引库名}/_search
{
"query": {
"查询类型": {
// .. 查询条件
}
}
}
说明:GET /{索引库名}/_search
:其中的_search
是固定路径,不能修改
例如,我们以最简单的无条件查询为例,无条件查询的类型是:match_all,因此其查询语句如下:
GET /goods/_search
{
"query": {
"match_all": {
}
}
}
由于match_all无条件,所以条件位置不写即可。
执行结果如下:
你会发现虽然是match_all,但是响应结果中并不会包含索引库中的所有文档,而是最多仅有10条。这是因为处于安全考虑,elasticsearch设置了默认的查询页数。
叶子查询的类型也可以做进一步细分,这里列举一些常见的,例如:
全文检索查询(Full Text Queries):利用分词器对用户输入搜索条件先分词,得到词条,然后再利用倒排索引搜索词条。例如:
精确查询(Term-level queries):不对用户输入搜索条件分词,根据字段内容精确值匹配。但只能查找keyword、数值、日期、boolean类型的字段。例如:
地理坐标查询:用于搜索地理位置,搜索方式很多,例如:
全文检索查询的一种,会对用户输入内容分词,然后去倒排索引库检索。语法:
GET /{索引库名}/_search
{
"query": {
"match": {
"字段名": "搜索关键子"
}
}
}
示例:
与match查询类似,区别在于可以同时对多个字段搜索,而且多个字段都要满足,语法示例:
GET /{索引库名}/_search
{
"query": {
"multi_match": {
"query": "搜索关键子",
"fields": ["字段1", "字段2"]
}
}
}
示例:
精确查询,英文是Term-level query
,顾名思义,词条级别的查询。也就是说不会对用户输入的搜索条件再分词,而是作为一个词条,与搜索的字段内容精确值匹配。因此推荐查找keyword
、数值、日期、boolean
类型的字段。例如: id、price、城市、地名、人名等作为一个整体才有含义的字段。
语法如下:
GET /{索引库名}/_search
{
"query": {
"term": {
"字段名": {
"value": "搜索关键子"
}
}
}
}
示例:
当你输入的搜索条件不是词条,而是短语时,由于不做分词,你反而搜索不到:
语法如下:
GET /{索引库名}/_search
{
"query": {
"range": {
"字段名": {
"gte": {最小值},
"lte": {最大值}
}
}
}
}
示例:
根据文档的id查询,语法如下:
{
"query": {
"ids": {
"values": ["文档id01","文档id02"]
}
}
}
示例:
bool查询,即布尔查询。就是利用逻辑运算来组合一个或多个查询子句的组合。
bool查询支持的逻辑运算有:
must:必须匹配每个子查询,类似“与”
should:选择性匹配子查询,类似“或”
must_not:必须不匹配,不参与算分,类似“非”
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}}}
]
}
}
}
搜索结果:
当我们利用match查询时,文档结果会根据与搜索词条的关联度打分(_score),返回结果时按照分值降序排列。
例如,我们搜索 "手机",结果如下:
从elasticsearch5.1开始,采用的相关性打分算法是BM25算法,公式如下:
基于这套公式,就可以判断出某个文档与用户搜索的关键字之间的关联度,还是比较准确的。但是,在实际业务需求中,常常会有竞价排名的功能。不是相关度越高排名越靠前,而是掏的钱多的排名靠前。
要想控制相关性算分,就需要利用elasticsearch中的 function score 查询了。
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
function score的运行流程如下:
1)根据原始条件查询搜索文档,并且计算相关性算分,称为原始算分(query score)
2)根据过滤条件,过滤文档
3)符合过滤条件的文档,基于算分函数运算,得到函数算分(function score)
4)将原始算分(query score)和函数算分(function score)基于运算模式做运算,得到最终结果,作为相关性算分。
给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" // 加权模式,求乘积
}
}
}
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" // 根据销量降序
}
]
}
结果:小米手机和华为手机的价格一样,当时小米手机的销量比华为的高,所以比较靠前
elasticsearch 默认情况下只返回top10的数据。而如果要查询更多数据就需要修改分页参数了。
elasticsearch中通过修改from
、size
参数来控制要返回的分页结果:
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)
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名。
实现思路:
从实现思路来分析,肯定是将所有数据排序,找出前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形成快照,保存下来,基于快照做分页。官方已经不推荐使用。
总结:
大多数情况下,我们采用普通分页就可以了。查看百度、京东等网站,会发现其分页都有限制。例如百度最多支持77页,每页不足20条。京东最多100页,每页最多60条。
因此,一般我们采用限制分页深度的方式即可,无需实现深度分页
什么是高亮显示呢?
我们在百度,京东搜索时,关键字会变成红色,比较醒目,这个便是高亮显示:
观察页面源码,你会发现两件事情:
高亮词条都被加了<em>
标签
<em>
标签都添加了红色样式
css样式肯定是前端实现页面的时候写好的,但是前端编写页面的时候是不知道页面要展示什么数据的,不可能给数据加标签。而服务端实现搜索功能,要是有elasticsearch
做分词搜索,是知道哪些词条需要高亮的。 因此词条的高亮标签肯定是由服务端提供数据的时候已经加上的。
因此实现高亮的思路就是:
用户输入搜索关键字搜索数据
服务端根据搜索关键字到elasticsearch搜索,并给搜索结果中的关键字词条添加html
标签
前端提前给约定好的html
标签添加CSS
样式
事实上elasticsearch已经提供了给搜索关键字加标签的语法,无需我们自己编码。
基本语法如下:
GET /{索引库名}/_search
{
"query": {
"match": {
"搜索字段": "搜索关键字"
}
},
"highlight": {
"fields": {
"高亮字段名称": { // 指定要高亮的字段
"pre_tags": "<em>", // 高亮的前置标签
"post_tags": "</em>" // 高亮的后置标签
}
}
}
}
示例:
_source的文档信息是不会有任何变化的,可以看到多了一个highlight的属性,里面的name值加上了高亮的标签了
查询的DSL是一个大的JSON对象,包含下列常用属性:
query
:查询条件
from
和size
:分页条件
sort
:排序条件
highlight
:高亮条件
GET /goods/_search
{
"query": {
"match": {
"name": "华为"
}
},
"from": 0, // 分页开始的位置
"size": 20, // 分页的文档数量
"sort": [ // 排序
{
"price": "desc"
}
],
"highlight": {
"fields": {
"name": { // 高亮字段
"pre_tags": "<em>", // 高亮字段的前置标签
"post_tags": "</em>" // 高亮字段的后置标签
}
}
}
}
之前说过,由于Elasticsearch对外暴露的接口都是Restful风格的接口,因此JavaAPI调用就是在发送Http请求。而我们核心要做的就是利用利用Java代码组织请求参数,解析响应结果。
这个参数的格式完全参考DSL查询语句的JSON结构,因此我们在学习的过程中,会不断的把JavaAPI与DSL语句对比。大家在学习记忆的过程中,也应该这样对比学习。
文档的查询依然使用之前学习的RestHighLevelClient
对象,查询的基本步骤如下:
request
对象,这次是搜索,所以是SearchRequest
首先以match_all
查询为例,其DSL和JavaAPI的对比如图:
代码解读:
第一步,创建SearchRequest
对象,指定索引库名
第二步,利用request.source()
构建DSL,DSL中可以包含查询、分页、排序、高亮等
query()
:代表查询条件,利用QueryBuilders.matchAllQuery()
构建一个match_all
查询的DSL
第三步,利用client.search()
发送请求,得到响应
这里关键的API有两个,一个是request.source()
,它构建的就是DSL中的完整JSON参数。其中包含了query
、sort
、from
、size
、highlight
等所有功能:
另一个是QueryBuilders
,其中包含了我们学习过的各种叶子查询、复合查询等:
在发送请求以后,得到了响应结果SearchResponse
,这个类的结构与我们在kibana中看到的响应结果JSON结构完全一致:
格式化之后:
因此,我们解析SearchResponse
的代码就是在解析这个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);
}
}
所有的查询条件都是由QueryBuilders来构建的,叶子查询也不例外。因此整套代码中变化的部分仅仅是query条件构造的方式,其它不动。
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);
}
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);
}
复合查询也是由QueryBuilders
来构建,我们以bool
查询为例,DSL和JavaAPI的对比如图:
案例:利用JavaRestClient实现搜索功能,条件如下:
代码如下:
@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);
}
查询结果:可以看到都是符合条件的
之前说过,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);
}
高亮查询与前面的查询有两点不同:
条件同样是在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高亮的时候需要对原始的字段内容进行切割,找到对应高亮的内容加标签。那么在处理的过程中会有一个阈值,当你的字段值过长,就会把这个原本的字符串切成几个片段, 然后放到一个数组当中,形成高亮字符串的一个数组。这种情况下就需要取出所有片段拼装在一起才能得到完整的内容。