Elasticsearch整理笔记

Posted 2023-01-27

es中的查询请求有两种方式，一种是简易版的查询，另外一种是使用JSON完整的请求体，叫做结构化查询（DSL）。
由于DSL查询更为直观也更为简易，所以大都使用这种方式。
DSL查询是POST过去一个json，由于post的请求是json格式的，所以存在很多灵活性，也有很多形式。
这里有一个地方注意的是官方文档里面给的例子的json结构只是一部分，并不是可以直接黏贴复制进去使用的。一般要在外面加个query为key的机构。

match
最简单的一个match例子：

查询和"我的宝马多少马力"这个查询语句匹配的文档。

​​​​ ​​"query"​​​​: ​​ ​​"match"​​​​: ​​ ​​"content"​​​​: ​​ ​​"query"​​​​: ​​​​"我的宝马多少马力"​​ ​​​​ ​​​​ ​​​​ ​​​​

上面的查询匹配就会进行分词，比如"宝马多少马力"会被分词为"宝马 多少 马力", 所有有关"宝马 多少 马力", 那么所有包含这三个词中的一个或多个的文档就会被搜索出来。
并且根据lucene的评分机制(TF/IDF)来进行评分。

match_phrase
比如上面一个例子，一个文档"我的保时捷马力不错"也会被搜索出来，那么想要精确匹配所有同时包含"宝马 多少 马力"的文档怎么做？就要使用 match_phrase 了

​​​​ ​​"query"​​​​: ​​ ​​"match_phrase"​​​​: ​​ ​​"content"​​​​: ​​ ​​"query"​​​​: ​​​​"我的宝马多少马力"​​ ​​​​ ​​​​ ​​​​ ​​​​

完全匹配可能比较严，我们会希望有个可调节因子，少匹配一个也满足，那就需要使用到slop。

​​​​ ​​"query"​​​​: ​​ ​​"match_phrase"​​​​: ​​ ​​"content"​​​​: ​​ ​​"query"​​​​: ​​​​"我的宝马多少马力"​​​​,​​ ​​"slop"​​​​: ​​​​1​​ ​​​​ ​​​​ ​​​​ ​​​​

multi_match
如果我们希望两个字段进行匹配，其中一个字段有这个文档就满足的话，使用multi_match

​​​​ ​​"query"​​​​: ​​ ​​"multi_match"​​​​: ​​ ​​"query"​​​​: ​​​​"我的宝马多少马力"​​​​,​​ ​​"fields"​​​​: [​​​​"title"​​​​, ​​​​"content"​​​​]​​ ​​​​ ​​​​ ​​​​

但是multi_match就涉及到匹配评分的问题了。

我们希望完全匹配的文档占的评分比较高，则需要使用best_fields

​​​​ ​​"query"​​​​: ​​ ​​"multi_match"​​​​: ​​ ​​"query"​​​​: ​​​​"我的宝马发动机多少"​​​​,​​ ​​"type"​​​​: ​​​​"best_fields"​​​​,​​ ​​"fields"​​​​: [​​ ​​"tag"​​​​,​​ ​​"content"​​ ​​],​​ ​​"tie_breaker"​​​​: ​​​​0.3​​ ​​​​ ​​​​ ​​​​

意思就是完全匹配"宝马 发动机"的文档评分会比较靠前，如果只匹配宝马的文档评分乘以0.3的系数

我们希望越多字段匹配的文档评分越高，就要使用most_fields

​​​​ ​​"query"​​​​: ​​ ​​"multi_match"​​​​: ​​ ​​"query"​​​​: ​​​​"我的宝马发动机多少"​​​​,​​ ​​"type"​​​​: ​​​​"most_fields"​​​​,​​ ​​"fields"​​​​: [​​ ​​"tag"​​​​,​​ ​​"content"​​ ​​]​​ ​​​​ ​​​​ ​​​​

我们会希望这个词条的分词词汇是分配到不同字段中的，那么就使用cross_fields

​​​​ ​​"query"​​​​: ​​ ​​"multi_match"​​​​: ​​ ​​"query"​​​​: ​​​​"我的宝马发动机多少"​​​​,​​ ​​"type"​​​​: ​​​​"cross_fields"​​​​,​​ ​​"fields"​​​​: [​​ ​​"tag"​​​​,​​ ​​"content"​​ ​​]​​ ​​​​ ​​​​ ​​​​

term
term是代表完全匹配，即不进行分词器分析，文档中必须包含整个搜索的词汇

​​​​ ​​"query"​​​​: ​​ ​​"term"​​​​: ​​ ​​"content"​​​​: ​​​​"汽车保养"​​ ​​​​ ​​​​ ​​​​

查出的所有文档都包含"汽车保养"这个词组的词汇。

使用term要确定的是这个字段是否“被分析”(analyzed)，默认的字符串是被分析的。

拿官网上的例子举例：

mapping是这样的：

​​PUT my_index ​​ ​​"mappings"​​​​: ​​ ​​"my_type"​​​​: ​​ ​​"properties"​​​​: ​​ ​​"full_text"​​​​: ​​ ​​"type"​​​​: ​​​​"string"​​ ​​,​​ ​​"exact_value"​​​​: ​​ ​​"type"​​​​: ​​​​"string"​​​​,​​ ​​"index"​​​​: ​​​​"not_analyzed"​​ ​​​​ ​​​​ ​​​​ ​​​​ ​​​​

 

​​PUT my_index / my_type / ​​​​1​​​ ​​​​ ​​"full_text"​​​​: ​​​​"Quick Foxes!"​​​​,​​ ​​"exact_value"​​​​: ​​​​"Quick Foxes!"​​ ​​​​

其中的full_text是被分析过的，所以full_text的索引中存的就是[quick, foxes]，而extra_value中存的是[Quick Foxes!]。

那下面的几个请求：

​​GET my_index / my_type / _search ​​ ​​"query"​​​​: ​​ ​​"term"​​​​: ​​ ​​"exact_value"​​​​: ​​​​"Quick Foxes!"​​ ​​​​ ​​​​ ​​​​

请求的出数据，因为完全匹配

​​GET my_index / my_type / _search ​​ ​​"query"​​​​: ​​ ​​"term"​​​​: ​​ ​​"full_text"​​​​: ​​​​"Quick Foxes!"​​ ​​​​ ​​​​ ​​​​

请求不出数据的，因为full_text分词后的结果中没有[Quick Foxes!]这个分词。

 

bool查询

filter：不参与评分的快速查询

​​GET _search ​​ ​​"query"​​​​: ​​ ​​"bool"​​​​: ​​ ​​"filter"​​​​: ​​ ​​"term"​​​​: ​​ ​​"content"​​​​: ​​​​"宝马"​​ ​​​​ ​​​​ ​​​​ ​​​​ ​​​​

range：范围过滤

​​GET _search ​​ ​​"post_filter"​​​​:​​ ​​"range"​​​​:​​ ​​"price"​​​​:​​​​"gt"​​​​:​​​​35​​​​, ​​​​"lt"​​​​: ​​​​50​​​​​​ ​​​​ ​​​​ ​​​​

exists：字段有值

​​查询price有值的， ​​​​null​​​​也不行​​ ​​GET _search ​​ ​​"post_filter"​​​​: ​​ ​​"exists"​​​​: ​​ ​​"field"​​​​: ​​​​"price"​​ ​​​​ ​​​​ ​​​​ ​​查询price有值的， ​​​​null​​​​也不行​​ ​​GET _search ​​ ​​"query"​​​​: ​​ ​​"bool"​​​​: ​​ ​​"filter"​​​​: ​​ ​​"exists"​​​​: ​​ ​​"field"​​​​: ​​​​"price"​​ ​​​​ ​​​​ ​​​​ ​​​​ ​​​​

 

bool联合查询: must,should,must_not
如果我们想要请求"content中带宝马，但是tag中不带宝马"这样类似的需求，就需要用到bool联合查询。
联合查询就会使用到must,should,must_not三种关键词。

这三个可以这么理解

must: 文档必须完全匹配条件
should: should下面会带一个以上的条件，至少满足一个条件，这个文档就符合should
must_not: 文档必须不匹配条件
比如上面那个需求：

​​​​ ​​"query"​​​​: ​​ ​​"bool"​​​​: ​​ ​​"must"​​​​: ​​ ​​"term"​​​​: ​​ ​​"content"​​​​: ​​​​"宝马"​​ ​​​​ ​​,​​ ​​"must_not"​​​​: ​​ ​​"term"​​​​: ​​ ​​"tags"​​​​: ​​​​"宝马"​​ ​​​​ ​​​​ ​​​​ ​​​​ ​​​​

聚合查询：

filtered查询

如果你想要找到所有售价高于10000美刀的车，同时也对这些车计算其平均价格，那么可以使用一个filtered查询：

​​GET _search?search_type=count​​ ​​​​ ​​"query"​​​ ​​: ​​ ​​"filtered"​​​​: ​​ ​​"filter"​​​​: ​​ ​​"range"​​​​: ​​ ​​"price"​​​​: ​​ ​​"gte"​​​​: ​​​​10000​​ ​​​​ ​​​​ ​​​​ ​​​​ ​​,​​ ​​"aggs"​​​ ​​: ​​ ​​"single_avg_price"​​​​: ​​ ​​"avg"​​​ ​​: ​​​​"field"​​​ ​​: ​​​​"price"​​​ ​​​​ ​​​​ ​​​​ ​​​​

 

从本质上而言，使用filtered查询和使用match查询并无区别，正如我们在上一章所讨论的那样。该查询(包含了一个过滤器)返回文档的一个特定子集，然后聚合工作在该子集上。

过滤桶(Filter Bucket)

如果你只想过滤聚合结果呢？假设我们正在创建针对汽车交易的搜索页面，我们想要根据用户搜索内容来展示对应结果。但是我们也想通过包含上个月出售的汽车的平均价格(匹配搜索的汽车)来让页面更加丰富。

此时我们不能使用简单的作用域，因为有两个不同搜索条件。搜索结果必须要匹配ford，但是聚合结果必须要匹配ford以及售出时间为上个月。

为了解决这一问题，我们使用一个名为filter的特殊桶。通过制定一个过滤器，当文档匹配了该过滤器的规则时，它就会被添加到桶中。

以下是得到的查询：

​​GET _search?search_type=count​​ ​​​​ ​​"query"​​​​:​​ ​​"match"​​​​: ​​ ​​"make"​​​​: ​​​​"ford"​​ ​​​​ ​​,​​ ​​"aggs"​​​​:​​ ​​"recent_sales"​​​​: ​​ ​​"filter"​​​​: ​​ ​​"range"​​​​: ​​ ​​"sold"​​​​: ​​ ​​"from"​​​​: ​​​​"now-1M"​​ ​​​​ ​​​​ ​​,​​ ​​"aggs"​​​​: ​​ ​​"average_price"​​​​:​​ ​​"avg"​​​​: ​​ ​​"field"​​​​: ​​​​"price"​​ ​​​​ ​​​​ ​​​​ ​​​​ ​​​​ ​​​​

 

因为过滤器桶和任何其它桶以相似的方式工作，你可以任意地将其它桶和指标包含在其中。所有的嵌套组建都会”继承”该过滤器。从而使你能够根据需要对聚合中的内容进行过滤。

后置过滤器(Post Filter)

目前，我们有了用于过滤搜索结果和聚合的过滤器(filtered查询)，也有了用于过滤聚合中某一部分的过滤器(filter桶)。

你也许会好奇，“是否有一种过滤器只过滤搜索结果，而不过滤聚合呢？”这个问题的答案就是使用post_filter。

它是搜索请求内能够接受一个过滤器作为参数的顶层元素。该过滤器会在查询执行完毕后生效(后置因此得名：在查询执行之后运行)。正因为它在查询执行后才会运行，所以它并不会影响查询作用域 - 因此就不会对聚合有所影响。

我们可以利用这一行为在搜索条件中添加额外的过滤器，而不影响用户界面中类似于类别分面(Categorical Facets)的元素。让我们设计另一个针对汽车交易的搜索页面。该页面允许用户对汽车进行搜索，同时还能够根据颜色进行过滤。颜色通过聚合提供：

​​GET _search?search_type=count​​ ​​​​ ​​"query"​​​​: ​​ ​​"match"​​​​: ​​ ​​"make"​​​​: ​​​​"ford"​​ ​​​​ ​​,​​ ​​"post_filter"​​​​: ​​ ​​"term"​​​ ​​: ​​ ​​"color"​​​ ​​: ​​​​"green"​​ ​​​​ ​​,​​ ​​"aggs"​​​ ​​: ​​ ​​"all_colors"​​​​: ​​ ​​"terms"​​​ ​​: ​​​​"field"​​​ ​​: ​​​​"color"​​​ ​​​​ ​​​​ ​​​​ ​​​​

 

post_filter元素是一个顶层元素，只会对搜索结果进行过滤。

查询部分呢用来找到所有ford汽车。然后我们根据一个terms聚合来得到颜色列表。因为聚合是在查询作用域中进行的，得到的颜色列表会反映出ford汽车的各种颜色。

最后，post_filter会对搜索结果进行过滤，只显示绿色的ford汽车。这一步发生在执行查询之后，因此聚合是不会被影响的。

这一点对于维持一致的用户界面而言是非常重要的。假设一个用户在界面上点击了一个分类(比如，绿色)。期望的结果是搜索结果被过滤了，而用户界面上的分类选项是不会变化的。如果你使用了一个filtered查询，用户界面上也立即会对分类进行更新，此时绿色就变成了唯一的选项 - 这显然不是用户想要的！

只有当你需要对搜索结果和聚合使用不同的过滤方式时才考虑使用post_filter。有时一些用户会直接在常规搜索中使用post_filter。

不要这样做！post_filter会在查询之后才会被执行，因此会失去过滤在性能上帮助(比如缓存)。

post_filter应该只和聚合一起使用，并且仅当你使用了不同的过滤条件时。

选择合适类型的过滤 - 搜索结果(Search Hits)，聚合(Aggregations)，或两者 - 通常都取决于你的用户界面的行为。过滤器的选择(或者组合)取决于你想要如何向用户展示结果数据。

A filtered query affects both search results and aggregations.filtered查询会影响搜索结果和聚合。 
filter桶只影响聚合。 
post_filter只影响搜索结果。

 

关于排序、分页查询

​​GET _search​​ ​​​​ ​​"query"​​​​: ​​ ​​"match_all"​​​​: ​​ ​​,​​ ​​"sort"​​​​: [​​ ​​​​ ​​"age"​​​​: ​​ ​​"order"​​​​: ​​​​"desc"​​ ​​​​ ​​​​ ​​],​​ ​​"from"​​​​: ​​​​2​​​​,​​ ​​"size"​​​​: ​​​​1​​ ​​​​