Elasticsearch高级应用
1. 映射高级
1.1 地理坐标点数据类型
地理坐标点
地理坐标点是指地球表面可以用经纬度描述的一个点。 地理坐标点可以用来计算两个坐标间的距离，还可以判断一个坐标是否在一个区域中。地理坐标点需要显式声明对应字段类型为 geo_point
PUT /company-locations { "mappings":{ "properties":{ "name":{ "type":"text" }, "location":{ "type":"geo_point" } } } }经纬度坐标格式
如上例， location 字段被声明为 geo_point 后，我们就可以索引包含了经纬度信息的文档了。 经纬度信息的形式可以是字符串、数组或者对象
字符串形式
PUT /company-locations/_doc/1 { "name":"NetEase", "location":"40.715,74.011" }对象形式
PUT /company-locations/_doc/2 { "name":"Sina", "location":{ "lat":40.722, "lon":73.989 } }数组形式
PUT /company-locations/_doc/3 { "name":"Baidu", "location":[ 73.983, 40.719 ] }注意 字符串形式以半角逗号分割，如 "lat,lon" 对象形式显式命名为 lat 和 lon 数组形式表示为 [lon,lat]
通过地理坐标点过滤
有四种地理坐标点相关的过滤器 可以用来选中或者排除文档
过滤器 作用 geo_bounding_box 找出落在指定矩形框中的点 geo_distance 找出与指定位置在给定距离内的点 geo_distance_range 找出与指定点距离在给定最小距离和最大距离之间的点 geo_polygon 找出落在多边形中的点。 这个过滤器使用代价很大 。当你觉得自己需要使用它，最好先看看 geo-shapes 。 geo_bounding_box查询
这是目前为止最有效的地理坐标过滤器了，因为它计算起来非常简单。 你指定一个矩形的顶部 ,底部 , 左边界和右边界，然后过滤器只需判断坐标的经度是否在左右边界之间，纬度是否在上下边界之间
然后可以使用 geo_bounding_box 过滤器执行以下查询
GET /company-locations/_search { "query":{ "bool":{ "must":{ "match_all":{ } }, "filter":{ "geo_bounding_box":{ "location":{ "top_left":{ "lat":40.73, "lon":71.12 }, "bottom_right":{ "lat":40.01, "lon":74.1 } } } } } } }location这些坐标也可以用 bottom_left 和 top_right 来表示
geo_distance
过滤仅包含与地理位置相距特定距离内的匹配的文档。假设以下映射和索引文档
然后可以使用 geo_distance 过滤器执行以下查询
GET /company-locations/_search { "query":{ "bool":{ "must":{ "match_all":{ } }, "filter":{ "geo_distance":{ "distance":"200km", "location":{ "lat":40, "lon":70 } } } } } }
1.2 动态映射
Elasticsearch在遇到文档中以前未遇到的字段，可以使用dynamic mapping（动态映射机制） 来确定字段的数据类型并自动把新的字段添加到类型映射。
Elastic的动态映射机制可以进行开关控制，通过设置mappings的dynamic属性，dynamic有如下设置项
- true: 遇到陌生字段就执行dynamic mapping处理机制
- false: 遇到陌生字段就忽略
- strict：遇到陌生字段就报错
#设置为报错
PUT /user
{
"settings":{
"number_of_shards":3,
"number_of_replicas":0
},
"mappings":{
"dynamic":"strict",
"properties":{
"name":{
"type":"text"
},
"address":{
"type":"object",
"dynamic":true
}
}
}
}
# 插入以下文档，将会报错
# user索引层设置dynamic是strict，在user层内设置age将报错
# 在address层设置dynamic是ture，将动态映射生成字段
PUT /user/_doc/1
{
"name":"lisi",
"age":"20",
"address":{
"province":"beijing",
"city":"beijing"
}
}
1.3 自定义动态映射
如果你想在运行时增加新的字段，你可能会启用动态映射。 然而，有时候，动态映射 规则 可能不太智能。幸运的是，我们可以通过设置去自定义这些规则，以便更好的适用于你的数据。
日期检测
当 Elasticsearch 遇到一个新的字符串字段时，它会检测这个字段是否包含一个可识别的日期，比如2014-01-01 如果它像日期，这个字段就会被作为 date 类型添加。否则，它会被作为 string 类型添加。有些时候这个行为可能导致一些问题
想象下，你有如下这样的一个文档：
{ “note”: “2014-01-01” }
假设这是第一次识别 note 字段，它会被添加为 date 字段。但是如果下一个文档像这样：
{ “note”: “Logged out” }
这显然不是一个日期，但为时已晚。这个字段已经是一个日期类型，这个 不合法的日期 将会造成一个异常。
日期检测可以通过在根对象上设置 date_detection 为 false 来关闭
PUT /my_index { "mappings":{ "date_detection":false } }使用这个映射，字符串将始终作为 string 类型。如果需要一个 date 字段，必须手动添加。Elasticsearch 判断字符串为日期的规则可以通过 dynamic_date_formats setting 来设置。
PUT /my_index { "mappings": { "dynamic_date_formats": "MM/dd/yyyy" } } PUT /my_index/_doc/1 { "note": "2014-01-01" } PUT /my_index/_doc/1 { "note": "01/01/2014" }dynamic_templates
使用 dynamic_templates 可以完全控制新生成字段的映射，甚至可以通过字段名称或数据类型来应用不同的映射。
每个模板都有一个名称，你可以用来描述这个模板的用途，一个 mapping 来指定映射应该怎样使用，以及至少一个参数 (如 match) 来定义这个模板适用于哪个字段。
模板按照顺序来检测；第一个匹配的模板会被启用。例如，我们给 string 类型字段定义两个模板：
es ：以 _es 结尾的字段名需要使用 spanish 分词器。
en ：所有其他字段使用 english 分词器。
我们将 es 模板放在第一位，因为它比匹配所有字符串字段的 en 模板更特殊：
PUT /my_index2 { "mappings":{ "dynamic_templates":[ { "es":{ "match":"*_es", "match_mapping_type":"string", "mapping":{ "type":"text", "analyzer":"spanish" } } }, { "en":{ "match":"*", "match_mapping_type":"string", "mapping":{ "type":"text", "analyzer":"english" } } } ] } }PUT /my_index2/_doc/1 { "name_es":"testes", "name":"es" }match_mapping_type 允许你应用模板到特定类型的字段上，就像有标准动态映射规则检测的一样 (例 如 string 或 long)
match参数只匹配字段名称，path_match 参数匹配字段在对象上的完整路径，所以 address.*.name将匹配这样的字段
2. Query DSL
Elasticsearch提供了基于JSON的完整查询DSL（Domain Specifific Language 特定域的语言）来定义查询。将查询DSL视为查询的AST（抽象语法树），它由两种子句组成：
叶子查询子句
叶子查询子句 在特定域中寻找特定的值，如 match，term或 range查询。
复合查询子句
复合查询子句包装其他叶子查询或复合查询，并用于以逻辑方式组合多个查询（例如 bool或dis_max查询），或更改其行为（例如 constant_score查询）。
我们在使用ElasticSearch的时候，避免不了使用DSL语句去查询，就像使用关系型数据库的时候要学会SQL语法一样。如果我们学习好了DSL语法的使用，那么在日后使用和使用Java Client调用时候也会变得非常简单
基本语法:
POST /索引库名/_search
{
"query":{
"查询类型":{
"查询条件":"查询条件值"
}
}
}
查询类型：
- 例如： match_all ， match ， term ， range 等等
查询条件：查询条件会根据类型的不同，写法也有差异，后面详细讲解
2.1 查询所有
POST /qiang-es-demo1/_search
{
"query":{
"match_all": {
}
}
}
结果解析:
- took:查询花费的时间
- time_out:是否超时
- _shards:分片信息
- hits:搜索结果总览对象
- total:总数
- max_sore:所有结果中文档得分的最高分
- hits: 文档对象数据
- _index:索引库
- _type:文档类型
- _id:文档id
- _score:文档得分
- _source:文档的源数据
2.2 全文搜索(full-text query)
全文搜索能够搜索已分析的文本字段，如电子邮件正文，商品描述等
匹配搜索 match query
全文查询的标准查询，它可以对一个字段进行模糊、短语查询。match queries 接收text/numerics/dates, 对它们进行分词分析, 再组织成一个boolean查询。可通过operator 指定bool组合操作（or、and 默认是 or ）。
例:
PUT /qiang-property { "settings":{ }, "mappings":{ "properties":{ "title":{ "type":"text", "analyzer":"ik_max_word" }, "images":{ "type":"keyword" }, "price":{ "type":"float" } } } } #写入文档 POST /qiang-property/_doc/ { "title":"小米电视4A", "images":"http://image.lagou.com/12479122.jpg", "price":4288 } POST /qiang-property/_doc/ { "title":"小米手机", "images":"http://image.lagou.com/12479622.jpg", "price":2699 } POST /qiang-property/_doc/ { "title":"华为手机", "images":"http://image.lagou.com/12479922.jpg", "price":5699 }or关系
match 类型查询，会把查询条件进行分词，然后进行查询,多个词条之间是or的关系
POST /qiang-property/_search { "query": { "match": { "title": "小米电视4A" } } } #在上面的案例中，不仅会查询到电视，而且与小米相关的都会查询到，多个词之间是 or 的关系。and关系
某些情况下，我们需要更精确查找，我们希望这个关系变成 and ，可以这样做
POST /qiang-property/_search { "query": { "match": { "title": { "query": "小米电视4A", "operator": "and" } } } }
短语搜索 match phrase query
match_phrase 查询用来对一个字段进行短语查询，可以指定 analyzer、slop移动因子
POST /qiang-property/_search { "query": { "match_phrase": { "title": "小米电视" } } } POST /qiang-property/_search { "query": { "match_phrase": { "title": "小米 4A" } } } POST /qiang-property/_search { "query": { "match_phrase": { "title": { "query": "小米 4A", "slop": 2 #代表匹配几个 } } } }query_string 查询 Query String Query提供了无需指定某字段而对文档全文进行匹配查询的一个高级查询,同时可以指定在 哪些字段上进行匹配。
POST /qiang-property/_search { "query": { "query_string": { "query": "2699" } } } POST /qiang-property/_search { "query": { "query_string": { "query": "2699", "default_field": "title" } } } #逻辑查询 POST /qiang-property/_search { "query": { "query_string": { "query": "手机 OR 小米", "default_field": "title" } } } #模糊查询 POST /qiang-property/_search { "query": { "query_string": { "query": "大米~1", "default_field": "title" } } } #多字段查询 POST /qiang-property/_search { "query": { "query_string": { "query": "2699", "fields": [ "title", "price" ] } } }多字段匹配搜索 multi match query
如果你需要在多个字段上进行文本搜索，可用multi_match 。multi_match在 match的基础上支持对多个字段进行文本查询
POST /qiang-property/_search { "query": { "multi_match": { "query": "2699", "fields": [ "title", "price" ] } } } #还可以使用*匹配多个字段： POST /qiang-property/_search { "query": { "multi_match": { "query": "http://image.lagou.com/12479622.jpg", "fields": [ "title", "ima*" ] } } }
2.3 词条级搜索 term-level queries
可以使用term-level queries根据结构化数据中的精确值查找文档. 结构化数据的值包括日期范围、IP地址、价格或产品ID。
与全文查询不同，term-level queries不分析搜索词。相反，词条与存储在字段级别中的术语完全匹配。
示例:
PUT /book
{
"settings": {},
"mappings": {
"properties": {
"description": {
"type": "text",
"analyzer": "ik_max_word"
},
"name": {
"type": "text",
"analyzer": "ik_max_word"
},
"price": {
"type": "float"
},
"timestamp": {
"type": "date",
"format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"
}
}
}
}
PUT /book/_doc/4
{
"name": "ElasticSearch",
"description": "Elasticsearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力 的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java语言开发的，并作为Apache许可条 款下的开放源码发布，是一种流行的企业级搜索引擎。Elasticsearch用于云计算中，能够达到实时搜 索，稳定，可靠，快速，安装使用方便。官方客户端在Java、.NET（C#）、PHP、Python、Apache Groovy、Ruby和许多其他语言中都是可用的。根据DB-Engines的排名显示，Elasticsearch是最受欢 迎的企业搜索引擎，其次是Apache Solr，也是基于Lucene。",
"price": 999.99,
"timestamp": "2020-08-15 10:11:35"
}
PUT /book/_doc/3
{
"name": "Hadoop",
"description": "The Apache Hadoop software library is a framework that allows for the distributed processing of large data sets across clusters of computers using simple programming models.",
"price": 620.45,
"timestamp": "2020-08-22 19:18:35"
}
PUT /book/_doc/2
{
"name": "solr",
"description": "Solr is highly scalable, providing fully fault tolerant distributed indexing, search and analytics. It exposes Lucenes features through easy to use JSON/HTTP interfaces or native clients for Java and other languages.",
"price": 320.45,
"timestamp": "2020-07-21 17:11:35"
}
PUT /book/_doc/1
{
"name": "lucene",
"description": "Lucene Core is a Java library providing powerful indexing and search features, as well as spellchecking, hit highlighting and advanced analysis/tokenization capabilities. The PyLucene sub project provides Python bindings for Lucene Core. ",
"price": 100.45,
"timestamp": "2020-08-21 19:11:35"
}
词条搜索 term query
term 查询用于查询指定字段包含某个词项的文档
GET /book/_search { "query": { "term": { "name": "solr" } } }词条集合搜索terms query
GET /book/_search { "query": { "terms": { "name": [ "solr", "elasticsearch" ] } } }范围搜索 range query
gte：大于等于 gt：大于 lte：小于等于 lt：小于 boost：查询权重 GET /book/_search { "query": { "range": { "price": { "gte": 10, "lte": 200, "boost": 2 } } } } GET /book/_search { "query": { "range": { "timestamp": { "gte": "now-2d/d", "lt": "now/d" } } } } GET /book/_search { "query": { "range": { "timestamp": { "gte": "18/08/2020", "lte": "2021", "format": "dd/MM/yyyy||yyyy" } } } }不为空搜索 exists query
查询指定字段值不为空的文档。相当 SQL 中的 column is not null
GET /book/_search { "query": { "exists": { "field": "price" } } }词项前缀搜索 prefix query
GET /book/_search { "query": { "prefix": { "name": "so" } } }通配符搜索 wildcard query
GET /book/_search { "query": { "wildcard": { "name": "so*r" } } } GET /book/_search { "query": { "wildcard": { "name": { "value": "lu*", "boost": 2 } } } }正则搜索 regexp query
regexp允许使用正则表达式进行term查询.注意regexp如果使用不正确，会给服务器带来很严重的性能压力。比如.*开头的查询，将会匹配所有的倒排索引中的关键字，这几乎相当于全表扫描，会很慢。因此如果可以的话，最好在使用正则前，加上匹配的前缀
GET /book/_search { "query": { "regexp": { "name": "s.*" } } }模糊搜索 fuzzy query
GET /book/_search { "query": { "fuzzy": { "name": "so" } } } GET /book/_search { "query": { "fuzzy": { "name": { "value": "so", "boost": 1, "fuzziness": 2 } } } } GET /book/_search { "query": { "fuzzy": { "name": { "value": "sorl", "boost": 1, "fuzziness": 2 } } } }ids搜索
GET /book/_search { "query": { "ids": { "type": "_doc", "values": [ "1", "3" ] } } }
2.4 复合搜索 compound query
constant_score query
用来包装另一个查询，将查询匹配的文档的评分设为一个常值
GET /book/_search { "query": { "term": { "description": "solr" } } } GET /book/_search { "query": { "constant_score": { "filter": { "term": { "description": "solr" } }, "boost": 1.2 } } }布尔搜索 bool query
must：必须满足 filter：必须满足，但执行的是filter上下文，不参与、不影响评分 should：或 must_not：必须不满足，在filter上下文中执行，不参与、不影响评分 GET /book/_search { "query": { "bool": { "must": { "match": { "description": "java" } }, "filter": { "term": { "name": "solr" } }, "must_not": { "range": { "price": { "gte": 200, "lte": 300 } } }, "minimum_should_match": 1, "boost": 1 } } }minimum_should_match代表了最小匹配精度，如果设置minimum_should_match=1，那么should语句中至少需要有一个条件满足。
2.5 排序
相关性评分排序
默认情况下，返回的结果是按照 相关性 进行排序的——最相关的文档排在最前。 在本章的后面部分，我们会解释 相关性 意味着什么以及它是如何计算的， 不过让我们首先看看 sort 参数以及如何使用它。
为了按照相关性来排序，需要将相关性表示为一个数值。在 Elasticsearch 中， 相关性得分 由一个浮点数进行表示，并在搜索结果中通过 _score 参数返回， 默认排序是 _score 降序，按照相关性评分升序排序如下
POST /book/_search { "query": { "match": { "description": "solr" } } } POST /book/_search { "query": { "match": { "description": "solr" } }, "sort": [ { "_score": { "order": "asc" } } ] }字段值排序
POST /book/_search { "query": { "match_all": {} }, "sort": [ { "price": { "order": "desc" } } ] }多级排序
假定我们想要结合使用 price和 _score（得分） 进行查询，并且匹配的结果首先按照价格排序,然后按照相关性得分排序
GET /book/_search { "query": { "match_all": {} }, "sort": [ { "price": { "order": "desc" } }, { "_score": { "order": "desc" } } ] }
2.6 分页
Elasticsearch中实现分页的语法非常简单
GET /book/_search
{
"query": {
"match_all": {}
},
"size": 2,
"from": 0
}
GET /book/_search
{
"query": {
"match_all": {}
},
"sort": [
{
"price": {
"order": "desc"
}
}
],
"size": 2,
"from": 2
}
size:每页显示多少条
from:当前页起始索引, int start = (pageNum - 1) * size
2.7 高亮
GET /book/_search
{
"query": {
"match": {
"name": "elasticsearch"
}
},
"highlight": {
"pre_tags": "<font color='pink'>",
"post_tags": "</font>",
"fields": [
{
"name": {}
}
]
}
}
GET /book/_search
{
"query": {
"match": {
"name": "elasticsearch"
}
},
"highlight": {
"pre_tags": "<font color='pink'>",
"post_tags": "</font>",
"fields": [
{
"name": {}
},
{
"description": {}
}
]
}
}
GET /book/_search
{
"query": {
"query_string": {
"query": "elasticsearch"
}
},
"highlight": {
"pre_tags": "<font color='pink'>",
"post_tags": "</font>",
"fields": [
{
"name": {}
},
{
"description": {}
}
]
}
}
2.8 文档批量操作 bulk和mget
mget 批量查询
GET /_mget { "docs": [ { "_index": "book", "_id": 1 }, { "_index": "book", "_id": 2 } ] }同一索引下批量查询:
GET /book/_mget { "docs": [ { "_id": 2 }, { "_id": 3 } ] }简化写法:
GET /book/_search { "query": { "ids": { "values": [ "1", "4" ] } } }bulk批量增删改
Bulk 操作解释将文档的增删改查一些列操作，通过一次请求全都做完。减少网络传输次数
POST /_bulk {"action": {"metadata"}} {"data"}如下操作，删除1，新增5，修改2。
POST /_bulk { "delete": { "_index": "book", "_id": "1" }} { "create": { "_index": "book", "_id": "5" }} { "name": "test14","price":100.99 } { "update": { "_index": "book", "_id": "2"}} { "doc" : {"name" : "test"} }delete：删除一个文档，只要1个json串就可以了 删除的批量操作不需要请求体 create：相当于强制创建 PUT /index/type/id/_create index：普通的put操作，可以是创建文档，也可以是全量替换文档 update：执行的是局部更新partial update操作 格式：每个json不能换行。相邻json必须换行 隔离：每个操作互不影响。操作失败的行会返回其失败信息实际用法：bulk请求一次不要太大，否则一下积压到内存中，性能会下降。所以，一次请求几千个操作、大小在几M正好
一般建议是1000-5000个文档，大小建议是5-15MB，默认不能超过100M，可以在es的配置文件（ES的confifig下的elasticsearch.yml）中配置 http.max_content_length: 10mb
3. Filter DSL
Elasticsearch中的所有的查询都会触发相关度得分的计算。对于那些我们不需要相关度得分的场景下, Elasticsearch以过滤器的形式提供了另一种查询功能，过滤器在概念上类似于查询，但是它们有非常快的执行速度，执行速度快主要有以下两个原因：
过滤器不会计算相关度的得分，所以它们在计算上更快一些。
过滤器可以被缓存到内存中，这使得在重复的搜索查询上，其要比相应的查询快出许多。
为了理解过滤器，可以将一个查询（像是match_all，match，bool等）和一个过滤器结合起来。我们
以范围过滤器为例，它允许我们通过一个区间的值来过滤文档。这通常被用在数字和日期的过滤上。
下面这个例子使用一个被过滤的查询，其返回price值是在200到1000之间（闭区间）的书。
例:
GET /book/_search
{
"query": {
"filtered": {
"query": {
"match_all": {}
},
"filter": {
"range": {
"price": {
"gte": 200,
"lte": 1000
}
}
}
}
}
}
#5.0 之后的写法
GET /book/_search
{
"query": {
"bool": {
"must": {
"match_all": {}
},
"filter": {
"range": {
"price": {
"gte": 200,
"lte": 1000
}
}
}
}
}
}
4. 定位非法搜索及原因
在开发的时候，我们可能会写到上百行的查询语句，如果出错的话，找起来很麻烦，Elasticsearch提供了帮助开发人员定位不合法的查询的api _validate
GET /book/_search?explain
{
"query": {
"match1": {
"name": "test"
}
}
}
使用 validate
GET /book/_validate/query?explain
{
"query": {
"match1": {
"name": "test"
}
}
}
5. 聚合分析
5.1 聚合介绍
聚合分析是数据库中重要的功能特性，完成对一个查询的数据集中数据的聚合计算，如：找出某字段（或计算表达式的结果）的最大值、最小值，计算和、平均值等。Elasticsearch作为搜索引擎兼数据库，同样提供了强大的聚合分析能力
对一个数据集求最大、最小、和、平均值等指标的聚合，在ES中称为指标聚合metric,而关系型数据库中除了有聚合函数外，还可以对查询出的数据进行分组group by，再在组上进行指标聚合。在 ES 中group by 称为分桶，桶聚合 bucketing
Elasticsearch聚合分析语法
在查询请求体中以aggregations节点按如下语法定义聚合分析：
"aggregations" : {
"<aggregation_name>" : { <!--聚合的名字 -->
"<aggregation_type>" : { <!--聚合的类型 -->
<aggregation_body> <!--聚合体：对哪些字段进行聚合 -->
}
[,"meta" : { [<meta_data_body>] } ]? <!--元 -->
[,"aggregations" : { [<sub_aggregation>]+ } ]? <!--在聚合里面在定义子聚合 - ->
}
[,"<aggregation_name_2>" : { ... } ]*<!--聚合的名字 -->
}
**说明：**aggregations 也可简写为 aggs
5.2 指标聚合
max min sum avg
POST /book/_search { "query": { "range": { "price": { "gt": 100 } } } }文档计数 count
POST /book/_count { "query": { "range": { "price": { "gt": 100 } } } }value_count 统计某字段有值的文档数
POST /book/_search?size=0 { "aggs": { "price_count": { "value_count": { "field": "price" } } } }cardinality值去重计数 基数
POST /book/_search?size=0 { "aggs": { "_id_count": { "cardinality": { "field": "_id" } }, "price_count": { "cardinality": { "field": "price" } } } }stats 统计 count max min avg sum 5个值
POST /book/_search?size=0 { "aggs": { "price_stats": { "stats": { "field": "price" } } } }Extended stats
高级统计，比stats多4个统计结果： 平方和、方差、标准差、平均值加/减两个标准差的区间
POST /book/_search?size=0 { "aggs": { "price_stats": { "extended_stats": { "field": "price" } } } }Percentiles 占比百分位对应的值统计
POST /book/_search?size=0 { "aggs": { "price_percents": { "percentiles": { "field": "price" } } } }指定分位值
POST /book/_search?size=0 { "aggs": { "price_percents": { "percentiles": { "field": "price", "percents": [ 75, 99, 99.9 ] } } } }Percentiles rank 统计值小于等于指定值的文档占比
统计price小于100和200的文档的占比
POST /book/_search?size=0 { "aggs": { "gge_perc_rank": { "percentile_ranks": { "field": "price", "values": [ 100, 200 ] } } } }
5.3 桶聚合
它执行的是对文档分组的操作（与sql中的group by类似），把满足相关特性的文档分到一个桶里，即桶分，输出结果往往是一个个包含多个文档的桶（一个桶就是一个group）
bucket：一个数据分组
metric：对一个数据分组执行的统计
POST /book/_search?size=0
{
"size": 0,
"aggs": {
"group_by_price": {
"range": {
"field": "price",
"ranges": [
{
"from": 0,
"to": 200
},
{
"from": 200,
"to": 400
},
{
"from": 400,
"to": 1000
}
]
},
"aggs": {
"average_price": {
"avg": {
"field": "price"
}
}
}
}
}
}
值的个数统计
"count_price": { "value_count": { "field": "price" } }
实现having 效果
POST /book/_search?size=0
{
"size": 0,
"aggs": {
"group_by_price": {
"range": {
"field": "price",
"ranges": [
{
"from": 0,
"to": 200
},
{
"from": 200,
"to": 400
},
{
"from": 400,
"to": 1000
}
]
},
"aggs": {
"average_price": {
"avg": {
"field": "price"
}
},
"having": {
"bucket_selector": {
"buckets_path": {
"avg_price": "average_price"
},
"script": {
"source": "params.avg_price >= 200 "
}
}
}
}
}
}
}
6. 零停机索引重建
Elasticsearch是一个实时的分布式搜索引擎，为用户提供搜索服务，当我们决定存储某种数据时，在创建索引的时候需要数据结构完整确定下来，与此同时索引的设定和很多固定配置将不能改变。当需要改变数据结构时就需要重建索引，为此，Elasticsearch团队提供了辅助工具帮助开发人员进行索引重建
6.1 方案1 外部数据导入方案
系统架构设计中，有关系型数据库用来存储数据，Elasticsearch在系统架构里起到查询加速的作用，如果遇到索引重建的操作，待系统模块发布新版本后，可以从数据库将数据查询出来，重新灌到Elasticsearch即可
执行步骤:
建议的功能方案：数据库 + MQ + 应用模块 + Elasticsearch，可以在MQ控制台发送MQ消息来触发重导数据，按批次对数据进行导入，整个过程异步化处理，请求操作示意如下所示：
1. 通过MQ的web控制台或cli命令行，发送指定的MQ消息
2. MQ消息被微服务模块的消费者消费，触发ES数据重新导入功能
3. 微服务模块从数据库里查询数据的总数及批次信息，并将每个数据批次的分页信息重新发送给MQ
消息，分页信息包含查询条件和偏移量，此MQ消息还是会被微服务的MQ消息者接收处理。
4. 微服务根据接收的查询条件和分页信息，从数据库获取到数据后，根据索引结构的定义，将数据组
装成ES支持的JSON格式，并执行bulk命令，将数据发送给Elasticsearch集群。
这样就可以完成索引的重建工作。
方案特点
MQ中间件的选型不做具体要求，常见的rabitmq、activemq、rocketmq等均可。
在微服务模块方面，提供MQ消息处理接口、数据处理模块需要事先开发的，一般是创建新的索引时，
配套把重建的功能也一起做好。整体功能共用一个topic，针对每个索引，有单独的结构定义和MQ消息
处理tag，代码尽可能复用。处理的批次大小需要根据实际的情况设置。
微服务模块实例会部署多个，数据是分批处理的，批次信息会一次性全部先发送给MQ，各个实例处理
的数据相互不重叠，利用MQ消息的异步处理机制，可以充分利用并发的优势，加快数据重建的速度。
方案缺点
1. 对数据库造成读取压力，短时间内大量的读操作，会占用数据库的硬件资源，严重时可能引起数据
库性能下降。
2. 网络带宽占用多，数据毕竟是从一个库传到另一个库，虽说是内网，但大量的数据传输带宽占用也
需要注意。
3. 数据重建时间稍长，跟迁移的数据量大小有关。
6.2 方案2 基于scroll+bulk+索引别名方案
利用Elasticsearch自带的一些工具完成索引的重建工作，当然在方案实际落地时，可能也会依赖客户端的一些功能，比如用Java客户端持续的做scroll查询、bulk命令的封装等。数据完全自给自足，不依赖其他数据源
执行步骤:
假设原索引名称是book，新的索引名称为book_new，Java客户端使用别名book_alias连接Elasticsearch，该别名指向原索引book。
1. 若Java客户端没有使用别名，需要给客户端分配一个: PUT /book/_alias/book_alias
2. 新建索引book_new，将mapping信息，settings信息等按新的要求全部定义好。
3. 使用scroll api将数据批量查询出来
为了使用 scroll，初始搜索请求应该在查询中指定 scroll 参数，这可以告诉 Elasticsearch 需要
保持搜索的上下文环境多久,1m 就是一分钟。
GET /book/_search?scroll=1m
{ "query": { "match_all": {} },"sort": ["_doc"], "size": 2 }
4.采用bulk api将scoll查出来的一批数据，批量写入新索引
POST /_bulk
{ "index": { "_index": "book_new", "_id": "对应的id值" }}
{ 查询出来的数据值 }
5. 反复执行修改后的步骤3和步骤4，查询一批导入一批，以后可以借助Java Client或其他语言的API
支持
注意做3时需要指定上一次查询的 scroll_id
GET /_search/scroll
{ "scroll": "1m", "scroll_id" : "步骤三中查询出来的值" }
6. 切换别名book_alias到新的索引book_new上面，此时Java客户端仍然使用别名访问，也不需要修
改任何代码，不需要停机
POST /_aliases
{
"actions": [
{
"remove": {
"index": "book",
"alias": "book_alias"
}
},
{
"add": {
"index": "book_new",
"alias": "book_alias"
}
}
]
}
7. 验证别名查询的是否为新索引的数据
方案特点
在数据传输上基本自给自足，不依赖于其他数据源，Java客户端不需要停机等待数据迁移，网络传输占
用带宽较小。只是scroll查询和bulk提交这部分，数据量大时需要依赖一些客户端工具。
在Java客户端或其他客户端访问Elasticsearch集群时，使用别名是一个好习惯
6.3 方案3 Reindex API方案
Elasticsearch v6.3.1已经支持Reindex API，它对scroll、bulk做了一层封装，能够 对文档重建索引而不需要任何插件或外部工具
最基础的命令
POST _reindex { "source": { "index": "book" }, "dest": { "index": "book_new" } } 响应结果 { "took":180, "timed_out":false, "total":4, "updated":0, "created":4, "deleted":0, "batches":1, "version_conflicts":0, "noops":0, "retries":{ "bulk":0, "search":0 }, "throttled_millis":0, "requests_per_second":-1, "throttled_until_millis":0, "failures":[ ] }注意： 如果不手动创建新索引book_new的mapping信息，那么Elasticsearch将启动自动映射模板对数据进行类型映射，可能不是期望的类型，这点要注意一下
version_type属性
使用reindex api也是创建快照后再执行迁移的，这样目标索引的数据可能会与原索引有差异，version_type属性可以决定乐观锁并发处理的规则。
reindex api可以设置version_type属性，如下：
POST _reindex { "source": { "index": "book" }, "dest": { "index": "book_new", "version_type": "internal" } }version_type属性含义如下： internal：直接拷贝文档到目标索引，对相同的type、文档ID直接进行覆盖，默认值 external：迁移文档到目标索引时，保留version信息，对目标索引中不存在的文档进行创建，已 存在的文档按version进行更新，遵循乐观锁机制。op_type属性和colicts属性
如果op_type设置为create，那么迁移时只在目标索引中创建ID不存在的文档，已存在的文档，会提示错误，如下请求：
POST _reindex { "source": { "index": "book" }, "dest": { "index": "book_new", "op_type": "create" } } 有错误提示的响应，节选部分： { "took":11, "timed_out":false, "total":5, "updated":0, "created":1, "deleted":0, "batches":1, "version_conflicts":4, "noops":0, "retries":{ "bulk":0, "search":0 }, "throttled_millis":0, "requests_per_second":-1, "throttled_until_millis":0, "failures":[ { "index":"book_new", "type":"children", "id":"2", "cause":{ "type":"version_conflict_engine_exception", "reason":"[children][2]: version conflict, document already exists (current version [17])", "index_uuid":"dODetUbATTaRL-p8DAEzdA", "shard":"2", "index":"book_new" }, "status":409 } ] }如果加上"conflflicts": “proceed"配置项，那么冲突信息将不展示，只展示冲突的文档数量，请求和响应结果将变成这样：
POST _reindex { "conflicts": "proceed", "source": { "index": "book" }, "dest": { "index": "book_new", "op_type": "create" } } 响应 { "took":12, "timed_out":false, "total":5, "updated":0, "created":1, "deleted":0, "batches":1, "version_conflicts":4, "noops":0, "retries":{ "bulk":0, "search":0 }, "throttled_millis":0, "requests_per_second":-1, "throttled_until_millis":0, "failures":[ ] }query支持
reindex api支持数据过滤、数据排序、size设置、_source选择等，也支持脚本执行，这里提供一个简单示例：
POST _reindex { "size":100, "source":{ "index":"book", "query":{ "term":{ "language":"english" } }, "sort":{ "likes":"desc" } }, "dest":{ "index":"book_new" } }零停机索引重建操作的三个方案，从自研功能、scroll+bulk到reindex，我们作为Elasticsearch的使用者，三个方案的参与度是逐渐弱化的，但稳定性却是逐渐上升的，我们需要清楚地去了解各个方案的优劣，适宜的场景，然后根据实际的情况去权衡，哪个方案更适合我们的业务模型.
7. Suggester智能搜索建议
现代的搜索引擎，一般会具备"Suggest As You Type"功能，即在用户输入搜索的过程中，进行自动补全或者纠错。 通过协助用户输入更精准的关键词，提高后续全文搜索阶段文档匹配的程度。例如在京东上输入部分关键词，甚至输入拼写错误的关键词时，它依然能够提示出用户想要输入的内容.
如果自己亲手去试一下，可以看到京东在用户刚开始输入的时候是自动补全的，而当输入到一定长度，如果因为单词拼写错误无法补全，就开始尝试提示相似的词。
那么类似的功能在Elasticsearch里如何实现呢？
答案就在Suggesters API。 Suggesters基本的运作原
理是将输入的文本分解为token，然后在索引的字典里查找相似的term并返回。 根据使用场景的不同，
Elasticsearch里设计了4种类别的Suggester，分别是:
Term Suggester
Phrase Suggester
Completion Suggester
Context Suggester
示例:
Term Suggester
PUT /blogs/
{
"mappings": {
"properties": {
"body": {
"type": "text"
}
}
}
}
通过bulk api写入几条文档
POST _bulk/?refresh=true
{"index":{"_index":"blogs"}}
{"body":"Lucene is cool"}
{"index":{"_index":"blogs"}}
{"body":"Elasticsearch builds on top of lucene"}
{"index":{"_index":"blogs"}}
{"body":"Elasticsearch rocks"}
{"index":{"_index":"blogs"}}
{"body":"Elastic is the company behind ELK stack"}
{"index":{"_index":"blogs"}}
{"body":"elk rocks"}
{"index":{"_index":"blogs"}}
{"body":"elasticsearch is rock solid"}
此时blogs索引里已经有一些文档了，可以进行下一步的探索。为帮助理解，我们先看看哪些term会存在于词典里
将输入的文本分析一下:
POST _analyze
{
"text": [
"Lucene is cool",
"Elasticsearch builds on top of lucene",
"Elasticsearch rocks",
"Elastic is the company behind ELK stack",
"elk rocks",
"elasticsearch is rock solid"
]
}
这些分出来的token都会成为词典里一个term，注意有些token会出现多次，因此在倒排索引里记录的词频会比较高，同时记录的还有这些token在原文档里的偏移量和相对位置信息。
执行一次suggester搜索看看效果:
POST /blogs/_search
{
"suggest": {
"my-suggestion": {
"text": "lucne rock",
"term": {
"suggest_mode": "missing",
"field": "body"
}
}
}
}
suggest就是一种特殊类型的搜索，DSL内部的"text"指的是api调用方提供的文本，也就是通常用户界面上用户输入的内容。这里的lucne是错误的拼写，模拟用户输入错误。 “term"表示这是一个term suggester。 “field"指定suggester针对的字段，另外有一个可选的"suggest_mode”。范例里的"missing"实际上就是缺省值, 先看看返回结果 :
{
"took" : 2,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 0,
"relation" : "eq"
},
"max_score" : null,
"hits" : [ ]
},
"suggest" : {
"my-suggestion" : [
{
"text" : "lucne",
"offset" : 0,
"length" : 5,
"options" : [
{
"text" : "lucene",
"score" : 0.8,
"freq" : 2
}
]
},
{
"text" : "rock",
"offset" : 6,
"length" : 4,
"options" : [ ]
}
]
}
}
在返回结果里"suggest” -> “my-suggestion"部分包含了一个数组，每个数组项对应从输入文本分解出来的token（存放在"text"这个key里）以及为该token提供的建议词项（存放在options数组里)。 示例里返回了"lucne”，“rock"这2个词的建议项(options)，其中"rock"的options是空的，表示没有可以建议的选项，为什么？
上面提到了，我们为查询提供的suggest mode是"missing”,由于"rock"在索引的词典里已经存在了，够精准，就不建议啦。 只有词典里找不到词，才会为其提供相似的选项。
如果将"suggest_mode"换成”popular“会是什么效果？重新执行查询，返回结果里"rock"这个词的option不再是空的，而是建议为rocks。
{
"took" : 3,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 0,
"relation" : "eq"
},
"max_score" : null,
"hits" : [ ]
},
"suggest" : {
"my-suggestion" : [
{
"text" : "lucne",
"offset" : 0,
"length" : 5,
"options" : [
{
"text" : "lucene",
"score" : 0.8,
"freq" : 2
}
]
},
{
"text" : "rock",
"offset" : 6,
"length" : 4,
"options" : [
{
"text" : "rocks",
"score" : 0.75,
"freq" : 2
}
]
}
]
}
}
回想一下，rock和rocks在索引词典里都是有的。 不难看出即使用户输入的token在索引的词典里已经有了，但是因为存在一个词频更高的相似项，这个相似项可能是更合适的，就被挑选到options里了。最后还有一个"always” mode，其含义是不管token是否存在于索引词典里都要给出相似项。有人可能会问，两个term的相似性是如何判断的？ ES使用了一种叫做Levenstein edit distance的算法，其核心思想就是一个词改动多少个字符就可以和另外一个词一致。 Term suggester还有其他很多可选参数来控制这个相似性的模糊程度，这里就不一一赘述了。
Phrase Suggester
Phrase suggester在Term suggester的基础上，会考量多个term之间的关系，比如是否同时出现在引的原文里，相邻程度，以及词频等等。看个范例就比较容易明白了:
POST /blogs/_search
{
"suggest": {
"my-suggestion": {
"text": "lucne and elasticsear rock",
"phrase": {
"field": "body",
"highlight": {
"pre_tag": "<em>",
"post_tag": "</em>"
}
}
}
}
}
返回结果 :
{
"took" : 17,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 0,
"relation" : "eq"
},
"max_score" : null,
"hits" : [ ]
},
"suggest" : {
"my-suggestion" : [
{
"text" : "lucne and elasticsear rock",
"offset" : 0,
"length" : 26,
"options" : [
{
"text" : "lucene and elasticsearch rock",
"highlighted" : "<em>lucene</em> and <em>elasticsearch</em> rock",
"score" : 0.004993905
},
{
"text" : "lucne and elasticsearch rock",
"highlighted" : "lucne and <em>elasticsearch</em> rock",
"score" : 0.0033391973
},
{
"text" : "lucene and elasticsear rock",
"highlighted" : "<em>lucene</em> and elasticsear rock",
"score" : 0.0029183894
}
]
}
]
}
}
options直接返回一个phrase列表，由于加了highlight选项，被替换的term会被高亮。因为lucene和elasticsearch曾经在同一条原文里出现过，同时替换2个term的可信度更高，所以打分较高，排在第一位返回。Phrase suggester有相当多的参数用于控制匹配的模糊程度，需要根据实际应用情况去挑选和调试。
Completion Suggester
它主要针对的应用场景就是"Auto Completion"。 此场景下用户每输入一个字符的时候，就需要即时发送一次查询请求到后端查找匹配项，在用户输入速度较高的情况下对后端响应速度要求比较苛刻。因此实现上它和前面两个Suggester采用了不同的数据结构，索引并非通过倒排来完成，而是将analyze过的数据编码成FST和索引一起存放。对于一个open状态的索引，FST会被ES整个装载到内存里的，进行前缀查找速度极快。但是FST只能用于前缀查找，这也是Completion Suggester的局限所在。
为了使用Completion Suggester，字段的类型需要专门定义如下:
PUT /blogs_completion/
{
"mappings": {
"properties": {
"body": {
"type": "completion"
}
}
}
}
用bulk API索引点数据:
POST _bulk/?refresh=true
{"index":{"_index":"blogs_completion"}}
{"body":"Lucene is cool"}
{"index":{"_index":"blogs_completion"}}
{"body":"Elasticsearch builds on top of lucene"}
{"index":{"_index":"blogs_completion"}}
{"body":"Elasticsearch rocks"}
{"index":{"_index":"blogs_completion"}}
{"body":"Elastic is the company behind ELK stack"}
{"index":{"_index":"blogs_completion"}}
{"body":"the elk stack rocks"}
{"index":{"_index":"blogs_completion"}}
{"body":"elasticsearch is rock solid"}
查询:
POST /blogs_completion/_search?pretty
{
"size": 0,
"suggest": {
"blog-suggest": {
"prefix": "elastic i",
"completion": {
"field": "body"
}
}
}
}
返回结果 :
{
"took" : 44,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 0,
"relation" : "eq"
},
"max_score" : null,
"hits" : [ ]
},
"suggest" : {
"blog-suggest" : [
{
"text" : "elastic i",
"offset" : 0,
"length" : 9,
"options" : [
{
"text" : "Elastic is the company behind ELK stack",
"_index" : "blogs_completion",
"_type" : "_doc",
"_id" : "nOBTzYEBO-8MqYNj66QS",
"_score" : 1.0,
"_source" : {
"body" : "Elastic is the company behind ELK stack"
}
}
]
}
]
}
}
值得注意的一点是Completion Suggester在索引原始数据的时候也要经过analyze阶段，取决于选用的analyzer不同，某些词可能会被转换，某些词可能被去除，这些会影响FST编码结果，也会影响查找匹配的效果。
比如我们删除上面的索引，重新设置索引的mapping，将analyzer更改为"english", 再查找 , 发现居然没有匹配结果了，多么费解！ 原来我们用的english analyzer会剥离掉stop word，而is就是其中一个，被剥离掉了！
其他能影响completion suggester结果的，还有如"preserve_separators"，“preserve_position_increments"等等mapping参数来控制匹配的模糊程度。以及搜索时可以选用Fuzzy Queries，使得上面例子里的"elastic i"在使用english analyzer的情况下依然可以匹配到结果。
"preserve_separators": false, 这个设置为false,将忽略空格之类的分隔符 "preserve_position_increments": true,如果建议词第一个词是停用词,并且我们使用了过滤停用 词的分析器,需要将此设置为false。
因此用好Completion Sugester并不是一件容易的事，实际应用开发过程中，需要根据数据特性和业务需要，灵活搭配analyzer和mapping参数，反复调试才可能获得理想的补全效果
回到篇首京东或者百度搜索框的补全/纠错功能，如果用ES怎么实现呢？我能想到的一个的实现方式:
在用户刚开始输入的过程中，使用Completion Suggester进行关键词前缀匹配，刚开始匹配项会比较
多，随着用户输入字符增多，匹配项越来越少。如果用户输入比较精准，可能Completion Suggester的
结果已经够好，用户已经可以看到理想的备选项了。
如果Completion Suggester已经到了零匹配，那么可以猜测是否用户有输入错误，这时候可以尝试一下
Phrase Suggester。如果Phrase Suggester没有找到任何option，开始尝试term Suggester。
精准程度上(Precision)看： Completion > Phrase > term， 而召回率上(Recall)则反之。从性能上看，
Completion Suggester是最快的，如果能满足业务需求，只用Completion Suggester做前缀匹配是最
理想的。 Phrase和Term由于是做倒排索引的搜索，相比较而言性能应该要低不少，应尽量控制
suggester用到的索引的数据量，最理想的状况是经过一定时间预热后，索引可以全量map到内存。
召回率(Recall) = 系统检索到的相关文件 / 系统所有相关的文件总数
准确率(Precision) = 系统检索到的相关文件 / 系统所有检索到的文件总数
从一个大规模数据集合中检索文档时，可把文档分成四组：
- 系统检索到的相关文档（A）
- 系统检索到的不相关文档（B）
- 相关但是系统没有检索到的文档（C）
- 不相关且没有被系统检索到的文档（D）
则：
- 召回率R：用实际检索到相关文档数作为分子，所有相关文档总数作为分母，即R = A / ( A + C )
- 精度P：用实际检索到相关文档数作为分子，所有检索到的文档总数作为分母，即P = A / ( A + B )
举例：一个数据库有 1000 个文档，其中有 50 个文档符合相关定义的问题,系统检索到 75 个文档，但 其中只有 45 个文档被检索出。 精度：P=45/75=60%。 召回率：R=45/50=90%。
Context Suggester
Completion Suggester 的扩展
可以在搜索中加入更多的上下文信息，然后根据不同的上下文信息，对相同的输入，比如"star"，
提供不同的建议值，比如：
咖啡相关：starbucks
电影相关：star wars
8. Java Client
ES提供多种不同的客户端：
- TransportClient ES提供的传统客户端，官方计划8.0版本删除此客户端。
- RestClient RestClient是官方推荐使用的，它包括两种：Java Low Level REST Client和 Java High Level REST Client。 ES在6.0之后提供 Java High Level REST Client， 两种客户端官方更推荐使用 JavaHigh Level REST Client， 使用时加入对应版本的依赖即可
Springboot中使用 RestClient
示例代码: springboot-restclient