倒排索引简介

一、前言

最近接触的几个项目都使用到了 Elasticsearch (以下简称 ES ) 来存储数据和对数据进行搜索分析，就对 ES 进行了一些学习。本文整理自我自己的一次技术分享。

本文不会关注 ES 里面的分布式技术、相关 API 的使用，而是专注分享下 ”ES 如何快速检索“这个主题上面。这个也是我在学习之前对 ES 最感兴趣的部分。

本文大致包括以下内容：

1. 关于搜索传统关系型数据库和 ES 的差别
2. 搜索引擎原理细究倒排索引
3. 倒排索引具体是个什么样子的（posting list -> term dic -> term index）
4. 关于 postings list 的一些巧技 （FOR、Roaring Bitmaps）
5. 如何快速做联合查询？

二、关于搜索

先设想一个关于搜索的场景，假设我们要搜索一首诗句内容中带“前”字的古诗，

 用 传统关系型数据库和 ES 实现会有什么差别？

如果用像 MySQL 这样的 RDBMS 来存储古诗的话，我们应该会去使用这样的 SQL 去查询

select name from poems where content like "%前%";

这种我们称为顺序扫描法，需要遍历所有的记录进行匹配。

不但效率低，而且不符合我们搜索时的期望，比如我们在搜索“ABCD"这样的关键词时，通常还希望看到"A","AB","CD",“ABC”的搜索结果。

于是乎就有了专业的搜索引擎，比如我们今天的主角 -- ES。

搜索引擎原理

搜索引擎的搜索原理简单概括的话可以分为这么几步，

 内容爬取，停顿词过滤比如一些无用的像"的"，“了”之类的语气词/连接词内容分词，提取关键词根据关键词建立倒排索引用户输入关键词进行搜索这里我们就引出了一个概念，也是我们今天的要剖析的重点 - 倒排索引。也是 ES 的核心知识点。

如果你了解 ES 应该知道，ES 可以说是对 Lucene 的一个封装，里面关于倒排索引的实现就是通过 lucene 这个 jar 包提供的 API 实现的，所以下面讲的关于倒排索引的内容实际上都是 lucene 里面的内容。

三、倒排索引

正排索引：从文档里搜索一个关键字（文档->关键字）。优点：易维护。缺点：搜索的耗时太长。

倒排索引：从关键字搜索文档（关键字->文档）。优点：搜索耗时短。缺点：不易维护。

首先我们还不能忘了我们之前提的搜索需求，先看下建立倒排索引之后，我们上述的查询需求会变成什么样子，

 这样我们一输入“前”，借助倒排索引就可以直接定位到符合查询条件的古诗。

当然这只是一个很大白话的形式来描述倒排索引的简要工作原理。在 ES 中，这个倒排索引是具体是个什么样的，怎么存储的等等，这些才是倒排索引的精华内容。

1. 几个概念

在进入下文之前，先描述几个前置概念。

term

关键词这个东西是我自己的讲法，在 ES 中，关键词被称为 term。

postings list

还是用上面的例子，

{静夜思, 望庐山瀑布}

是 "前" 这个 term 所对应列表。在 ES 中，这些被描述为所有包含特定 term 文档的 id 的集合。由于整型数字 integer 可以被高效压缩的特质，integer 是最适合放在 postings list 作为文档的唯一标识的，ES 会对这些存入的文档进行处理，转化成一个唯一的整型 id。

再说下这个 id 的范围，在存储数据的时候，在每一个 shard 里面，ES 会将数据存入不同的 segment，这是一个比 shard 更小的分片单位，这些 segment 会定期合并。在每一个 segment 里面都会保存最多 2^31 个文档，每个文档被分配一个唯一的 id，从0到(2^31)-1。

 相关的名词都是 ES 官方文档给的描述，后面参考材料中都可以找到出处。

2. 索引内部结构

上面所描述的倒排索引，仅仅是一个很粗糙的模型。真的要在实际生产中使用，当然还差的很远。

在实际生产场景中，比如 ES 最常用的日志分析，日志内容进行分词之后，可以得到多少的 term？

那么如何快速的在海量 term 中查询到对应的 term 呢？遍历一遍显然是不现实的。

term dictionary

于是乎就有了 term dictionary，ES 为了能快速查找到 term，将所有的 term 排了一个序，二分法查找。是不是感觉有点眼熟，这不就是 MySQL 的索引方式的，直接用 B+树建立索引词典指向被索引的数据。

term index

但是问题又来了，你觉得 Term Dictionary 应该放在哪里？肯定是放在内存里面吧？磁盘 io 那么慢。就像 MySQL 索引就是存在内存里面了。

但是如果把整个 term dictionary 放在内存里面会有什么后果呢？

内存爆了...

别忘了，ES 默认可是会对全部 text 字段进行索引，必然会消耗巨大的内存，为此 ES 针对索引进行了深度的优化。在保证执行效率的同时，尽量缩减内存空间的占用。

于是乎就有了 term index。

Term index 从数据结构上分类算是一个“Trie 树”，也就是我们常说的字典树。这是一种专门处理字符串匹配的数据结构，用来解决在一组字符串集合中快速查找某个字符串的问题。

这棵树不会包含所有的 term，它包含的是 term 的一些前缀（这也是字典树的使用场景，公共前缀）。通过 term index 可以快速地定位到 term dictionary 的某个 offset，然后从这个位置再往后顺序查找。就想右边这个图所表示的。（怎么样，像不像我们查英文字典，我们定位 S 开头的第一个单词，或者定位到 Sh 开头的第一个单词，然后再往后顺序查询）

lucene 在这里还做了两点优化，一是 term dictionary 在磁盘上面是分 block 保存的，一个 block 内部利用公共前缀压缩，比如都是 Ab 开头的单词就可以把 Ab 省去。二是 term index 在内存中是以 FST（finite state transducers）的数据结构保存的。

FST 有两个优点：

空间占用小。通过对词典中单词前缀和后缀的重复利用，压缩了存储空间查询速度快。O(len(str)) 的查询时间复杂度。

OK，现在我们能得到 lucene 倒排索引大致是个什么样子的了。

单词-索引，单词-词典，倒排-列表三部分组成

 四、关于 postings list 的一些巧技

原生的 Posting List 有两个痛点：

• 如何压缩以节省磁盘空间
• 如何快速求交并集（intersections and unions）

先来聊聊压缩。

我们来简化下 Lucene 要面对的问题，假设有这样一个数组：

[73, 300, 302, 332, 343, 372]

如何把它进行尽可能的压缩？

Lucene 里，数据是按 Segment 存储的，每个 Segment 最多存 65536 个文档 ID， 所以文档 ID 的范围，从 0 到 2^16-1，所以如果不进行任何处理，那么每个元素都会占用 2 bytes ，对应上面的数组，就是 6 * 2 = 12 bytes.

怎么压缩呢？

压缩，就是尽可能降低每个数据占用的空间，同时又能让信息不失真，能够还原回来。

Step 1：Delta-encode —— 增量编码

我们只记录元素与元素之间的增量，于是数组变成了：

[73, 227, 2, 30, 11, 29]

Step 2：Split into blocks —— 分割成块

Lucene里每个块是 256 个文档 ID，这样可以保证每个块，增量编码后，每个元素都不会超过 256（1 byte）.

为了方便演示，我们假设每个块是 3 个文档 ID：

[73, 227, 2], [30, 11, 29]

Step 3：Bit packing —— 按需分配空间

对于第一个块，[73, 227, 2]，最大元素是227，需要 8 bits，好，那我给你这个块的每个元素，都分配 8 bits的空间。

但是对于第二个块，[30, 11, 29]，最大的元素才30，只需要 5 bits，那我就给你每个元素，只分配 5 bits 的空间，足矣。

这一步，可以说是把吝啬发挥到极致，精打细算，按需分配。

以上三个步骤，共同组成了一项编码技术，Frame Of Reference（FOR）：

Roaring bitmaps

接着来聊聊 Posting List 的第二个痛点 —— 如何快速求交并集（intersections and unions）。

在 Lucene 中查询，通常不只有一个查询条件，比如我们想搜索：

• 含有“生存”相关词语的文档
• 文档发布时间在最近一个月
• 文档发布者是平台的特约作者

这样就需要根据三个字段，去三棵倒排索引里去查，当然，磁盘里的数据，上一节提到过，用了 FOR 进行压缩，所以我们要把数据进行反向处理，即解压，才能还原成原始的文档 ID，然后把这三个文档 ID 数组在内存中做一个交集。

即使没有多条件查询， Lucene 也需要频繁求并集，因为 Lucene 是分片存储的。

同样，我们把 Lucene 遇到的问题，简化成一道算法题。

假设有下面三个数组：

[64, 300, 303, 343]

[73, 300, 302, 303, 343, 372]

[303, 311, 333, 343]

求它们的交集。

Option 1: Integer 数组

直接用原始的文档 ID ，可能你会说，那就逐个数组遍历一遍吧，遍历完就知道交集是什么了。

其实对于有序的数组，用跳表（skip table）可以更高效，这里就不展开了，因为不管是从性能，还是空间上考虑，Integer 数组都不靠谱，假设有100M 个文档 ID，每个文档 ID 占 2 bytes，那已经是 200 MB，而这些数据是要放到内存中进行处理的，把这么大量的数据，从磁盘解压后丢到内存，内存肯定撑不住。

Option 2: Bitmap

假设有这样一个数组：

[3,6,7,10]

那么我们可以这样来表示：

[0,0,1,0,0,1,1,0,0,1]

看出来了么，对，我们用 0 表示角标对应的数字不存在，用 1 表示存在。

这样带来了两个好处：

• 节省空间：既然我们只需要0和1，那每个文档 ID 就只需要 1 bit，还是假设有 100M 个文档，那只需要 100M bits = 100M * 1/8 bytes = 12.5 MB，比之前用 Integer 数组 的 200 MB，优秀太多
• 运算更快：0 和 1，天然就适合进行位运算，求交集，「与」一下，求并集，「或」一下，一切都回归到计算机的起点

Option 3: Roaring Bitmaps

细心的你可能发现了，bitmap 有个硬伤，就是不管你有多少个文档，你占用的空间都是一样的，之前说过，Lucene Posting List 的每个 Segement 最多放 65536 个文档ID，举一个极端的例子，有一个数组，里面只有两个文档 ID：

[0, 65535]

用 Bitmap，要怎么表示？

[1,0,0,0,….(超级多个0),…,0,0,1]

你需要 65536 个 bit，也就是 65536/8 = 8192 bytes，而用 Integer 数组，你只需要 2 * 2 bytes = 4 bytes

呵呵，死板的 bitmap。可见在文档数量不多的时候，使用 Integer 数组更加节省内存。

我们来算一下临界值，很简单，无论文档数量多少，bitmap都需要 8192 bytes，而 Integer 数组则和文档数量成线性相关，每个文档 ID 占 2 bytes，所以：

8192 / 2 = 4096

当文档数量少于 4096 时，用 Integer 数组，否则，用 bitmap.

这里补充一下 Roaring bitmaps 和 之前讲的 Frame Of Reference 的关系。
Frame Of Reference 是压缩数据，减少磁盘占用空间，所以当我们从磁盘取数据时，也需要一个反向的过程，即解压，解压后才有我们上面看到的这样子的文档ID数组：[73, 300, 302, 303, 343, 372] ，接着我们需要对数据进行处理，求交集或者并集，这时候数据是需要放到内存进行处理的，我们有三个这样的数组，这些数组可能很大，而内存空间比磁盘还宝贵，于是需要更强有力的压缩算法，同时还要有利于快速的求交并集，于是有了Roaring Bitmaps 算法。
另外，Lucene 还会把从磁盘取出来的数据，通过 Roaring bitmaps 处理后，缓存到内存中，Lucene 称之为 filter cache. 

五、总结

下面我们来做一个技术总结

为了能够快速定位到目标文档，ES 使用倒排索引技术来优化搜索速度，虽然空间消耗比较大，但是搜索性能提高十分显著。为了能够在数量巨大的 terms 中快速定位到某一个 term，同时节约对内存的使用和减少磁盘 io 的读取，lucene 使用 "term index -> term dictionary -> postings list" 的倒排索引结构，通过 FST 压缩放入内存，进一步提高搜索效率。为了减少 postings list 的磁盘消耗，lucene 使用了 FOR（Frame of Reference）技术压缩，带来的压缩效果十分明显。ES 的 filter 语句采用了 Roaring Bitmap 技术来缓存搜索结果，保证高频 filter 查询速度的同时降低存储空间消耗。在联合查询时，在有 filter cache 的情况下，会直接利用位图的原生特性快速求交并集得到联合查询结果，否则使用 skip list 对多个 postings list 求交并集，跳过遍历成本并且节省部分数据的解压缩 cpu 成本Elasticsearch 的索引思路

将磁盘里的东西尽量搬进内存，减少磁盘随机读取次数 (同时也利用磁盘顺序读特性)，结合各种奇技淫巧的压缩算法，用及其苛刻的态度使用内存。

所以，对于使用 Elasticsearch 进行索引时需要注意:

不需要索引的字段，一定要明确定义出来，因为默认是自动建索引的同样的道理，对于 String 类型的字段，不需要 analysis 的也需要明确定义出来，因为默认也是会 analysis 的选择有规律的 ID 很重要，随机性太大的 ID(比如 Java 的 UUID) 不利于查询最后说一下，技术选型永远伴随着业务场景的考量，每种数据库都有自己要解决的问题（或者说擅长的领域），对应的就有自己的数据结构，而不同的使用场景和数据结构，需要用不同的索引，才能起到最大化加快查询的目的。

这篇文章讲的虽是 Lucene 如何实现倒排索引，如何精打细算每一块内存、磁盘空间、如何用诡谲的位运算加快处理速度，但往高处思考，再类比一下 MySQL，你就会发现，虽然都是索引，但是实现起来，截然不同。笼统的来说，b-tree 索引是为写入优化的索引结构。当我们不需要支持快速的更新的时候，可以用预先排序等方式换取更小的存储空间，更快的检索速度等好处，其代价就是更新慢，就像 ES。