引言

这也许是你全网你能找到的最详细的倒排索引的底层解读。博主把倒排索引的讲解划分为以下七个部分，理解难度递增，可根据自身需要选择依次阅读或者针对性阅读。

通常来说，应付一般的面试，理解第一部分即可。如果需要面试搜索相关业务的岗位，需要深层次理解倒排索引，可根据自身情况选择阅读。

1、倒排索引核心原理

提到ES，大多数爱好者想到的都是搜索引擎，尽管这是个误区，但是也不得不提。大数据搜索最重要的三个要素分别是 “快”、“准”、“高”。
所谓快，即搜索速度要快，搜索引擎级别的要求要达到PB级数据的秒内搜索；

所谓“准”，即搜索结果要尽量符合正常人类的预期值，在ES里我们用相关度这个概念来描述搜索结果的准确性。ES里计算相关性采用“打分机制”，ES在旧版本中使用一种叫TF/IDF的评分算法作为默认的评分算法，从 7.x 之后，默认改为BM25评分算法。

关于 BM25 算法的原理解读，推荐阅读我的博客：Elasticsearch相关度评分算法（三）：BM25（Okapi BM25）

天下武功，唯快不破。本节内容，我将围绕“ES是如何支撑大数据近实时搜索”这一话题展开，这一点非常重要。聪明的人类在探索快速检索这一技术领域已经发挥了令人难以想象的智慧，后人不必重复造轮子，要学会如何站在巨人的肩膀上。这一点，前人已经帮助我们总结很多经验。概括的说，一个优秀的搜索引擎的设计，至少应该具备以下几点要求：

高效的压缩算法
快速的编码和解码算法
合理的数据结构
通用最小化算法
​
结合以上几点，后面我将通过一个案例来讲解，倒排索引的基本原理是什么。在了解“倒排索引”之前，我们先来看一下何为“索引”。
一本汉语字典，如果我们想要从中找到某个字，通常我们会通过字典最前面的拼音检索或者是部首检索来查找。其实汉语字典的正文本身就是一个索引，比如我们要查找“吴”字，很自然的就想到了“吴”的拼音是“wu”，w在26个字母中在很靠后的位置，基本上就可以确定“吴”字的大致位置，然后按照字典序可以在w字母的汉字里精确的找到这个字，因为汉字本身就是按照字典序排列的，这种按照一定规则排序的目录在关系型数据库中一般叫做“聚集索引”。

除了这种索引，通常我们还了解一种类似于“偏旁部首”的检索方式称之为“非聚集索引”，我们这里不展开来讨论什么是聚集索引和非聚集索引。但是我们可以确定的是，不管是什么索引，它的目的都是帮助我们快速检索数据的。

在数据库领域里，索引可以概括为一种帮助我们快速检索数据的以文件形式落地的数据结构。

以MySQL为例，如图1-1所示：

左侧是MySql安装文件的data目录，右侧使我们使用数据库客户端打开数据库后的样式，左侧文件分别对应了右侧数据库中的数据库名，我们以“mysql”这个数据库为例，文件夹中每个文件都有若干个不同后缀的同名文件，分别对应右侧某个数据表，不同的后缀代表不同的数据类型，其中.frm文件代表当前文件存储的是数据表的表结构，.MYD和.MYI文件则代表了当前文件是myisam存储引擎下的数据文件和索引文件，.ibd则代表当前文件是innodb存储引擎下的索引文件，只不过innodb的数据和索引使用了同一个文件。

不管是元数据还是索引数据，他们最终都是以“文件”的形式存储在磁盘中的，只不过不同的文件内部使用的数据结构各不相同。而MySql使用的数据结构是B+Trees。但是这种数据结构并不适用于倒排索引，原因我们会在后面的文章中提到。

理解了索引的定义，我们来看一下索引在生活场景中的实际应用。如图1-2所示：

我们假设右侧表格是某个商城软件的商品表，当我们有通过关键字搜索商品列表的需求的时候，我们会执行图中左侧的SQL语句进行模糊查询，但是当数据量达到一定量的时候，搜索速度会很慢，原因是当前语句会造成“扫表”，产生大量的IO，MySql每次IO的大小默认为16KB，所以这样的查询是不被允许的，通常情况下解决的办法是在product字段上创建索引，但是这样做会产生很多问题。

首先，MySql使用的B+Trees的数据结构来存储索引数据，这种数据结构当数据量达到千万级的时候，那么每个单个节点会树的深度就已经达到甚至超过4层了，当数据量再大，查询的性能就达不到要求了，况且搜索引擎级别的数据量级动辄亿级或者十亿级，如果按照搜索引擎的要求，那这种数据结构是难以支撑的。

其次，因为每个树的每个节点大小固定为16KB，一般来说每个索引的占用的空间越大，那么单个节点所容纳的索引数量就越少。虽然B+Trees的非叶子节点不存放data，只存放索引数据，但是由于关键字搜索的需求就是在文本字段上去创建索引，所以通常我们的索引Key也都是文本类型，这就造成了单个索引占用的空间较大，B+Trees非叶子节点不存放数据这种设计相较于B-Trees（B Trees）本身就是为了减轻非叶子节点的负重，从而降低树的深度，但是显然我们这样做就违背了这一B+Trees的设计初衷，显然在文本上创建索引并不是很明智的选择，当索引字段为长文本的时候，树的深度会成指数级加大。

​而且通常情况下我们有模糊查询的需求，需要在搜索的时候前后加上“%”，但由于“最左匹配原则”，左like查询会导致索引的失效，导致SQL查询性能指数级下降。况且即便索引不会失效，目标字段的关键词中往往掺杂着一些无用字符，比如我们要查找的商品叫做“小米NFC旗舰手机”，但是我们搜索的关键词是“小米NFC手机”或者“小米手机NFC”，这种由于词序颠倒或者有干扰字符的情况就会导致我们的搜索结构不准确。

综上所述，B+Trees支撑的索引并不适合做“关键词搜索”这种需求。

那么，Lucene中的倒排索引是如何解决这类问题呢？同样我们以上文提到的场景为例，如图1-3所示：