1.从全文检索说起

首先介绍一下结构化与非结构化数据：

结构化数据将数据具有的特征事先以结构化的形式定义好，数据有固定的格式或有限的长度。典型的结构化数据就是传统关系型数据库的表结构，数据特征直接体现在表结构的字段上，所以根据某一特征做数据检索很直接，速度也比较快
非结构化数据没有预先定义好的结构化特征，也没有固定格式和固定长度。典型的非结构化数据包括文章、图片、视频、网页、邮件等，其中像HTML网页这种具有一定格式的文档也称为半结构化数据

对于非结构化的数据检索，被称为全文检索。

假设现在MySQL中有一张User表，含有三个阶段：姓名name、年龄age和爱好favor：

对于User表来说，整体上是结构化的，比如name、age都可以直接建立索引来快速地检索。
而其中的favor字段是一个text类型，存储的是非结构化的文本数据：
篮球、足球、爱运动的我；本人热爱学习，游戏偶尔也玩！！！！

与结构化查询相比，全文检索面临的最大问题就是性能问题。全文检索最一般的应用场景是根据一些关键字查找包含这些关键字的文档，比如互联网搜索引擎要实现的功能就是根据一些关键字查找网页。显然，如果没有对文档做特别处理，查找的办法似乎只能是逐条比对。

假设现在需要找到favor中含有“足球”这个关键字的User，那么只能使用like模糊查询：
select * from user where favor like '%足球%'

like语句是无法建立索引的，查询时会进行全表扫描，并且在每个favor字段中进行遍历匹配，以找到含有“足球”这个关键字的记录，整体复杂度特别高，所以全文检索也是MySQL这类结构关系式数据库无法很好实现的需求。

全文检索一般是查询包含某一或某些关键字记录，所以通过文档整体值建立的索引对提高查询速度是没有任何帮助的。为了解决这个问题，人们创建了一种新索引方法，这种索引方法就是倒排索引。

2.倒排索引的原理

倒排索引是为了解决上述非结构化数据的检索问题而产生的。

首先明确一下，在ES中存储记录的单位是JSON“文档”，而JSON“文档”中的“字段”也就是组成JSON的一个个KV对。

普通索引也被称为正排索引，也就是通过对主键和结构化字段建立索引，通过这些结构化索引找到文档。

倒排索引则是先将文档中包含的关键字全部提取出来，然后再将关键字与文档的对应关系保存起来，最后再对关键字本身做索引排序。用户在检索某一关键字时，可以先对关键字的索引进行查找，再通过关键字与文档的对应关系找到所在文档。

假设上述的User表通过ES存储，其中两个User文档为：

{"_id: 1,"name":"pbr1","age":22,"favor":"篮球、足球、爱运动的我；本人热爱学习，游戏偶尔也玩！！！！"
}{"_id: 2,"name":"pbr2","age":22,"favor":"篮球、足球、爱运动的我"
}

其中favor定义为text类型，假设分词器进行以下分词：

文档1的favor分词：“篮球”、“足球”、“爱运动的我”、“本人热爱学习”、“游戏偶尔也玩”这5个token
文档2的favor分词：“篮球”、“足球”、“爱运动的我”这3个token

那么对分词token建立索引，并建立对原始文档的映射，就得到一个以favor进行分词的倒排索引：
在这里插入图片描述

可以看到，倒排索引实际上就是对全文数据结构化的过程。对于存储在关系型数据库中的数据来说，它们依赖于人的预先分析将数据拆解为不同字段，所以在数据插入时就已经是结构化的；而在全文数据库中，文档在插入时还不是结构化的，需要应用程序根据规则自动提取关键字，并形成关键字与文档之间的结构化对应关系。

比如现在需要查询爱好为“篮球”和“足球”的用户，那么可以直接通过倒排索引拿到对应的文档1和文档2，也就查询到了这两个用户。

3.ES索引构建过程

全文检索中提取关键字是非常重要的一步。这些预先提取出来的关键字，在Elasticsearch及全文检索的相关文献中一般称为词项（Term），文档的词项提取在Elasticsearch中称为文档分析（Analysis），是整个全文检索中较为核心的过程。这个过程必须要区分哪些是词项，哪些不是。对于英文来说，它还必须要知道apple和apples指的同一个东西，而run和running指的是同一动作。对于中文来说就更麻烦了，因为中文词语不以空格分隔，所以面临的第一难题是如何将词语分辨出来。

ES底层使用了Lucene来构建索引，一个基本的过程是先对text类型的字段进行分词，分词使用的分词器以配置mapping时指定的为准，默认使用standard分词器，对于中文分词来说，一般建议使用ik_smart或ik_max_word分词器：

暂时无法在文档外展示此内容