我的Elasticsearch系列文章，逐渐更新中，欢迎关注
0A.关于Elasticsearch及实例应用
00.Solr与ElasticSearch对比
01.ElasticSearch能做什么？
02.Elastic Stack功能介绍
03.如何安装与设置Elasticsearch API
04.如果通过elasticsearch的head插件建立索引_CRUD操作
05.Elasticsearch多个实例和head plugin使用介绍
06.当Elasticsearch进行文档索引时，它是怎样工作的？
10.Kibana科普-作为Elasticsearhc开发工具
11.Elasticsearch查询方法
15.使用Django进行ElasticSearch的简单方法
16.关于Elasticsearch的6件不太明显的事情
17.使用Python的初学者Elasticsearch教程
18.用ElasticSearch索引MongoDB,一个简单的自动完成索引项目
19.Kibana对Elasticsearch的实用介绍
20.不和谐如何索引数十亿条消息
21.使用Django进行ElasticSearch的简单方法
另外Elasticsearch入门，我强烈推荐ElasticSearch新手搭建手册和这篇优秀的REST API设计指南 给你，这两个指南都是非常想尽的入门手册。
介绍
在本系列的第一个博客中，我们看到了在Elasticsearch中对文档建立索引时的反向索引计算，而在第二个博客中，我们看到了Elasticsearch中的映射基础。现在，在此博客中，我们将详细介绍Elasticsearch的分析部分，如何完成以及如何定制分析。
1.分析过程说明
为了了解Elasticsearch中的分析过程及其需求，我们需要对
inverted indexElasticsearch中的创建进行更深入的了解。我们在阶段02的博客01中讨论的关于
inverted index创建的内容是基本版本，在这里让我为倒排索引创建场景添加一些复杂性。
当我们将这些文档索引到Elasticsearch时，流程如下、
【图1】
现在让我解释反向索引创建之前的每个阶段：
1.1字符过滤器
字符过滤器具有对提供给他们的输入文本执行添加，删除或替换操作的能力。为了更清楚地理解它，如果输入字符串包含重复出现的拼写错误的单词，而我们需要用正确的单词替换它，那么我们可以使用字符过滤器对此进行相同的处理。此过滤器最常见的应用之一是
html
从输入文本中剥离标签。
让我们看看使用Elasticsearch的Analyze API进行字符过滤的工作。在这里，我们将使用字符过滤器“ html_strip”从文本中删除html标签。卷曲请求如下：
curl -XPOST 'localhost:9200/_analyze?pretty' -H 'Content-Type: application/json' -d '{ "tokenizer": "standard", "char_filter": [ "html_strip" ], "text": "The <b> Auto-generation </b> is a success" }'
生成的令牌如下所示：
“The”,”Auto”,”generation”,”is”,”a”,”success”
在这里我们可以看到令牌中没有html标记。同样，尝试不带的上述curl请求，
“char_filter”:[“html_strip”]
然后看看有什么不同。
1.2分词器
从“字符”过滤器转换后的输入文本将传递到令牌处理程序。令牌生成器会将输入文本拆分为特定字符处的单个令牌（或术语）。elasticsearch中的默认标记器是“标准标记器”，它使用基于语法的标记化技术，该技术不仅可以扩展到英语，还可以扩展到许多其他语言。
让我们在下面看到一个标准令牌生成器的示例：
curl -XPOST ‘localhost:9200/_analyze?pretty’ -H ‘Content-Type: application/json’ -d '{ “tokenizer”: “standard”, “text”: “The Auto-generation is a success” }'
在响应中，您可以看到文本分为以下标记：
curl -XPOST ‘localhost:9200/_analyze?pretty’ -H ‘Content-Type: application/json’ -d '{ “tokenizer”: “standard”, “text”: “The Auto-generation is a success” }'
在这里，只要有空格和连字符（-），单词就会被拆分。
注意：有不同类型的标记器，用于不同的目的。在某些用例中，我们可能不需要拆分特殊字符（例如，在使用电子邮件ID或url的情况下），因此为了满足此类需求，我们可以使用“ UAX URL Email Tokenizer”等标记器。
1.3 令牌过滤器
将输入文本拆分为标记/术语后，将其移至分析的最后阶段，即标记过滤。令牌过滤器可以作用于由令牌生成器生成的令牌，并可以对其进行修改，添加或删除。让我们尝试以上示例的令牌过滤器。我们将在这里尝试使用的令牌过滤器是小写的令牌过滤器，它将所有进入其中的令牌都小写。以下curl请求使用analyst API进行演示：
curl -XPOST 'localhost:9200/_analyze?pretty' -H 'Content-Type: application/json' -d'{ "tokenizer": "standard", "filter": [ "lowercase" ], "text": "The Auto-generation is a success" }'
响应中生成的令牌如下所示：
“ the”，“ auto”，“ generation”，“ is”，“ a”，“ success”
请注意，每个标记现在都小写了。这就是小写令牌过滤器对令牌的作用。
有关Elasticsearch随附的令牌过滤器的列表
在Elasticsearch中，令牌过滤器最常见的用例之一是向单词添加同义词。从本质上讲，这意味着可以使用此过滤器将单词映射到其同义词，并且每当我们搜索同义词时，都会出现包含基础单词的文档。我们将在以后的博客中看到此方法的应用。
2.分析仪
上一节介绍了Elasticsearch分析文档中字段内容的过程。正如在上一节中提到的，有几种类型的字符过滤器，令牌化器和令牌过滤器可用，我们应该根据遇到的用例明智地选择它们。这三个组件（字符过滤器，令牌生成器和令牌过滤器）的组合称为分析器。Elasticsearch提供了几种类型的内置分析器，用于处理最常见的用例。例如，Elasticsearch的默认分析器标准分析器是标准令牌生成器和两个令牌过滤器（标准令牌过滤器，小写和停止令牌过滤器）的组合。同样，根据字符过滤器的组合，可以使用多种分析仪，
分析仪的总体结构如下所示：
【图2】
我们还可以通过选择所需的过滤器和标记器来制作自定义分析器。我们将在本系列的下一个博客中看到定制分析器的制作。
3.分析阶段
现在我们对什么是分析以及什么是分析器有了清晰的了解，让我们进入在Elasticsearch中发生的分析的两个阶段，即索引时间分析和搜索时间分析。
3.1索引时间分析
让我们考虑以下文档进行索引
curl -XPOST localhost:9200/testindex-0203/testtype/1 -d '{ "text": "My name is Arun" }'
由于我们没有使用分析器，因此Elasticsearch对此应用了默认的分析器“标准分析器”。让我们在分析API的帮助下，查看上述文档与Standard Analyser一起使用时的最终标记
curl -XPOST 'localhost:9200/_analyze?pretty' -H 'Content-Type: application/json' -d'{ "analyzer": "standard", "text": "My name is Arun" }'
用于存储在倒排索引中的令牌是：
“我的”，“姓名”，“是”，“阿伦”
倒排的索引如下表所示：
【图3】
这整个过程发生在索引时间中，因此发生在名称索引时间分析中。
3.2搜索时间分析
顾名思义，搜索时间分析将在搜索时发生。但是有一个区别，就是这种分析是在查询上进行的，具体取决于所使用的查询。
3.2.1术语查询-情况1
考虑以下查询：
curl -XPOST 'localhost:9200/_analyze?pretty' -H 'Content-Type: application/json' -d'{ "analyzer": "standard", "text": "My name is Arun" }'
如果我们对索引“ testindex-0203”运行此查询，它将返回被索引的文档作为结果。标记“名称”存在于反向索引中，并再次映射到文档1。因此，当我们搜索术语“名称”时，它将查找反向索引，并且由于找到了该术语，因此相应的文档被提取为结果。
3.2.2术语查询-案例2
现在考虑具有相同“条件”查询的另一种情况，如下所示：
curl -XPOST localhost:9200/testindex-0203/testtype/_search -d '{ “query”: { “term”: { “text”: “Name” } } }'
在这里，我们使用相同的术语查询来进行查询，但是对于搜索关键字使用不同的大小写，其现在是“名称”而不是“名称”。现在发生了一些有趣的事情，此搜索不会给我们找到任何文件。这种奇怪行为的原因是，倒排索引中不存在“名称”，因此没有要显示的文档。
因此，对于“术语”查询，不允许对搜索关键字进行任何分析。
3.2.3术语查询-情况3
让我们考虑术语查询的另一种情况以查看此行为，这是查询
curl -XPOST localhost:9200/testindex-0203/testtype/_search -d '{ “query”: { “term”: { “text”: “My name” } } }'
在上述情况下，没有分析搜索关键字，因此，Elasticsearch在反向索引中寻找令牌“我的名字”。并且由于此类术语不存在，因此针对上述查询，elasticsearch也将返回零结果。
在Elasticsearch中就是“条件”查询的情况。让我们尝试一个不同的查询，称为match query并检查输出。
3.2.4匹配查询-情况1
考虑以下查询：
curl -XPOST localhost:9200/testindex-0203/testtype/_search -d '{ “query”: { “term”: { “text”: “My name” } } }'
这将返回带有索引文档的响应，因为反向索引中存在“名称”令牌。
3.2.5匹配查询-情况2
curl -XPOST localhost:9200/testindex-0203/testtype/_search -d '{ “query”: { “match”: { “text”: “Name” } } }'
在这里，当我们对案例2使用“条件”查询时，没有任何响应。但是，对于匹配查询，无论在索引编制时将什么分析应用于要查询的字段（文本），都将对搜索关键字（“名称”）进行完全相同的分析。这使搜索关键字经历“标准分析”，并且搜索关键字“名称”更改为“名称”（由于标准分析器中的小写标记过滤器）。这个新的搜索关键字“名称”存在于反向索引中，并且响应也将具有相应的文档。
3.2.6匹配查询-情况3
curl -XPOST localhost:9200/testindex-0203/testtype/_search -d '{ “query”: { “match”: { “text”: “Name” } } }'
这里给出的搜索关键字是“My name”，经过标准分析后，它将转换为关键字“我的名字”和“名字”。这两个关键字都存在于反向索引中，因此将文档作为响应返回。
因此，根据查询类型，搜索关键字将在搜索时间内进行分析（与查询的字段相同）。这称为搜索时间分析。
结论
在此博客中，我介绍了分析器的基本组成部分以及Elasticsearch中发生的分析类型。在下一个博客中，我们将看到如何针对非常特定的用例构建自己的自定义分析器。