Elasticsearch Query DSL之Term level queries

本文将开始探讨 elasticsearch 的另外一种查询方式：term_query。

term_level查询操作的是存储在反向索引（倒排索引）中的准确词根，这些查询通常用于结构化数据，如数字、日期和枚举，而不是全文字段，无需进行分析（分词），term level查询类似于关系型数据库的（where条件过滤）。其查询模式如下：

term query
查找包含指定字段中精确匹配查询字符串的文档。
terms query
查找包含指定字段中包含查询词根集合中任意一个精确匹配的文档。
terms_set query
查找与一个或多个指定词根相匹配的文档。必须匹配的项的数量取决于指定的最小值或脚本。
range query
范围查询
exists query
返回在原始字段中至少有一个非空值的文档
prefix query
前缀查询
wildcard query
通配符查询
regexp query
正则表达式查询
fuzzy query
模糊查询
type query
指定类型查询
ids query
ids数组查询。

2.1 terms 查询机制
2.2 java(Demo示例)

3、terms_set query
4、range query

4.1 data maths(日期函数)
4.2 日期类型范围查询示例(使用date maths)
4.3 日期类型范围查询示例(使用日期格式转换)

5、exists query

5.1 null_value映射
5.2 查询不存在某个字段的文档

6、prefix query
7、Wildcard Query
8、regexp Query
9、fuzzy query
10、type query
11、ids query

term query

term query从索引库中的词根倒排索引中精确匹配文档。

POST _search
{
  "query": {
    "term" : { "user" : "Kimchy" } 
  }
}

其含义就是，查找user属性为"Kimchy"的文档，执行查询之前，不会对查询字符串"Kimchy"进行分词。term query查询支持boost参数来提高单个词根的相关度。

不同字段类型的分析处理过程不净相同，下面是各数据类型的处理机制：
字符串字段（string）可以是文本类型(作为全文处理，如电子邮件正文)，也可以是关键字类型(keyword)(作为确切值处理，如电子邮件地址或邮政编码)。精确值(如数字、日期和关键字类型)将字段中指定的精确值添加到倒排索引中，以使其可搜索。
text类型的字段，其值首先会进行分析（使用分词器）然后得出一系列的词根，然后将词根添加到倒排索引中。分析文本有很多方法:默认的标准分析器删除大多数标点符号，将文本分解为单个单词，并使用小写字母，在创建索引映射（类似于关系型数据库的表结构，当然有区别）时可以指定各个字段的分词器，在查询的时候也可以使用指定的分词器对查询字符串进行分析，其配置参数名称为：analyzer 。

下面举例说明一下全文索引(match_query)与精确查询(term_query)的工作过程：

PUT my_index
{
  "mappings": {
    "_doc": {
      "properties": {
        "full_text": {
          "type":  "text"    // @1 
        },
        "exact_value": {
          "type":  "keyword"    // @2
        }
      }
    }
  }
}
PUT my_index/_doc/1    // @3
{
  "full_text":   "Quick Foxes!",                   
  "exact_value": "Quick Foxes!"              
}

根据上面介绍得知，字段full_text的值会先使用分词器进行分析，然后将分词后的词根存入倒排索引中，而字段exact_value则会直接将值当成词根存入倒排索引中，并不会进行分词。代码@3存入一个文档，full_text的"Quick Foxes!"默认使用标准分词器，则会生产词根[quick、foxes]，然后将quick、foxes存入倒排索引中，而字段exact_value不会使用分词器，直接将"Quick Foxes!"存入倒排索引中。

基于上面的索引定义与数据，来分析一下这些查询是否能匹配到该文档：
查阅示例1：

GET my_index/_search                       
{
  "query": {
    "term": {
      "exact_value": "Quick Foxes!" 
    }
  }
}

分析：使用term_query，并且字段为exact_value，表示精确匹配得知，该字段存储的值与查询值完成匹配，故结论为能匹配到文档。
查询示例2：

扫描二维码关注公众号，回复： 8586655 查看本文章

GET my_index/_search                        
{
  "query": {
    "term": {
      "full_text": "Quick Foxes!" 
    }
  }
}

分析：使用term_query匹配，使用full_text字段，查询字符串与存入文档之前的值一样，看似能匹配上，但其实不然，根据上面的分析可值，由于full_text字段的类型为text，存入倒排序列的并不是"Quick Foxes!",而是quick、foxes，故结论为无法匹配到文档。
查询示例3：

GET my_index/_search                        
{
 "query": {
   "term": {
     "full_text": "foxes" 
   }
 }
}

分析：使用term_query，并且采用查询字符串foxes，由于full_text是text字段类型，会先进行分词，故会存入quick、foxes两个词根，与输入字符串foxes匹配，故结论为能匹配到文档。
查询示例4：

GET my_index/_search                        
{
  "query": {
    "match": {
      "full_text": "Quick Foxes!" 
    }
  }
}

分析：使用match query(权威搜索)，会首先对查询字符串进行分词，然后根据词根一一匹配，故该结果能匹配到文档。

2、terms query

查找包含指定字段中包含查询词根集合中任意一个精确匹配的文档。实例如下：

GET /_search
{
    "query": {
        "terms" : { "user" : ["kimchy", "elasticsearch"]}
    }
}

其查询的意图：查询"user"属性的值为"kimchy"或"elasticsearch"的文档。

2.1 terms 查询机制

试想如下一个场景，在微博应用场景中，需要查看关注你的所有用户发布的微博，那这个查询第一步应该是得到关注你的所有用户列表，然后查询微博的发布者ID在关注你的列表集合中的所有文档。这个关注列表一般不会很小，如果要分两步来实现的话，查询中传入的terms这个集合会很大，相当于关系型数据库中的in (很大的集合)，那有没有一种机制，支持类似关系型数据库中 a.id in ( select b.id from B b where …)这种方式呢？答案当然是有的。下面下能给出本次试验的基础数据：

PUT /users/_doc/2
{
    "followers" : ["1", "3"]
}

PUT /tweets/_doc/1
{
    "user" : "1"
}

//其查询写法如下：

GET /tweets/_search
{
    "query" : {
        "terms" : {
            "user" : {
                "index" : "users",
                "type" : "_doc",
                "id" : "2",
                "path" : "followers"
            }
        }
    }
}

查询terms支持如下参数：

index 指定查询索引名（相当于关系型数据库database）
type 指定类型名(相当于关系型数据库table)
id 指定文档的id(相当于关系型数据库的row 主键id)
path：值来自哪个字段，支持级联，例如followers.id等嵌套json属性。
routing：指定路由字段值。

从上可知，terms过滤器的值将从具有指定类型的索引中的指定id的文档中的字段中获取。在内部执行get请求以从指定路径（_source字段中存储的值）中提取。

使用大量词根执行terms查询请求可能相当缓慢，因为每个词根都需要额外的处理和占用内存。为了防止出现这种情况，可以设置最大支持的terms的个数，默认为65536。可以通过设置index.max_terms_count来更改此默认值。

2.2 java(Demo示例)

public static void testTermsQuery() {
		RestHighLevelClient client = EsClient.getClient();
		try {
			SearchRequest searchRequest = new SearchRequest();
			searchRequest.indices("esdemo");
			SearchSourceBuilder sourceBuilder = new SearchSourceBuilder();
			
			sourceBuilder.query(
					QueryBuilders.termsQuery("context", "fox", "brown")
					);
//			TermsLookup termsLookup = new TermsLookup("esdemo", "matchquerydemo", "1", "context");
//			termsLookup.routing("1");
//			sourceBuilder.query(
//				QueryBuilders.termsLookupQuery("context", termsLookup);
//			);
			searchRequest.source(sourceBuilder);
			SearchResponse result = client.search(searchRequest, RequestOptions.DEFAULT);
			System.out.println(result);
		} catch (Throwable e) {
			e.printStackTrace();
		} finally {
			EsClient.close(client);
		}
	}

3、terms_set query

查找与一个或多个指定词根相匹配的文档。必须匹配的项的数量取决于指定的最小值或脚本。必须匹配的项的数量根据每个文档的不同而不同，并且由最小值控制的项应该匹配字段，或者由最小值计算的每个文档应该匹配脚本，先从示例开始讲起：

PUT /my-index
{
    "mappings": {
        "_doc": {
            "properties": {
                "required_matches": {
                    "type": "long"
                }
            }
        }
    }
}

首先为_doc类型新增一个数值型的字段，这里取值为required_matches。

PUT /my-index/_doc/1?refresh
{
    "codes": ["ghi", "jkl"],
    "required_matches": 2
}

PUT /my-index/_doc/2?refresh
{
    "codes": ["def", "ghi"，“test”,"ak"],
    "required_matches": 3
}

在存入es中，会自己决定需要匹配的词根个数，低于这个数值，则不会返回该文档。

GET /my-index/_search
{
    "query": {
        "terms_set": {
            "codes" : {
                "terms" : ["abc", "def", "ghi"],
                "minimum_should_match_field": "required_matches"
            }
        }
    }
}

通过属性minimum_should_match_field指定需要匹配的个数，但这个数值来源于文档内部的字段，故该属性值就是指定匹配个数的来源属性名称。该查询结构也支持脚本，其脚本指定字段为minimum_should_match_script，关于script脚本将会在专门的章节中讲述。

4、range query

范围查询。查询的类型取决于字段类型，对于string字段，是TermRangeQuery，而对于number/date字段，查询是NumericRangeQuery。以下示例返回年龄在10到20岁之间的所有文档。

GET _search
{
    "query": {
        "range" : {
            "age" : {
                "gte" : 10,
                "lte" : 20,
                "boost" : 2.0
            }
        }
    }
}

range query支持如下参数：

gte 大于等于
gt 大于
lte 小于等于
lt 小于
boost 权重（重要程度）

4.1 data maths(日期函数)

日期表达式以一个日期（基准日期，锚定日期）开始，可以是now，也可以是以||结尾的日期字符串。这个锚定日期可以有选择地跟随一个或多个数学表达式，例如：

+1h 增加一小时
-1d 减少一天
/d - 向日取整（返回该天的整点）
/M -向月取整（返回该月的第一天的整点）

日期支持如下时间单位：

y 年
M 月
w 周
d 日
h 小时（12表示法）
H 小时(24表示法)
m 分钟
s 小时

假设现在是2001-01-01 12:00:00，以下是一些例子:
1、now+1h
当前时间加1小时，最终表示为：2001-01-01 13:00:00
2、now-1h
当前时间减1小时，最终表示为：2001-01-01 11:00:00
3、now-1h/d
先减去一小时，为2001-01-01 11:00:00，然后舍弃d后面的时间，这里是舍弃11:00:00，故最终表示为2001-01-01 00:00:00
4、2001.02.01||+1M/d
2001-02-01先加一个月，变为2001-03-01，然后舍弃天后的实际，最终表示为2001-03-01 00:00:00

4.2 日期类型范围查询示例(使用date maths)

GET _search
{
    "query": {
        "range" : {
            "date" : {
                "gte" : "now-1d/d",
                "lt" :  "now/d"
            }
        }
    }
}

例如当前时间为2018-10-24 12:25:35,则代表查询的含义为date字段的值大于等于2018-10-23 00:00:00 小于 2018-10-24 00:00:00。

当使用日期数学将日期四舍五入到最近的日、月、小时等时，四舍五入的日期取决于范围的两端是否包含或排除。舍入移动到舍入范围的最后一毫秒，舍出到舍入范围的第一毫秒。关于各运算符的舍入舍出规则如下：

gt
2014-11-18||/M becomes 2014-11-30T23:59:59.999, 使用gt(不包含e)，是向上，取当月最后一天23:59:59
gte
2014-11-18||/M becomes 2014-11-01，如果运算符为大于等于，则向下舍弃，取当月第一天零点
lt
2014-11-18||/M becomes 2014-11-01，如果运算算法小于，则向下舍弃
lte
2014-11-18||/M becomes 2014-11-30T23:59:59.999, 小于等于，则向上，取当月最后一天的23:59:59

4.3 日期类型范围查询示例(使用日期格式转换)

GET _search
{
    "query": {
        "range" : {
            "born" : {
                "gte": "01/01/2012",
                "lte": "2013",
                "format": "dd/MM/yyyy||yyyy"
            }
        }
    }
}

format使用双竖线|| 做分隔符号，上面表示，查询born字段大于等于2012-01-01 00:00:00 小于等于2013-01-01 00:00:00。
如果需要年月日，消息分钟，请用如下写法：

QueryBuilders.rangeQuery("post_date")
			.gte("2018-10-25T14:12:10")
			.lte("2018-10-27T14:12:10")
			.format("yyyy-MM-dd'T'HH:mm:ss||yyyy-MM-dd'T'HH:mm:ss")。//  ‘T’用来分隔 年月日  与  时分秒。

5、exists query

返回指定字段中至少有一个非空值（null）的文档。示例如下：

GET /_search
{
    "query": {
        "exists" : { "field" : "user" }
    }
}

对于上面的查询，下面的所有文档都将符合要求：
{ “user”: “jane” }
{ “user”: “” } // 空字符串不为null
{ “user”: “-” }
{ “user”: [“jane”] }
{ “user”: [“jane”, null ] } //因为存在jane值不为null，则匹配。

5.1 null_value映射

自定义null值。例如将"null"字符串定义为null值。

PUT /example
{
  "mappings": {
    "_doc": {
      "properties": {
        "user": {
          "type": "keyword",
          "null_value": "_null_"
        }
      }
    }
  }
}

其作用是会将user字段的null值索引为_null_字符串，则下面的文档将能被exists匹配：
{ “user”: null }
{ “user”: [null] }

5.2 查询不存在某个字段的文档

GET /_search
{
    "query": {
        "bool": {
            "must_not": {
                "exists": {
                    "field": "user"
                }
            }
        }
    }
}

查询不存在属性user的文档。

6、prefix query

词根前缀查询，对查询词根不会使用分词器进行分词。使用示例如下：

GET /_search
{ "query": {
    "prefix" : { "user" : "ki" }
  }
}

同样，也可以未字段设置权重(boost)。示例如下：

GET /_search
{ "query": {
    "prefix" : { "user" :  { "value" : "ki", "boost" : 2.0 } }
  }
}

其代表含义可转换为关系型数据库查询语句：where a.user like ‘ki%’。
思考一下，如果存在有文档的user字段的值为"Kimmi"，使用如下字符查询条件：

{ "query": {
    "prefix" : { "user" : "Ki" }
  }
}

该查询能匹配到结果吗？在默认使用标准分词器的环境中，是无法匹配到数据的，其原因如下：首先，在存储文档时，首先会对"kimmi"字段进行分词，返回的词根为kimmi(全小写)，将这些词根存入到Elasticsearch(lucene)的倒排索引中，然后进行查询时，并不会使用分词器对 prefix进行分词，故查询字符串为Ki，是无法匹配到上述文档的，要向匹配到文档，请使用小写的查询ki。这也是ES中的term(词根精确查询)与关系型数据库的一个非常重要的区别。

JAVA代码查询示例：

public static void testTermQuery_prefix() {
		RestHighLevelClient client = EsClient.getClient();
		try {
			SearchRequest searchRequest = new SearchRequest();
			searchRequest.indices("twitter");
			SearchSourceBuilder sourceBuilder = new SearchSourceBuilder();
			sourceBuilder.query(
					QueryBuilders.prefixQuery("user", "ki")
					.boost(2.0f)
			);
			searchRequest.source(sourceBuilder);
			SearchResponse result = client.search(searchRequest, RequestOptions.DEFAULT);
			System.out.println(result);
		} catch (Throwable e) {
			e.printStackTrace();
		} finally {
			EsClient.close(client);
		}
	}

7、Wildcard Query

通配符匹配。支持的通配符为和?。其中代表任何的字符序列，包含空字符，而?代表任意的单个字符。这种查询需慎重，特别是对于以通配符开头的查询，例如"a"或"?b"，因为这种需要遍历整个倒排索引，通常建议使用 “查询字符加通配符”，例如"a"或"a*b"这类。

其查询举例如下：

GET /_search
{
    "query": {
        "wildcard" : { "user" : "ki*y" }
    }
}

对应的java查询如下：

public static void testWildcardQuery() {
		RestHighLevelClient client = EsClient.getClient();
		try {
			SearchRequest searchRequest = new SearchRequest();
			searchRequest.indices("esdemo");
			SearchSourceBuilder sourceBuilder = new SearchSourceBuilder();
			sourceBuilder.query(
					QueryBuilders.wildcardQuery("user", "ki*il")
					);
			searchRequest.source(sourceBuilder);
			SearchResponse result = client.search(searchRequest, RequestOptions.DEFAULT);
			System.out.println(result);
		} catch (Throwable e) {
			e.printStackTrace();
		} finally {
			EsClient.close(client);
		}
	}

8、regexp Query

正则表达式查询。

9、fuzzy query

模糊匹配，基于词根编辑距离来实现。所谓的词根编辑距离（其术语为： Levenshtein Edit Distance）是指一个词（字符序列）经过多少次单字符的修改能转换为另外一个词的次数。例如 cat --> cak 其编辑距离为1。
支持模糊匹配的查询API，其参数fuzziness可选值：

0：表示精确匹配。
1：表示允许出现1个编辑距离。
2：表示允许出现2个编辑距离。
auto:当词根长度小于3时，则精确匹配；当词根长度大于3并且小于6时，允许1个编辑长度的词根匹配；当词根大于等于6后，允许2个编辑距离的词根匹配。默认为auto。

注意：fuzzy query是词根级别的查询，不会对查询字符串进行分析。
fuzziness 允许的编辑距离，默认为AUTO。

prefix_length 词根的前prefix_length个字符不允许出现编辑距离，指一个词根前面的部分必须是精确匹配，因为模糊匹配，一般是用来解决书写错误，或语法（因为的负数）等，前面的字符一般不会书写错误。

max_expansions 最大去查找匹配词根的个数，默认为50。
transpositions 是否支持位置变化，例如ab-ba，如果transpositions为true，则ab-ba的编辑距离为1,如果transpositions为false，则其编辑距离为2。默认为false。

其JAVA示例如下：
假设es数据库中缓存有如下文档：{“message”:“ab and hell”}

/**
	 * 日期范围查询demo
	 */
	public static void testFuzzyQuery() {
		RestHighLevelClient client = EsClient.getClient();
		try {
			SearchRequest searchRequest = new SearchRequest();
			searchRequest.indices("twitter");
			SearchSourceBuilder sourceBuilder = new SearchSourceBuilder();
			sourceBuilder.query(
					QueryBuilders.fuzzyQuery("message", "ba")
					.transpositions(true)
					.fuzziness(Fuzziness.ONE)  // 如果transpositions设置为false,则无法匹配到上述文档，如果将fuzziness(Fuzziness.TWO)，则
                                           // 可匹配到文档，但如果transpositions=true，并且fuzziness(Fuzziness.ONE)同样可匹配到文档。
			);
			searchRequest.source(sourceBuilder);
			SearchResponse result = client.search(searchRequest, RequestOptions.DEFAULT);
			System.out.println(result);
		} catch (Throwable e) {
			e.printStackTrace();
		} finally {
			EsClient.close(client);
		}
	}

10、type query

term level queries 支持使用type来过滤文档（相当于数据库层面的表级别过滤）

GET /_search
{
    "query": {
        "type" : {
            "value" : "_doc"
        }
    }
}

11、ids query

可以通过指定ids数组进行查询，其示例如下：

GET /_search
{
    "query": {
        "ids" : {
            "type" : "_doc",
            "values" : ["1", "4", "100"]
        }
    }
}

其中type为可选字段，如果未指定，则查索引库中所有的类别。

关于 term query 就介绍到这里了，如果觉的文章还不错的话，希望帮忙点个赞，谢谢。

唯有坚持不懈博客专家

发布了197 篇原创文章 · 获赞 321 · 访问量 42万+

他的留言板关注