elasticsearch数据检索和分析

导入kibana里面的范例数据

_search 接口

        所有的rest搜索请求使用_search接口，可以是get请求，也可以是post请求，还可以通过在搜索url中指定索引来限制范围。
_search接口有两种请求方法，一种是基于uri的请求方式，另一种是基于请求体的方式，无论哪种，语法都是基于DSL的(DSL是一种基于json的查询语言)。我选择基于请求体的方式来学习。

        query—是搜索请求中最重要的组成部分，它配置了基于评分返回的最佳文档，也包括我们不希望返回的那些文档。
        size—代表了返回文档的数量。
        from—和size一起使用，from用于分页操作。需要主要的是，为了确定第2页的10项结果，elasticsearch必须要计算前20个结果。如果结果集合不断增加，获取某些靠后的翻页将会成为代价高昂的操作。
        _source—指定_source字段如何返回，默认是返回完整的_source字段。通过配置_source，将过滤返回的字段。如果索引的文档很大，而且无须结果中的全部内容，就可以使用这个功能。如果想要使用它，切记不能再索引映射中关闭_source字段。
        sort—默认的排序是基于文档的得分。如果并不关心得分，或者期望许多文档的得分相同，添加额外的sort将帮助我们控制哪些文档被返回。

例 1：

get kibana_sample_data_flights/_search 
{ 
	"from":100, 
	"size":20, 
	"query":{ 
		"term":{ 
			"DestCountry":"CN" 
		} 
	} 
}

这个语句是查询DestCountry为CN 100条后面的 101到120的数据

例 2：

get kibana_sample_data_flights/_search
{ 
	"from":80, 
 	"size":20, 
    "query":{ 
   		"match_all":{}
  	},
  "_source":["Origin*","*Weather"],
  "sort":[
    {"DistanceKilometers":"asc"},
    {"FlightNum":"desc"}
  ]
}

根据索引查询数据 查询100条后的 81到100 的数据 根据DistanceKilometers升序 FlightNum降序

注意: from 与 size 的和不能超过 index. max_result_window 这个索引配置项设置的值。默认情况下这个配置项的值为 10000,所以如果要查询 10000 条以 后的文档，就必须要增加这个配置值。否则会抛出类似“ Result window is too large’的异常。

例 3：

元字段_source 中存储了文档的原始数据。如果请求中没有指定_source，Elasticsearch 默认返回整个_ source， 或者如果_ source 没有存储，那么就只返回匹配文档的元数据:_ id、_type、_index 和_score。

get kibana_sample_data_flights/_search 
{ 
	"query":{ 
		"match_all":{} 
	},
	"_source":["OriginCountry","DestCountry"] 
}

例 4：

我们不仅可以返回字段列表,还可以指定通配符。例如,如果想同时返回" DestCountry “和” DestWeather “字段，可以这样配置_ source: “Dest*”。 也可以使用通配字符串的数组来指定多个通配符，例如_ source:[” Origin*", "* Weather "]。

get kibana_sample_data_flights/_search 
{ 
	"query":{ 
		"match_all":{} 
	},
	"_source":["Origin*","*Weather"] 
}

例 5：

不仅可以指定哪些字段需要返回，还可以指定哪些字段无须返回

get kibana_sample_data_flights/_search 
{ 
	"_source":{ 
	"includes":["*.lon","*.lat"], 
	"excludes":"DestLocation.*" 
	} 
} 

检索

目前为止所进行的几乎所有搜索请求虽然有些条件限制，但是限制条件主要是在规定 ES 返回的查询结果中哪些字段返回，哪些字段不返回，对于哪些文档返回，哪些文档不返回，其实没有多少约束。真正如何更精确的找到我们需要的文档呢？这就需要我们需要使用带条件的搜索，主要包括两类，基于词项的搜索和基于全文的搜索。

内置分词器

字符过滤器

字符过滤器种类不多。elasticearch 只提供了三种字符过滤器

HTML字符过滤器(HTML Strip Char Filter)

从文本中去出HTML元素

POST _analyze
{ 
	  "tokenizer": "keyword",
	  "char_filter": ["html_strip"],
	  "text":"<p>I&apos;m so <b>happy</b>!</p>" 
}

映射字符过滤器(Mapping Char Filter)

接收键值的映射，每当遇到与键相同的字符串时，它就用该键关联的值替换它们。

PUT pattern_wsh
{ 
  "settings": { 
    "analysis": { 
      "analyzer": { 
        "my_analyzer":{ 
          "tokenizer":"keyword", 
          "char_filter":["wsh_test_filter"]
        } 
      },
      "char_filter":{
        "wsh_test_filter":{ 
          "type":"mapping", 
          "mappings":["wlf => wsh"] 
        }
      } 
    } 
  } 
}

这里我们自定义一个分析器，char_filter 里定义了一个wsh_test_filter映射字符过滤器 把wlf过滤成wsh ，分词器使用关键字分词器。

测试结果：

模式替换过滤器(Pattern Replace Char Filter)

使用正则表达式匹配并替换字符串中的字符。糟糕的正则表达式可能导致性能变慢。

PUT pattern_wsh2
{ 
  "settings": { 
    "analysis": { 
      "analyzer": { 
        "my_analyzer": { 
          "tokenizer": "standard", 
          "char_filter": [ "wsh_filter_pattern_replace" ]
        } 
      },
      "char_filter": {
        "wsh_filter_pattern_replace": { 
          "type": "pattern_replace", 
          "pattern": "(\\d+)-(?=\\d)",
          "replacement": "$1_" 
        }
      } 
    }
  } 
}

自定义一个分析器，char_filter 里定义了一个wsh_filter_pattern_replace模式替换过滤器
将正匹表达式匹配到的内容替换为_

测试结果：

分词器（Tokenizer）

标准分词器(standard)

标准分词器( standard tokenizer) 是一个基于语法的分词器，对于大多数欧洲语言来说是不错的。它还处理了Unicode文本的切分。它也移除了逗号和句号这样的标点符号。
“I have, potatoes.”切分后的分词分别是” I” 、” have” 和” potatoes”。

关键词分词器(keyword)

关键词分词器( keyword tokenizer )是- -种简单的分词器，将整个文本作为单个的分词，提供给分词过滤器。只想应用分词过滤器，而不做任何分词操作时，它可能非常有用。
‘Hi, there.’ 唯一的分词是 Hi, there。

字母分词器(letter)

字母分词器根据非字母的符号,将文本切分成分词。例如，对于句子“Hi,there."分词是Hi和 there,因为逗号、空格和句号都不是字母:
'Hi, there. '分词是 Hi 和 there。

小写分词器(lowercase)

小写分词器( lowercase tokenizer)结合了常规的字母分词器和小写分词过滤器(如你所想，它将整个分词转化为小写)的行为。通过 1 个单独的分词器来实现的主要原因是，2 次进行两项操作会获得更好的性能。
'Hi, there.'分词是 hi

空白分词器(whitespace)

空白分词器( whitespace tokenizer )通过空白来分隔不同的分词，空白包括空
格、制表符、换行等。请注意，这种分词器不会删除任何标点符号，所以文本“Hi,
there." 的分词.
'Hi， there. '分词是 Hi,和 there.。

模式分词器(pattern)

模式分词器( patterm tokenizer)允许指定一个任意的模式，将文本切分为分词。被指定的模式应该匹配间隔符号。例如，可以创建一个定制分析器，它在出现文本“. -.”的地方将分词断开。

UAX URL 电子邮件分词器(uax_url_email)

在处理英语单词的时候，标准分词器是非常好的选择。但是，当下存在不少以网站地址和电子邮件地址结束的文本。标准分析器可能在你未注意的地方对其进行了切分。例如，有一个电子邮件地址的样本 john.smith@example.com,用标准分词器分析它，切分后:
‘john.smith@example.com’ 分词是 john.smith 和 example.com。
它同样将 URL 切分为不同的部分:
'http://example. com?q=foo’分词是 http、example.com、q 和 foo。
UAX URL 电子邮件分词器( UAX URL email tokenizer )将电子邮件和URL都作为单独的分词进行保留。

路径层次分词器(path_hierarchy)

路径层次分词器( path hierarchy tokenizer )允许以特定的方式索引文件系统的路径，这样在搜索时，共享同样路径的文件将被作为结果返回。例如，假设有一个文件名想要索引，看上去是这样的(ustl0oal/var/log/elasticsearch.log。路径层次分词器将其切分为:
’ /usr/local/var/1og/elasticsearch. log’
分词是/usr、/usr/local、/usr/local/var、/usr/local/var/ log 和
/usr/local/var/ log/elasticsearch.1og。
这意味着，一个用户查询时，和上述文件共享同样路径层次(名字也是如此) 的文件也会被匹配上。查询“/usr/local/var/log/es.log" 时，它和 “/usr/local/var/log/elasticsearch.log" 拥有同样的分词，因此它也会被作为结果返回。

分词过滤器（Token filters）

标准分词过滤器（standard）

不要认为标准分词过滤器( standard token filter )进行了什么复杂的计算，实际上它什么事情也没做。

小写分词过滤器（lowercase）

小写分词过滤器( lowercase token filter)只是做了这件事:将任何经过的分词转换为小写。这应该非常简单也易于理解。

长度分词过滤器（length）

长度分词过滤器(length token filter)将长度超出最短和最长限制范围的单词过滤掉。举个例子，如果将 min 设置为 2，并将 max 设置为 8，任何小于 2 个字符和任何大于 8 个字符的分词将会被移除。

停用词分词过滤器（stop）

停用词分词过滤器(stop token fite)将停用词从分词流中移除。对于英文而言，这意味着停用词列表中的所有分词都将会被完全移除。用户也可以为这个过滤器指定-个待移除单词的列表。
停用词是指在信息检索中，为节省存储空间和提高搜索效率，在处理自然语言数据（或文本）之前或之后会自动过滤掉某些字或词，这些字或词即被称为Stop Words（停用词）。
可以被分为两大类:
1、使用十分广泛，过于频繁的一些单词。 the、is、what之类。
2、文本中出现频率很高，但实际意义又不大的词。

截断分词过滤器、修剪分词过滤器和限制分词数量过滤器

下面 3 个分词过滤器，通过某种方式限制分词流。
■截断分词过滤器( truncate token filter )允许你通过定制配置中的 length 参数，截断超过一定长度的分词。默认截断多于 10 个字符的部分。
■修剪分词过滤器( trim token filter )删除 1 个分词中的所有空白部分。例如，分词" foo "将被转变为分词 foo。
■限制分词数量分词过滤器(limit token count token filter)限制了某个字段可包含分词的最大数量。例如，如果创建了一个定制的分词数量过滤器，限制是 8, 那么分词流中只有前 8 个分词会被索引。这个设置使用 max_ token_ count 参数， 默认是 1 (只有 1 个分词会被索引)。

常用内置分析器

标准分析器

当没有指定分析器的时候，标准分析器( standardanalyzer)是文本的默认分析 器。它综合了对大多欧洲语言来说合理的默认模块，它没有字符过滤器，包括标准分词器、小写转换分词过滤器和停用词分词过滤器（默认为_none_，也就是不去除停止词）。如果不为某个字段指定分析器，那么该字段就会使用标准分析器。
可配置的参数如下：
max_token_length，默认值 255，表示词项最大长度，超过这个长度将按该长度分为多个词项。
stopwords，默认值_none_，表示分析器使用的停止词数组，可使用内置停止词列表，比如_english_等。
stopwords_path 停止词文件路径。

简单分析器

简单分析器( simple analyzer)只使用了小写转换分词器，这意味着在非字母处进行分词，并将分词自动转变为小写。这个分析器对于亚洲语言来说效果不佳，因为亚洲语言不是根据空白来分词，所以应该仅仅针对欧洲语言使用它。

空白分析器

空白分析器( whitespace analyzer )什么事情都不做,只是根据空白将文本切分为若干分词。

停用词分析器

停用词分析器( stop analyzer )和简单分析器的行为很相像，只是在分词流中额外地过滤了停用词。

关键词分析器

关键词分析器( keyword analyzer )将整个字段当作一个单独的分词。

模式分析器

模板分析器( pattern analyzer )允许你指定一个分词切分的模式。 但是，由于可能无论如何都要指定模式，通常更有意义的做法是使用定制分析器，组合现有的模式分词器和所需的分词过滤器。

雪球分析器

雪球分析器( snowball analyzer )除了使用标准的分词器和分词过滤器(和标准分析器一样),也使用了小写分词过滤器和停用词过滤器。它还使用了雪球词干器对文本进行词干提取。

自定义分析器

在analysis下的相应位置设置字符过滤器、分词器和分词过滤器

PUT /wsh_test
{
    "settings": {
        "analysis": {
            "char_filter": { custom character filters },
            "tokenizer":   { custom tokenizers },
            "filter":      { custom token filters },
            "analyzer":    { custom analyzers }
        }
    }
}

①.使用html清除字符过滤器移除html部分。
②.使用一个自定义的映射字符过滤器把&替换为“and”。

"char_filter": {
    "&_to_and": {
        "type":       "mapping",
        "mappings": [ "&=> and "]
     }
  }

③.使用标准分词器分词。
④.小写词条，使用小写词过滤器处理。
⑤.使用自定义停止词过滤器移除自定义的停止词列表中包含的词。

"filter": {
    "my_stopwords": {
        "type":        "stop",
        "stopwords": [ "the", "a" ]
    }
  }

自定义停止词the 、a

我们的分析器定义用我们之前已经设置好的自定义过滤器组合了已经定义好的分词器和过滤器：

"analyzer": {
  "my_analyzer": {
      "type":           "custom",
      "char_filter":  [ "html_strip", "&_to_and" ],
      "tokenizer":      "standard",
      "filter":       [ "lowercase", "my_stopwords" ]
  }
}

自定义分析器 type 固定写 custom

汇总后

PUT /wsh_test
{
  "settings": {
      "analysis": {
          "char_filter": {
              "&_to_and": {
                  "type":       "mapping",
                  "mappings": [ "&=> and "]
              }
           },
          "filter": {
              "my_stopwords": {
                  "type":       "stop",
                  "stopwords": [ "the", "a" ]
            }
          },
          "analyzer": {
              "my_analyzer": {
                  "type":         "custom",
                  "char_filter":  [ "html_strip", "&_to_and" ],
                  "tokenizer":    "standard",
                  "filter":       [ "lowercase", "my_stopwords" ]
            }
          }
    }
  }
}

测试结果：

文本分词

文本分词会发生在两个地方，创建索引和搜索的时候。当索引文档字符类型为text时，在建立索引时将会对该字段进行分词。当对一个text类型的字段进行全文检索的时候，会对用户输入的文本进行分词

创建索引时

elasticsearch会按照下面顺序来确定使用哪个分词器:
1、先判断字段是否有设置分词器，如果有，则使用字段属性上的分词器设置；
2、如果设置了analysis.analyzer.default,则使用该设置的分词器；
3、如果上面两个都未设置，则使用默认的standard分词器。

设置索引默认分词器

put wsh_index1
{ 
  "settings": { 
    "analysis": { 
      "analyzer": { 
        "default":{ 
          "type":"simple" 
        } 
      } 
    } 
  } 
}

还可以为索引配置内置分词器，并修改内置的部分选项修改它的行为

put wsh_index1 
{ 
  "settings":{
    "analysis":{ 
      "analyzer":{
        "my_analyzer":{ 
          "type":"standard",
          "stopwords":["the","a","an","this","is"] 
        } 
      }
    } 
  } 
} 

为字段指定内置分词器

put wsh_index1 
{
  "mappings":{ 
    "properties" : {
      "title" :{ 
        "type":"text", 
        "analyzer":"standard",
        "search_analyzer":"simple" 
      } 
    } 
  } 
}

使用案例：
创建索引 对wsh.english 配置停止词

PUT /wsh_index1 
{ 
  "settings": { 
    "analysis": { 
      "analyzer": {
        "stop_english": { 
          "type": "standard", 
          "stopwords": "_english_" 
        } 
      } 
    } 
  },
  "mappings": { 
    "properties": {
      "wsh": {
        "type": "text", 
        "analyzer": "standard",
        "fields": {
          "english": { 
            "type": "text", 
            "analyzer": "stop_english"
          }
        } 
      }
    } 
  } 
}

通过上述运行我们可以看到，分析器 stop_english 中的 the和is 被删除，而 standard中的并没有。这是因为 wsh.english 配置了单独的停止词

文档搜索时

文档搜索时使用的分析器有一点复杂，它依次从如下参数中如果查找文档分析器，如果都没有设置则使用standard分析器。
1、搜索时指定analyzer参数。
2、创建索引时指定字段的search_analyzer属性。
3、创建索引时字段指定的analyzer属性。
4、创建索引时setting里指定的analysis.analyzer.default_search。
5、如果都没有设置则使用standard分析器。

搜索时指定 analyzer 查询参数

GET wsh_index1/_search 
{ 
"query": { 
    "match": {
      "message": { 
        "query": "wsh", 
        "analyzer": "stop" 
      } 
    }
  } 
}

指定字段的 analyzer 和 seach_analyzer

PUT wsh_index1
{ 
  "mappings": { 
    "properties": { 
      "title":{ 
        "type":"text",
        "analyzer": "whitespace",
        "search_analyzer": "simple" 
      }
    } 
  } 
}

指定索引的默认搜索分词器

PUT wsh_index1 
{
  "settings": { 
    "analysis": { 
      "analyzer": {
        "default":{ 
          "type":"simple"
          },
        "default_seach":{
          "type":"whitespace"
        } 
      } 
    }
  } 
}

关于词项的搜索

term 查询

对词项做精确匹配，数值、日期等

get kibana_sample_data_flights/_search 
{ 
	"query":{ 
		"term":{ 
			"dayOfWeek":3 
		} 
	} 
}

对于字符串而言，字符串的精确匹配是指字符的大小写，字符的数量和位置都是相同的，词条（term）查询使用字符的完全匹配方式进行文本搜索，词条查询不会分析（analyze）查询字符串，给定的字段必须完全匹配词条查询中指定的字符串。

terms 查询

类似于sql语句中where条件的in

get kibana_sample_data_flights/_search 
{ 
	"query":{ 
		"terms":{ 
			"OriginCityName":["Frankfurt am Main","Cape Town"] 
		} 
	} 
}

range 查询和 exists 查询

range 查询和过滤器的含义是不言而喻的，它们查询介于一定范围之内的值，适用于数字、日期甚至是字符串。为了使用范围查询，需要指定某个字段的上界和下界值。

gte：greater than and equal 大于等于
gt：greater than 大于
lte：less than and equal 小于等于
lt：less than 大于
boost：相关性评分
exists 查询检索字段值不为空的的文档，无论其值是多少，在查询中通过 field字段设置检查非空的字段名称，只能有一个。

get kibana_sample_data_flights/_search 
{ 
	"query":{ 
		"range":{ 
			"FlightDelayMin":{ 
				"gte":100, 
				"lte":200 
			} 
		} 
	} 
}

prefix 查询

prefix 查询允许你根据给定的前缀来搜索词条，这里前缀在同样搜索之前是没有经过分析的。
找到航班目的国家中所有以 C 开头的文档。

get kibana_sample_data_flights/_search
{ 
	"query":{ 
		"prefix":{ 
			"DestCountry":"C" 
		} 
	} 
}

wildcard 查询和 regexp 查询

wildcard 查询就是通配符查询。
使用字符串可以让 Elasticsearch 使用*通配符替代任何数量的字符(也可以不含)或者是使用?通配符替代单个字符。
使用这种查询时，需要注意的是 wildcard 查询不像 match 等其他查询那样轻量级。查询词条中越早出现通配符( 或者? ), Elasticsearch 就需要做更多的工作来进行匹配。例如，对于查询词条“h”，Elasticsearch 必须匹配所有以“h”开头的词条。
regexp 查询就是正则表达式。

get kibana_sample_data_flights/_search 
{ 
	"query":{
		"regexp":{ 
			"字段名":"正则表达式" 
		} 
	} 
}

基于全文的搜索

match 查询

POST /kibana_sample_data_logs/_search 
{ 
  "query": { 
    "match": { 
      "message": "firefox chrome" 
    } 
  } 
}

默认情况下，引擎内部执行的查询逻辑是：只要 elk 字段值中包含有任意一个关键字 firefox 或 chrome

伪代码
if( doc. elk.contains(firefox ) ||doc. elk.contains(chrome) )
return doc ;

匹配查询的行为受到两个参数的控制：
operator：表示单个字段如何匹配查询条件的分词
minimum_should_match：表示字段匹配的数量

默认情况下 operator 的值是 or，在构造查询时设置分词之间的逻辑运算符，如果设置为 and，那么引擎内部执行的查询逻辑变为
if( doc. elk.contains(firefox ) &&doc. elk.contains(chrome) )
return doc ;

对于 minimum_should_match 属性值，默认值是 1，如果设置其值为 2，表示分词必须匹配查询条件的数量为 2，这意味着，只要文档的 elk 字段包含任意两个关键字，就满足查询条件，但是如果文档中只有 1 个关键字，这个文档就不满足条件。

{ 
	"query": { 
		"match": { 
			"message": { 
				"query":"firefox chrome", 
				"operator": "and" 
			} 
		} 
	} 
}

multi_match 查询

多个字段上执行匹配相同的查询，叫做"multi_match"查询。

POST /kibana_sample_data_flights/_search 
{ 
	"query": { 
		"multi_match": { 
			"query":"AT", 
			"fields":["DestCountry", "OriginCountry"] 
		} 
	} 
}

请求将同时检索文档中 DestCountry 和 OriginCountry 这两个字段，只要有一个字段包含 AT 词项该文档就满足查询条件。

match_phrase 查询

match_phrase 查询首先解析查询字符串来产生一个词条列表。然后会搜索所有的词条，但只保留包含了所有搜索词条的文档，顺序要一模一样。

GET /my_index/my_type/_search 
{ 
	"query": { 
		"match_phrase": { 
			"title": "quick brown fox" 
		} 
	} 
}

精确短语(Exact-phrase)匹配非常的严格, 查询字段的顺序会影响结果,可以在短语匹配使用 slop 参数来引入一些灵活性

slop 参数缺省为 0，它告诉 match_phrase 查询词条能够最远相隔多远时仍然将文档视为匹配。相隔多远的意思是，你需要移动一个词条多少次来让查询和文档匹配。
java is very good 如果想要java good 能搜到这句话 slop就是2

match_phrase_prefix 查询

基于前缀的短语匹配，这种查询的行为与 match_phrase 查询一致，不同的是它将查询字符串的最 后一个词作为前缀使用。

{ 
	"match_phrase_prefix" : { 
		"brand" : "his name is b" 
	} 
}

就相当于his name is b*
与 match_phrase 一样，它也可以接受 slop 参数（参照 slop ）让相对词序位置不那么严格。

模糊查询

在 Elasticsearch 基于全文的查询中，除了与短语相关的查询以外，其余查询都包含有一个名为 fuzziness 的参数用于支持模糊查询。
Elaticsearch 支持的模糊查询比这个要强大得多，它可以根据一个拼写错误的词项匹配正确的结果，例如根据firefix 匹配 firefox。在自然语言处理领域，两个词项之间的差异通常称为距离或编辑距离，距离的大小用于说明两个词项之间差异的大小。

返回包含与搜索字词相似的字词文档；为了找到相似的术语，fuzzy 查询将在指定的编辑距离内创建一组搜索词的所有可能的变体或扩展。查询然后返回每个扩展的完全匹配。

get kibana_sample_data_logs/_search 
{ 
	"query": { 
		"fuzzy": { 
			"message": { 
				"value": "firefix","fuzziness": "1" 
			} 
		} 
	} 
}

我们想找到文档中 message 字段包含 firefox，而查询条件中给出的是 firefix，因为两者的编辑距离为 1，所以包含 firefox 的文档依然可以找到，但是，如果使用firefit，因为编辑距离为 2，则不会找到任何文档。

value，必填项，希望在 field 中找到的术语
fuzziness，选填项，匹配允许的最大编辑距离；可以被设置为“0”， “1”，“2”或“auto”。“auto”是推荐的选项，它会根据查询词的长度定义距离。
max_expansions，选填项，创建的最大变体项，默认为 50。应该避免使用较大的值，尤其是当 prefix_length 参数值为 0 时，如果过多，会影响查找性能。
prefix_length，选填项，创建扩展时保留不变的开始字符数。默认为 0
transpositions，选填项，指示编辑是否包括两个相邻字符串的转置（ab→ba）。默认为 true。

纠错与提示器

POST /kibana_sample_data_logs/_search?filter_path=suggest 
{ 
	"suggest":{ 
		"msg-suggest": { 
			"text": "firefit chrom", 
			"term":{ 
				"field": "message" 
			} 
		} 
	}
}

search 接口的 suggest 参数中定义了一个提示 msg- suggest,并通过 text 参数给出需要提示的内容。另一个参数 term 实际上是一种提示器的名称，它会分析 text 参数中的字符串并提取词项，再根据 Levenshtein 算法找到满足编辑距离的提示词项。所以在返回结果中会包含一个 suguggest 字段。

term 提示器
在示例中使用的提示器就是 term 提示器，这种提示器默认使用的算法是称为 internal 的编辑距离算法。intermal 算法本质上就是 Levenshtein 算法，但根据 Elasticsearch 索引特征做了一些优化而效率更高，可以通过 string distance 参数更改算法。
term 提示器使用的编辑距离可通过 max edits 参数设置，默认值为 2。

phrase 提示器
terms 会将需要提示的文本拆分成词项，然后对每一个词项做单独的提示，而 phrase 提示器则会使用整个文本内容做提示。所以在 phrase 提示器的返回结果中，不会看到一个词项一个词项的提示，而是针对整个短语的提示。但从使用的角度来看几乎是一样的。

completion 提示器
completion 提示器一般应用于输人提示和自动补全，也就是在用户输人的同时给出提示或补全未输入内容。这就要求 completion 提示器必须在用户输人结束前快速地给出提示，所以这个提示器在性能上做了优化以达到快速检索的目的。它会在内存中创建特殊的数据结构以满足快速生成提示词的要求。

term 和 phrase 提示器主要用于纠错，term 提示器用于对单个词项的纠错而 phrase 提示器则主要针对短语做纠错。completion 提示器是专门用于输人提示和自动补全的提示器，在使用上依赖前缀产生提示并且速度更快。