Elasticsearch 中为什么选择倒排索引而不选择 B 树索引

• • FSM

• 构建 FST

• 总结

前言

===============================================================

索引可能大家都不陌生，在用关系型数据库时，一些频繁用作查询条件的字段我们都会去建立索引来提升查询效率。在关系型数据库中，我们一般都采用 B 树索引进行存储，所以 B 树索引也是我们接触比较多的一种索引数据结构，然而在 es 中，进行全文搜索的时候却并没有选择使用 B 树 索引，而是采用的倒排索引。本文就让我们来看看 es 中的倒排索引是如何存储和检索的吧。

为什么全文索引不使用 B+ 树进行存储

================================================================================

关系型数据库，如 MySQL，其选择的是 B+ 树索引，如下图就是一颗简单的的 B+ 树示例：

上图中蓝色的表示索引值，白色的表示指针，最底层叶子节点除了存储索引值还会存储整条数据（InnoDB 引擎），而根节点和枝节点不会存储数据，B+ 树之所以这么设计就是为了使得根节点和枝节点能够存储更多的节点，因为搜索的时候从根节点开始搜索，每查询一个节点就是一次 IO 操作，所以一个节点能存储更多的索引值能减少磁盘 IO 次数。

如果有想更详细了解 B+ 树的，可以点击这里。

那么到这里我们就可以思考这个问题了，假如索引值本身就很大，那么 B+ 树是不是性能会急剧下降呢？答案是肯定的，因为当索引值很大的话，一个节点能存储的数据会大大减少（一个节点默认是 16kb 大小），B+ 树就会变得更深，每次查询数据所需要的 IO 次数也会更多。而且全文索引就是需要支持对大文本进行索引的，从空间上来说 B+ 树不适合作为全文索引，同时 B+ 树因为每次搜索都是从根节点开始往下搜索，所以会遵循最左匹配原则，而我们使用全文搜索时，往往不会遵循最左匹配原则，所以可能会导致索引失效。

总结起来 B+ 树不适合作为全文搜索索引主要有以下两个原因：

• 全文索引的文本字段通常会比较长，索引值本身会占用较大空间，从而会加大 B+ 树的深度，影响查询效率。

• 全文索引往往需要全文搜索，不遵循最左匹配原则，使用 B+ 树可能导致索引失效。

全文检索

=================================================================

在全文检索当中，我们需要对文档进行切词处理，切好之后再将切出来的词和文档进行关联，并进行索引，那么这时候我们应该如何存储关键字和文档的对应关系呢？

正排索引

---

可能大家都知道，在全文检索中（比如：Elasticsearch）用的是倒排索引，那么既然有倒排索引，自然就有正排索引。

正排索引又称之为前向索引（forward index）。我们以一篇文档为例，那么正排索引可以理解成他是用文档 id 作为索引关键字，同时记录了这篇文档中有哪些词（经过分词器处理），每个词出现的次数已经每个词在文档中的位置。

但是我们平常在搜索的时候，都是输入一个词然后要得到文档，所以很显然，正排索引并不适合于做这种查询，所以一般我们的全文检索用的都是倒排索引，但是倒排索引却并不适合用于聚合运算，所以其实在 es 中的聚合运算用的是正排索引。

倒排索引

---

倒排索引又称之为反向索引（inverted index）。和正排索引相反，倒排索引使用的是词来作为索引关键字，并同时记录了哪些文档中有这个词。

在这里我们以一个英文文档为例子，之所以选择用英文文档是因为英文分词比较简单，直接以空格进行分词即可，而中文分词相对比较复杂。

我们以 Elasticsearch 官网中下面两句话作为两位文档来分析：

Elasticsearch is the distributed search and analytics engine at the heart of the Elastic Stack.

Elasticsearch provides near real-time search and analytics for all types of data.

根据上面两句话，假设我们可以得到下面这样的一个索引结构：

| term index | term dictionary | Posting list TF |

| — | — | — |

| term 索引 | elasticsearch | [1,2] |

| term 索引 | search | [1,2] |

| term 索引 | elastic | [1] |

| term 索引 | provides | [2] |

其中：

• term index：顾名思议，这个是为 term（经过分词后的每个词） 建立的索引，也就是通过这个索引可以快速找到当前 term 的位置，从而找到对应的 Posting list。因为在 es 中，会为每个字段都建立索引（默认存储在内存中），所以当我们的数据量非常大的时候，就需要能快速定位到这个词对应的索引所在的内存位置，所以就单独为每个 term 建立了索引，这个索引一般可以选择哈希表或者 B+ 树进行索引存储。

• term dictionary：记录了文档中去重后的所有词（经过分词器处理）。

• Posting list TF：记录了含有当前词的文档以及当前词出现在文档的位置（偏移量），该项信息是一个数组，上面表格中为了简单只列举了文档 id，实际上这里会存储很多信息。

这时候假如我们搜索 Elasticsearch Elastic 这样的关键字，那么会经过以下步骤：

1. 对输入的关键字进行分词处理，得到两个词：elasticsearch 和 elastic（经过分词器之后大写字母都会转化成小写字母）。

2. 然后分别用这两个词进行搜索，搜索之后，发现 elasticsearch 在两个文档中都有出现，而 elastic 只在文档一中出现。

3. 最终的搜索结果就是文档一和文档二都返回，但是因为文档一两个词都命中了，所以相关度（分数）更高，于是文档一会排在文档二前面，这就是算分的过程。不过需要注意的是，实际的这种相关度分数算法不会这么简单，而是有专门的算法来计算，命中词多的并不一定会出现在前面。

倒排索引如何存储数据

知道了倒排索引的搜索过程，那么倒排索引的数据又是如何存储的呢？

回答这个问题之前我们先来看另一个问题，那就是建立索引的目的是什么？最直接的目的肯定是为了加快检索速度，而为了达到这个目的，那么在不考虑其他因素的情况下，必然是需要占用的空间越少越好，而为了减少占用空间，可能就需要压缩之后再进行存储，而压缩之后又涉及到解压缩，所以采用的压缩算法也需要能达到快速压缩和解压的目的。

FOR 压缩

FOR 压缩算法即 Frame Of Reference。这种算法比较简单，也有一定的局限性，因为其对存储的文档 id 有一定要求。

假设现在有一亿个文档，对应的文档 id 就是从 1 开始自增。假设现在关键字 elasticsearch 存在于 1000W 个文档中，而这 1000W 个文档恰好就是从 1 到 1000W，那么假如不采用任何压缩算法，直接进行存储需要占用多少空间？

int 类型占用了 4 个字节，而 1000W 这个数量级需要 2 的 24 次方，也就是说如果用二进制来存储，在不考虑符号位的情况下也需要 24 个 bit 才能存储，而因为 Posting list TF 是一个数组，所以为了能解析出数据，文档 id=1 的数据也需要用 24 个 bit 来进行存储，这样就会极大的浪费了空间。

为了解决这个问题，我们就需要使用 FOR 算法，FOR 算法并不直接存储文档 id，而是存储差值，像这种这么规律的文档 id，差值都是 1，而 1 转成二进制就可以只使用 1 个 bit 进行存储，这样就只需要 1000W 个 bit 的空间来进行存储就够了，相比较直接存储原始文档 id 的情况下，这种场景采用 FOR 算法大大减少了空间。

上面举的这个例子是比较理想的情况，然而实际上这种概率是比较小的，那我们再来看下面这一组文档 id：

1,9,15,45,68,323,457

这个数组计算差值后得到下面这个数组：

8,6,30,23,255,134

这个时候如果还是直接用普通差值的算法，虽然也能节省空间，但是却并不是最优的一种解决方案，那么这个时候有没有一种更高效的方法来进行存储呢？

我们观察下这个差值数组，发现这个数组可以进一步拆分成两组：

• [8,6,30,23]：这一组最大值为 30，只需要 5 个比特就能进行存储。

• [255,134]：这一组最大值为 255，需要 8 个比特就能存储。

这么拆分之后，原始数据需要用 32*7=224 个比特（原始数据直接用 int 存储），普通差值需要 8*6=48 个比特，而经过分组差值拆分之后只需要 5*4+8*2=36 个比特，进一步压缩了空间，这种优势随着数据量的增加会更加明显。

但是不管采用哪种方案都有一个问题，那就是进行差值或者拆分之后，怎么还原数据，解压的时候怎么知道差值数组内的元素占用空间大小？

所以对每一个数据，还需要一块一个字节的空间大小来存储当前数组内元素占用的比特数，所以分组并不是越细越好，假如对每一个差值元素都单独存储，那么反而会比不分组更浪费空间，反之，如果每个分组内的元素足够多，那么存储占用空间的这一个字节反带来的影响就会更小或者忽略不计。

RBM 压缩

上面例子中介绍的差值都不会大相径庭，那么假如我们差值计算之后得到的数组，其每个元素差别都很大呢？比如说下面这个文档 id 数组：

1000,62101,131385,132052,191173,196658

这个数组大家可以去计算一下差值，计算之后会发现一个大一个小，两个差值之间差距很大，所以这种方式就不适合于用 FOR 压缩，所以我们就需要有另外的压缩算法来提升效率，这就是 RBM 压缩。

RBM 压缩算法即 Roaring Bitmap，是在 2016 年由 S. Chambi、D. Lemire、O. Kaser 等人在论文《Better bitmap performance with Roaring bitmaps》与《Consistently faster and smaller compressed bitmaps with Roaring》中提出来的。

RBM 压缩算法的核心思想是：将 32 位无符号整数按照高 16 位进行划分容器，即最多可能有 65536 个 container。因为 65536 实际上就是 2 的 16 次方，而一个无符号 int 类型正好是需要 32 位进行存储，划分为高低位正好两边都是 16 位，也就是最多 65536 个。

划分之后根据高 16 位去找 container（比如高 16 位计算的结果是 1 就去找 container_1，2 就去找 container_2，依次类推），找到之后如果发现容器不存在，那么就会新建一个容器，并且把低 16 位存入容器内，如果容器存在，就直接将低 16 位存入容器。

这样就会出现一个现象：那就是容器最多有 65536 个，而每个容器内的元素也恰好最多是 65536 个元素。

也就是上面的数组经过计算就会得到以下容器（container_1 没有元素）：

如果说大家觉得上面的高低 16 位不好理解，那么可以这么理解，我们把数组中的元素全部除以 65536，对其取模，每得到一个模就创建一个容器，而其余数就放入对应的模所对应的容器中。因为一个 int 类型就是 2 的 32 次方，正好是 65536 的平方。

经过运算之后得到容器，那么容器中的元素又该如何进行存储呢？可以选择直接存储，也可以选择其他更高效的存储方式。在 RBM 算法中，总共有三种容器类型，分别采用不同的方法来存储容器中的元素：

• ArrayContainer

ArrayContainer 采用 short 数组来进行存储，因为每个容器中的元素最大值就是 65535，采用 2 个字节进行存储。这种存储方式的特点是随着元素个数的增多，所需空间会一直增大。

最后

码字不易，觉得有帮助的可以帮忙点个赞，让更多有需要的人看到

又是一年求职季，在这里，我为各位准备了一套Java程序员精选高频面试笔试真题，来帮助大家攻下BAT的offer，题目范围从初级的Java基础到高级的分布式架构等等一系列的面试题和答案，用于给大家作为参考

以下是部分内容截图

Container采用short数组来进行存储，因为每个容器中的元素最大值就是65535，采用 2` 个字节进行存储。这种存储方式的特点是随着元素个数的增多，所需空间会一直增大。

最后

码字不易，觉得有帮助的可以帮忙点个赞，让更多有需要的人看到

又是一年求职季，在这里，我为各位准备了一套Java程序员精选高频面试笔试真题，来帮助大家攻下BAT的offer，题目范围从初级的Java基础到高级的分布式架构等等一系列的面试题和答案，用于给大家作为参考

以下是部分内容截图
[外链图片转存中…(img-yWFkhxBb-1719254669949)]