第四章 ElasticSearch基础搜索（二）

一、内置分析器

前面说过，每个被分析字段经过一系列的处理步骤：

1）字符过滤：使用字符过滤器转变字符。

2）文本切分为分词：将文本切分为单个或多个分词。

3）分词过滤：使用分词过滤器转变每个分词。

每个分析器基本上都要包含上面三个步骤至少一个。其中字符过滤器可以为0个，也可以为多个，分词器则必须，但是也只能有一个，分词过滤器可以为0个或者多个。Elasticsearch已经为我们内置了很多的字符过滤器、分词器和分词过滤器，以及分析器。不过常用的就是那么几个。

1、字符过滤器Character filters

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

1.1、HTML字符过滤器HTML Strip Char Filter

从文本中去除HTML元素：

POST _analyze

{

  "tokenizer": "keyword",

  "char_filter": [

    "html_strip"

  ],

  "text": "<p>I'm so <b>happy</b>!</p>"

}

执行结果如下：

{

  "tokens" : [

    {

      "token" : """I'm so happy!""",

      "start_offset" : 0,

      "end_offset" : 27,

      "type" : "word",

      "position" : 0

    }

  ]

}

1.2、映射字符过滤器Mapping Char Filter

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

PUT pattern_test4

{

  "settings": {

    "analysis": {

      "analyzer": {

        "my_analyzer": {

          "tokenizer": "keyword",

          "char_filter": [

            "my_char_filter"

          ]

        }

      },

      "char_filter": {

        "my_char_filter": {

          "type": "mapping",

          "mappings": [

            "hankin => 666",

            "chj => 888"

          ]

        }

      }

    }

  }

}

上例中，我们自定义了一个分析器，其内的分词器使用关键字分词器，字符过滤器则是自定制的，将字符中的hankin替换为666，chj替换为888。进行测试：

POST pattern_test4/_analyze

{

  "analyzer": "my_analyzer",

  "text": " hankin就是chj，hankin只是英文名称！"

}

执行结果：

{

  "tokens" : [

    {

      "token" : " 666就是888，666只是英文名称！",

      "start_offset" : 0,

      "end_offset" : 26,

      "type" : "word",

      "position" : 0

    }

  ]

}

1.3、模式替换过滤器Pattern Replace Char Filter

使用正则表达式匹配并替换字符串中的字符。但要小心你写的糟糕的正则表达式，因为这可能导致性能变慢。比如：

POST _analyze

{

"analyzer": "standard",

"text": "My credit card is 123-456-789"

}

这样分词，会导致123-456-789被分为123、456、789，但是我们希望123-456-789 是一个整体，可以使用模式替换过滤器，替换掉“-”。

PUT pattern_test5

{

  "settings": {

    "analysis": {

      "analyzer": {

        "my_analyzer": {

          "tokenizer": "standard",

          "char_filter": [

            "my_char_filter"

          ]

        }

      },

      "char_filter": {

        "my_char_filter": {

          "type": "pattern_replace",

          "pattern": """(\d+)-(?=\d)""",

          "replacement": "$1_"

        }

      }

    }

  }

}

再次测试：

POST pattern_test5/_analyze

{

  "analyzer": "my_analyzer",

  "text": "My credit card is 123-456-789"

}

把数字中间的“-”替换为下划线“_”，这样的话可以让“123-456-789”作为一个整体，而不至于被分成123 456 789三部分。

2、分词器Tokenizer

2.1、标准分词器(standard)

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

“I have, potatoes.”切分后的分词分别是” I” 、” have” 和” potatoes”。

2.2、关键词分词器(keyword)

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

2.3、字母分词器(letter)

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

2.4、小写分词器(lowercase)

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

'Hi, there.'分词是hi和 there。

2.5、空白分词器(whitespace)

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

2.6、模式分词器(pattern)

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

2.7、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都作为单独的分词进行保留。

2.8、路径层次分词器(path_hierarchy)

路径层次分词器( path hierarchy tokenizer )允许以特定的方式索引文件系统的路径，这样在搜索时，共享同样路径的文件将被作为结果返回。例如，假设有一个文件名想要索引，看上去是这样的(/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" 拥有同样的分词，因此它也会被作为结果返回。

3、分词过滤器（Token filters）

3.1、标准分词过滤器（standard）

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

3.2、小写分词过滤器（lowercase）

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

3.3、长度分词过滤器（length）

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

3.4、停用词分词过滤器（stop）

停用词分词过滤器(stop token fite)将停用词从分词流中移除。对于英文而言，这意味着停用词列表中的所有分词都将会被完全移除。用户也可以为这个过滤器指定一个待移除单词的列表。

什么是停用词?

停用词是指在信息检索中，为节省存储空间和提高搜索效率，在处理自然语言数据（或文本）之前或之后会自动过滤掉某些字或词，这些字或词即被称为Stop Words（停用词）。

停用词(Stop Words)大致可分为如下两类： 

1）使用十分广泛，甚至是过于频繁的一些单词。

比如英文的“i”、“is”、“what”，中文的“我”、“就”之类词几乎在每个文档上均会出现，查询这样的词搜索引擎就无法保证能够给出真正相关的搜索结果，难于缩小搜索范围提高搜索结果的准确性，同时还会降低搜索的效率。因此，在真正的工作中，Google和百度等搜索引擎会忽略掉特定的常用词，在搜索的时候，如果我们使用了太多的停用词，也同样有可能无法得到非常精确的结果，甚至是可能大量毫不相关的搜索结果。

2）文本中出现频率很高，但实际意义又不大的词。

这一类主要包括了语气助词、副词、介词、连词等，通常自身并无明确意义，只有将其放入一个完整的句子中才有一定作用的词语。如常见的“的”、“在”、“和”、“接着”之类。

下面是英文的默认停用词列表:

a, an, and, are, as, at, be, but, by, for, if, in, into, is, it, no, not, of, on, or;

such, that, the, their; then,there, these, they, this, to, was, will, with

系统内置的停止词如下： 

种语言中常见的停止词。这些内置的停止词如下:

_arabic_， - armenian_，_ basque，_ bengali 1，_ brazilian，_ bulgarian_,_ catalan _，_czech_,_ danish_，_dutch_，english_，finnish_, french_，_galician_，german_,_greek._hindi_,_ hungarian_，_ indonesian_，_ irish_，_ _italian_，_ latvian_,_norwegian_,_ persian_，_portuguese_,_ romanian_,_ russian_,-sorani_,- spanish_,_swedish_，_thai_，_turkish_等。

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

下面3个分词过滤器，通过某种方式限制分词流。

■截断分词过滤器( truncate token filter )允许你通过定制配置中的length参数，截断超过一定长度的分词。默认截断多于10个字符的部分。

■修剪分词过滤器( trim token filter )删除1个分词中的所有空白部分。例如，分词" foo "将被转变为分词foo。

■限制分词数量分词过滤器(limit token count token filter)限制了某个字段可包含分词的最大数量。例如，如果创建了一个定制的分词数量过滤器，限制是8，那么分词流中只有前8个分词会被索引。这个设置使用max_ token_ count参数，默认是1 (只有1个分词会被索引)。

4、常用内置分析器

4.1、标准分析器

当没有指定分析器的时候，标准分析器( standardanalyzer)是文本的默认分析器。它综合了对大多欧洲语言来说合理的默认模块，它没有字符过滤器，包括标准分词器、小写转换分词过滤器和停用词分词过滤器（默认为_none_，也就是不去除停止词）。这里只需要记住，如果不为某个字段指定分析器，那么该字段就会使用标准分析器。可配置的参数如下：

max_token_length：默认值255，表示词项最大长度，超过这个长度将按该长度分为多个词项。

Stopwords：默认值_none_，表示分析器使用的停止词数组，可使用内置停止词列表，比如_english_等。

stopwords_path：停止词文件路径。

4.2、简单分析器

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

4.3、空白分析器

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

4.4、停用词分析器

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

4.5、关键词分析器

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

4.6、模式分析器

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

4.7、雪球分析器

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

5、自定义分析器

5.1、业务需求如下

去除所有的HTML标签将&替换成and，使用一个自定义的mapping字符过滤器使用standard分词器分割单词，使用lowercase分词过滤器将词转为小写，用stop分词过滤器去除一些自定义停用词。

PUT pattern_custom

{

  "settings": {

    "analysis": {

      "analyzer": {

        "my_analyzer": {

          "char_filter": [

            "html_strip",

            "&_to_and"

          ],

          "filter": [

            "lowercase",

            "my_stopwords"

          ],

          "tokenizer": "standard",

          "type": "custom"

        }

      },

      "char_filter": {

        "&_to_and": {

          "mappings": [

            "&=>and"

          ],

          "type": "mapping"

        }

      },

      "filter": {

        "my_stopwords": {

          "stopwords": [

            "hankin",

            "Jason"

          ],

          "type": "stop"

        }

      }

    }

  }

}

5.2、测试验证：

POST pattern_custom/_analyze

{

  "analyzer": "my_analyzer",

  "text": "<br> I & Zacker & hankin & Jason are handsome<br>"

}

查询结果如下所示：

{

  "tokens" : [

    {

      "token" : "i",

      "start_offset" : 5,

      "end_offset" : 6,

      "type" : "<ALPHANUM>",

      "position" : 0

    },

    {

      "token" : "and",

      "start_offset" : 7,

      "end_offset" : 8,

      "type" : "<ALPHANUM>",

      "position" : 1

    },

    {

      "token" : "zacker",

      "start_offset" : 9,

      "end_offset" : 15,

      "type" : "<ALPHANUM>",

      "position" : 2

    },

    {

      "token" : "and",

      "start_offset" : 16,

      "end_offset" : 17,

      "type" : "<ALPHANUM>",

      "position" : 3

    },

    {

      "token" : "and",

      "start_offset" : 25,

      "end_offset" : 26,

      "type" : "<ALPHANUM>",

      "position" : 5

    },

    {

      "token" : "are",

      "start_offset" : 33,

      "end_offset" : 36,

      "type" : "<ALPHANUM>",

      "position" : 7

    },

    {

      "token" : "handsome",

      "start_offset" : 37,

      "end_offset" : 45,

      "type" : "<ALPHANUM>",

      "position" : 8

    }

  ]

}

不难发现，HTML标签没了，大写I变为了小写i，停用词hankin、Jason过滤掉了。

6、中文分析器

上面的分析器基本都是针对英文的，对中文的处理不是太好，比如：

POST _analyze

{

  "analyzer": "standard",

  "text": "我爱北京天安门！"

}

分析后的结果是：

{

  "tokens" : [

    {

      "token" : "我",

      "start_offset" : 0,

      "end_offset" : 1,

      "type" : "<IDEOGRAPHIC>",

      "position" : 0

    },

    {

      "token" : "爱",

      "start_offset" : 1,

      "end_offset" : 2,

      "type" : "<IDEOGRAPHIC>",

      "position" : 1

    },

    {

      "token" : "北",

      "start_offset" : 2,

      "end_offset" : 3,

      "type" : "<IDEOGRAPHIC>",

      "position" : 2

    },

    {

      "token" : "京",

      "start_offset" : 3,

      "end_offset" : 4,

      "type" : "<IDEOGRAPHIC>",

      "position" : 3

    },

    {

      "token" : "天",

      "start_offset" : 4,

      "end_offset" : 5,

      "type" : "<IDEOGRAPHIC>",

      "position" : 4

    },

    {

      "token" : "安",

      "start_offset" : 5,

      "end_offset" : 6,

      "type" : "<IDEOGRAPHIC>",

      "position" : 5

    },

    {

      "token" : "门",

      "start_offset" : 6,

      "end_offset" : 7,

      "type" : "<IDEOGRAPHIC>",

      "position" : 6

    }

  ]

}

Standard 分析器把中文语句拆分为一个个的汉字，并不是太适合。这时候，就需要中文分析器。

中文分析器有很多，例如cjk，ik等等，我们选用比较有名的ik作为我们的中文分析器。

6.1、安装中文分析器

1）下载elasticsearch-analysis-ik7.7.0

下载地址：https://github.com/medcl/elasticsearch-analysis-ik/releases

2）在elasticsearch的plugins中新建文件夹ik，在ik文件夹中解压缩下载的压缩包，

mkdir ik

unzip elasticsearch-analysis-ik-7.7.0.zip

3）重启elasticsearch，成功

4）若发现报错，如下图所示，则请查看文件夹的权限不够，可通过chmod 777 –R 文件夹路径，赋予所有权限。另外elasticsearch版本和分词器的版本一定要一致

注意：如果是gz包方式部署的ES则可以使用下面这种方式安装：

进入elasticsearch目录下的plugins目录，并执行：

./elasticsearch-plugin install https://github.com/medcl/elasticsearch-analysis-ik/releases/download/v7.7.0/elasticsearch-analysis-ik-7.7.0.zip

如果询问你Continue with installation?，当然继续进行，安装完成后，必须重启elasticsearch。

6.2、中文分析器的使用

IK分词器有两种分词效果，一种是ik_max_word（最大分词）和ik_smart（最小分词）。

6.2.1、ik_max_word最细粒度分词:

会将文本做最细粒度的拆分，比如会将“中华人民共和国国歌”拆分为“中华人民共和国，中华人民,中华，华人，人民共和国，人民，人，民，共和国，共和，和，国国，国歌”，会穷尽各种可能的组合。

POST _analyze

{

  "analyzer": "ik_max_word",

  "text": "中华人民共和国国歌"

}

分词效果如下：

{

  "tokens" : [

    {

      "token" : "中华人民共和国",

      "start_offset" : 0,

      "end_offset" : 7,

      "type" : "CN_WORD",

      "position" : 0

    },

    {

      "token" : "中华人民",

      "start_offset" : 0,

      "end_offset" : 4,

      "type" : "CN_WORD",

      "position" : 1

    },

    {

      "token" : "中华",

      "start_offset" : 0,

      "end_offset" : 2,

      "type" : "CN_WORD",

      "position" : 2

    },

    {

      "token" : "华人",

      "start_offset" : 1,

      "end_offset" : 3,

      "type" : "CN_WORD",

      "position" : 3

    },

    {

      "token" : "人民共和国",

      "start_offset" : 2,

      "end_offset" : 7,

      "type" : "CN_WORD",

      "position" : 4

    },

    {

      "token" : "人民",

      "start_offset" : 2,

      "end_offset" : 4,

      "type" : "CN_WORD",

      "position" : 5

    },

    {

      "token" : "共和国",

      "start_offset" : 4,

      "end_offset" : 7,

      "type" : "CN_WORD",

      "position" : 6

    },

    {

      "token" : "共和",

      "start_offset" : 4,

      "end_offset" : 6,

      "type" : "CN_WORD",

      "position" : 7

    },

    {

      "token" : "国",

      "start_offset" : 6,

      "end_offset" : 7,

      "type" : "CN_CHAR",

      "position" : 8

    },

    {

      "token" : "国歌",

      "start_offset" : 7,

      "end_offset" : 9,

      "type" : "CN_WORD",

      "position" : 9

    }

  ]

}

6.2.2、ik_smart粗粒度分词:

会做最粗粒度的拆分，比如会将“中华人民共和国国歌”拆分为“中华人民共和国，国歌”，使用方式和一般的分析器没有什么差别。

POST _analyze

{

  "analyzer": "ik_smart",

  "text": "中华人民共和国国歌"

}

分词结果：

{

  "tokens" : [

    {

      "token" : "中华人民共和国",

      "start_offset" : 0,

      "end_offset" : 7,

      "type" : "CN_WORD",

      "position" : 0

    },

    {

      "token" : "国歌",

      "start_offset" : 7,

      "end_offset" : 9,

      "type" : "CN_WORD",

      "position" : 1

    }

  ]

}

二、基于全文（match）的搜索

了解了文本分析以后，就可以学习基于全文的搜索了，这里就需要用到match系列查询。

 

1、match查询

比如说：

GET my_index/_search

{

  "query": {

    "match": {

      "message": {

        "elk": "Elasticsearch LogStash Kibana",

        "analyzer": "stop"

      }

    }

  }

}

查询字符串是“Elasticsearch LogStash Kibana”，被分析器分词之后，产生三个小写的单词：elasticsearch logstash kibana，然后根据分析的结果构造一个布尔查询，默认情况下，引擎内部执行的查询逻辑是：只要 elk字段值中包含有任意一个关键字elasticsearch或logStash或kibana，那么返回该文档，相对于的伪代码是：if( doc. elk.contains(elasticsearch) ||doc. elk.contains(logstash) ||doc. elk.contains (kibana) ) return doc ;

匹配查询的行为受到两个参数的控制： 

operator：表示单个字段如何匹配查询条件的分词。

minimum_should_match：表示字段匹配的数量通过调整operator和minimum_should_match属性值，控制匹配查询的逻辑条件，进而控制引擎返回的结果。默认情况下operator的值是or，在构造查询时设置分词之间的逻辑运算符，如果设置为and，那么引擎内部执行的查询逻辑是：

if( doc. elk.contains(elasticsearch) &&doc. elk.contains(logstash) &&doc. elk.contains (kibana) ) return doc ;

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

 

比如：

POST /kibana_sample_data_logs/_search

{

  "query": {

    "match": {

      "message": "firefox chrome"

    }

  }

}

检索包含firefox或chrome的文档，如果改为：

POST /kibana_sample_data_logs/_search

{

  "query": {

    "match": {

      "message": {

        "query": "firefox chrome",

        "operator": "and"

      }

    }

  }

}

则不会有任何文档返回，因为没有文档的message字段既包含firefox又包含chrome。同样：

POST /kibana_sample_data_logs/_search

{

  "query": {

    "match": {

      "message": {

        "query": "firefox chrome",

        "minimum_should_match": 2

      }

    }

  }

}

也不会任何文档返回，原因也是一样的，因为没有文档的message字段既包含firefox又包含chrome。

2、multi_match查询

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

POST /kibana_sample_data_flights/_search

{

  "query": {

    "multi_match": {

      "query": "AT",

      "fields": [

        "DestCountry",

        "OriginCountry"

      ]

    }

  }

}

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

3、match_phrase查询

当你希望寻找邻近的单词时，match_phrase查询可以帮你达到目的。比如：

假设我们要找到title字段包含这么一段文本“quick brown fox”的文档，然后我们用

GET /my_index/_doc/1

{

  "query": {

    "match_phrase": {

      "title": "quick brown fox"

    }

  }

}

match_phrase查询首先解析查询字符串来产生一个词条列表。然后会搜索所有的词条，但只保留包含了所有搜索词条的文档，并且词条的位置要邻接。但是对于

GET /my_index/_doc/1

{

  "query": {

    "match_phrase": {

      "title": "quick fox"

    }

  }

}

这个查询查询不会匹配我们的任何文档，因为没有文档含有邻接在一起的quick和fox词条。也就是说，匹配的文档必须满足：

1）quick、brown和fox必须全部出现在title字段中。

2）brown的位置必须比quick的位置大1。

3）fox的位置必须比quick的位置大2。

如果以上的任何一个条件没有被满足，那么文档就不能被匹配。

精确短语(Exact-phrase)匹配也许太过于严格了。也许我们希望含有"quick brown fox"的文档也能够匹配"quick fox"查询，即使位置并不是完全相等的。我们可以在短语匹配使用 slop 参数来引入一些灵活性：

GET /my_index/_doc/1

{

  "query": {

    "match_phrase": {

      "title": {

        "query": "quick fox",

        "slop": 1

      }

    }

  }

}

slop参数缺省为0，它告诉 match_phrase查询词条能够最远相隔多远时仍然将文档视为匹配。相隔多远的意思是，你需要移动一个词条多少次来让查询和文档匹配？比如这样一段文本：hello world, java is very good, spark is also very good.

使用match_phrase搜索java spark搜不到如果我们指定了slop，那么就允许java spark进行移动，来尝试与doc进行匹配

java is very good spark is java spark java

--> spark java

--> sparkjava

--> spark

上面展示了，当固定第一个term的时候，后面的teram经过移动直到匹配上搜索词的经过这个移动的次数就是slop，实际例子如下：

POST /kibana_sample_data_logs/_search

{

  "query": {

    "match_phrase": {

      "message": "firefox 6.0a1"

    }

  }

}

4、match_phrase_prefix查询

被称为基于前缀的短语匹配，比如：

{

"match_phrase_prefix" : {

"brand" : "johnnie walker bl"

}

}

这种查询的行为与match_phrase查询一致，不同的是它将查询字符串的最后一个词作为前缀使用，换句话说，可以将之前的例子看成如下这样：johnnie跟着walker跟着以bl开始的词或者可以干脆理解为："johnnie walker bl*"与match_phrase一样，它也可以接受slop参数（参照slop）让相对词序位置不那么严格：

{

"match_phrase_prefix" : {

"brand" : {

"query": "walker johnnie bl",

"slop": 10 

}

}

}

prefix查询存在严重的资源消耗问题，短语查询的这种方式也同样如此。前缀a可能会匹配成千上万的词，这不仅会消耗很多系统资源，而且结果的用处也不大。可以通过设置max_expansions参数来限制前缀扩展的影响，一个合理的值是是50 ，这也是系统默认的值：

{

"match_phrase_prefix" : {

"brand" : {

"query":

"johnnie walker bl",

"max_expansions": 50

}

}

}

实际例子：

POST /kibana_sample_data_logs/_search

{

  "query": {

    "match_phrase_prefix": {

      "message": "firefox 6.0"

    }

  }

}

5、模糊查询、纠错与提示器

5.1、编辑距离算法

在Elasticsearch基于全文的查询中，除了与短语相关的查询以外，其余查询都包含有一个名为fuzziness的参数用于支持模糊查询。Elasticsearch支持的模糊查询与SQL语言中模糊查询还不一样，SQL的模糊查询使用“% keyword%"的形式，效果是查询字段值中包含keyword的记录。

Elaticsearch支持的模糊查询比这个要强大得多，它可以根据一个拼写错误的词项匹配正确的结果，例如根据firefix匹配firefox。在自然语言处理领域，两个词项之间的差异通常称为距离或编辑距离，距离的大小用于说明两个词项之间差异的大小。计算词项编辑距离的算法有多种，在Elasticsearch中主要使用Levenshtein和NGram两种。其他与此相关的算法也都是在这两种算法基础上进行的改造，基本思想都是一致的。所以理解这两个算法的核心思想是学习这部分内容的关键。

5.2、编辑距离算法Levenshtein与NGram

5.2.1、Levenshein算法

Levenshein算法是前苏联数学家Vladimir Levenshein在1965年开发的一套算法， 这个算法可以对两个字符串的差异程度做量化。量化结果是一个正整数，反映的是一个字符申变成另一个字符串最少需要多少次的处理。由于Levenshtein算法是最为普遍接受的编辑距离算法，所以在很多文献中如果没有特殊说明编辑距离算法就是指Levenshtein算法。在Levenshtein算法中定义了三种字符操作，即替换、插人和删除，后来又由其他科学家补充了一个换位操作。在转换过程中，每执行次操作编辑距离就加1， 编辑距离越大越能说明两个字符串之间的差距大。

比如从firefix到firefox需要将“i"替换成“o”，所以编辑距离为1；而从fax到fair则需要将“x”替换为“i"并在结尾处插人“r”，所以编辑距离为2。显然在编辑距离相同的情况下，单词越长错误与正确就越接近。比如编辑距离同样为2的情况下，从fax到fair与从elascsearxh到elasticsearch，后者elastesearsh是由拼写错误引起的可能性就更大些。所以编辑距离这种量化标准一般还需要与单词长度结合起来考虑，在一些极端情况下编辑距离还应该设置为0，比如像at、on这类长度只有2的短单词。

5.2.2、NGram算法

NGram一般是指N个连续的字符，具体的字符个数被定义为NGram的size。size为1的NGram称为Unigram，size为2时称为Bigram，而size为3时则称为Trigram。如果NGram处理的单元不是字符而是单词，一般称之为Shingle。使用NGram 计算编辑距离的基本思路是让字符串分解为NGram，然后比较分解后共有NGram的数量。

假设有a、b两个字符申，则NGram距离的具体运算公式为：ngram( a )+ngram(b) -2 * ngram(a)∩ngram( b)，公式中ngram(a)和 ngram(b)代表 a、b 两个字符串NGram的数量，ngram(a)∩ngram(b)则是两者共有NGram的数量。

例如按Bigram处理firefix和firefox两个单词，分别为“fi,ir,re, ef, fi,ix”和“fi，ir, re, ef, fi, ox"。那么两个字符申的Bigram个数都为6，而共有Bigram为4，则最终NGram距离为6+6-2x4=4。

在应用上，Levenshtein算法更多地应用于对单个词项的模糊查询上，而NGram则应用于多词项匹配中。Elasticseareh同时应用了两种算法。

5.3、模糊查询fuzzy

返回包含与搜索字词相似的字词文档；为了找到相似的术语，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。

5.4、纠错与提示器

纠错是在用户提交了错误的词项时给出正确词项的提示，而输人提示则是在用户输人关键字时给出智能提示，甚至可以将用户未输人完的内容自动补全。大多数互联网搜索引擎都同时支持纠错和提示的功能，比如在用户提交了错误的搜索关键字时会提示:“你是不是想查找....”。而在用户输人搜索关键字时还能自动弹出提示框将用户可能要输人的内容全都列出来供用户选择。

Elasticsearch也同时支持纠错与提示功能，由于这两个功能从实现的角度来说并没有本质区别，所以它们都由一种被称为提示器或建议器( Suggester)的特殊检索实现。由于输人提示需要在用户输人的同时给出提示词，所以这种功能要求速度必须快，否则就失去了提示的意义。在实现上，输人提示是由单独的提示器完成。而在使用上，提示器则是通过检索接口_search的一个参数设置，例如:

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提示器找到的提示词项：

 

Elaticearch提供了三种提示器，它们在本质上都是基于编辑距离算法，下面就来看看这此提示器如何使用。

5.5、term提示器

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

term提示器使用的编辑距离可通过max_ edits参数设置，默认值为2。

5.6、phrase提示器

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

POST /kibana_sample_data_logs/_search

{

  "suggest": {

    "msg-suggest": {

      "text": "firefix with chrime",

      "phrase": {

        "field": "message"

      }

    }

  }

}

展示结果：

 

但不要被phrase提示器返回结果欺骗，这个提示器在执行时也会对需要提示的文本内容做词项分析，然后再通过NGram算法计算整个短语的编辑距离。所以本质上来说，phrase提示是基于term提示器的提示器，同时使用了Levenshtein和NGram算法。

5.7、completion提示器

completion提示器一般应用于输入提示和自动补全，也就是在用户输入的同时给出提示或补全未输入内容。这就要求completion提示器必须在用户输人结束前快速地给出提示，所以这个提示器在性能上做了优化以达到快速检索的目的。

首先要求提示词产生的字段为completion类型，这是一种专门为completion提示器而设计的字段类型，它会在内存中创建特殊的数据结构以满足快速生成提示词的要求。例如在示例中创建了aricles索引，并向其中添加了1份文档：

PUT articles

{

  "mappings": {

    "properties": {

      "author": {

        "type": "keyword"

      },

      "content": {

        "type": "text"

      },

      "suggestions": {

        "type": "completion"

      }

    }

  }

}

POST articles/_doc/

{

  "author": "taylor",

  "content": "an introduction of elastic stack and elasticsearch",

  "suggestions": {

    "input": [

      "elastic stack",

      "elasticsearch"

    ],

    "weight": 10

  }

}

POST articles/_doc/

{

  "author": "taylor",

  "content": "an introduction of elastic stack and elasticsearch",

  "suggestions": [

    {

      "input": "elasticsearch",

      "weight": 30

    },

    {

      "input": "elastic stack",

      "weight": 1

    }

  ]

}

在向completion类型的字段添加内容时可以使用两个参数，input参数设置字段实际保存的提示词；而 weight参数则设置了这些提示词的权重，权重越高它在返回的提示词中越靠前。在示例5.7中给出了两种设置提示词权重的方式，第一种是将一组提示词的权重设置为统一值，另一种则是分开设置它们的权重值，需要注意的是，completion类型字段保存的提示词是不会分析词项的，比如示例5.7中的“elastic stack”并不会拆分成两个提示词，而是以整体出现在提示词列表中。

completion提示器专门用于输人提示或补全，它根据用户已经输人的内容提示完整词项，所以在completion提示器中没有text参数而是使用prefix参数。例如：

POST articles/_search

{

  "_source": "suggest",

  "suggest": {

    "article_suggestion": {

      "prefix": "ela",

      "completion": {

        "field": "suggestions"

      }

    }

  }

}

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