不愧是我，一晚上教会了女神倒排索引

你将花费10分钟读完本篇文章，读完本文你将：

• 熟悉索引再Elasticsearch的作用
• 熟悉正排索引和倒排索引的原理区别
• 掌握索引的压缩算法原理

引言

这是一个安静的晚上，我在峡谷里打团，突然微信弹出一串消息，我一看，原来是女神又找我聊天。

正排索引

倒排索引

举个栗子

假设八佾有个朋友，但这个朋友，不是八佾本人。在农历新年给领导写信，但是有两个领导是八佾的朋友很想骂sillybee的，于是他大胆的在信中这么写。

doc1:"dear leader ,you sillybee"

doc2:"dear leader ,i have to thank a happy silybe new year "

doc3:"dear leader ,i have to say happy new year"

三封已经封好的信， 八佾的朋友是个聪明的IT从业工作者(但他远没你想的那么聪明)，担心自己分不清三封信，于是 他记录下了这么一张表。

我想帮他向你们解释一下这张表，第一列是出现的单词，第二列是单词出现的文档位置。例如，dear这个单词出现在文档1，文档2和文档3。sillybee这个单词出现在文档1中，这样就能快速找到文档出现的位置了。

下个定义

正排索引和倒排索引的应用场景

倒排索引的压缩算法

FOR

FOR的全称是Frame Of Reference，主要思想是先对DOC ID列表进行排序，之后使用差值的方式进一步压缩，这样需要表示的数字更小，占的位数少，需要空间就更少。这么说可能太抽象了。

RBM

由于拉链归并的思想，Elasticsearch对一些常用的过滤器进行了缓存，用来加速一些过滤器的执行，因此带来了几个问题：

1. 因为不能缓存所有的过滤器，所以压缩比例对于倒排索引的编码匹配来说不那么重要
2. 我们需要加速一些重复执行的过滤器，因此一个好的数据结构来说很重要
3. 过滤器存储在内存中，而正排表基本上是在磁盘上

面对此种情况，Elasticsearch列举了一些对应的方案，进行了均衡。

第一种方式：整型数组

最直接的选择就是数组，因为数据的遍历性，可以极大的提速。然而压缩性却很难保证。如果你需要存储100Mb的文档，那么你就至少需要400Mb的空间。

第二种方式：bitmap

位图是一个数组，其中每个条目只占用一位，因此它们只有两个可能的值：0 或 1。

为了知道 docID 是否包含在位图中，需要读取索引 docID 处的值。 0 表示该集合不包含此 docID，而 1 表示该集合包含此 docID。迭代需要计算连续的零，这实际上非常快，因为 CPU 有专门的指令。如果我们与整型 相比，密集过滤器的内存使用率要好得多，因为我们现在只需要 100M 位 = 12.5MB。

但是这种情况下会有稀疏集的问题：虽然我们的第一个选项每次匹配需要 4 个字节，但现在无论有多少匹配，我们都需要 12.5MB 的内存。

第三种方式： roaring bitmaps

RBM是为了兼顾数组的遍历性和位图的低存储空间。具体的过程是这样的：

八佾Talk

冉求曰：”非不说子之道，力不足也。“

子曰：”力不足者，中道而废。今女画。“