深入浅出Elasticsearch 的倒排索引
分词：前置知识
在创建索引之前，会对文档中的字符串进行分词。ES中字符串有两种类型，keyword和text。
keyword类型的字符串不会被分词，搜索时全匹配查询
text类型的字符串会被分词，搜索时是包含查询不同的分词器对相同字符串分词的结果大有不同，选择不同的分词器对索引的创建有很大的影响，这里使用ik分词器进行介绍：
ik_max_word分词器: 最细粒度拆分
ik_smart分词器: 最粗粒度的拆分时机：
1.存储的时候需要用到分词器
2.搜索的时候需要用到分词器工作流程：
a.标准过滤：无意义的词语（啊 的 和） 去掉，同时去掉标点符号
b.大小写过滤：标准过滤后的内容中所有英文大写装换成为英文小写
c.停用词过滤单词-文档矩阵：前置知识
| 单词1 | 单词2 | 单词3 | 单词4 | |
|---|---|---|---|---|
| 文档1 | √ | √ | ||
| 文档2 | √ | |||
| 文档3 | √ | |||
| 文档4 | √ | √ |
该矩阵是表达单词和文档两者之间包含关系的概念模型。
从横向看，每行代表文档包含了哪些单词，比如文档1包含了单词1和单词3，而不包含其它单词。
从纵向看，每列代表了某个单词存在于哪些文档。比如单词1在文档1和文档4中出现过。
简单来说，索引就是实现“单词-文档矩阵”的具体数据结构，而倒排索引则是实现了这种数据结构的具体方式。了解以上的概念，现在进入今天的主题只要你能耐心看完相信会对Elasticsearch产生不一样的见解！
1.Elasticsearch为什么需要倒排索引：
每种数据库都有自己要解决的问题（或者说擅长的领域），对应的就有自己的数据结构，
而不同的使用场景和数据结构，需要用不同的索引，才能起到最大化加快查询的目的。
对于mysql来说，是b+树，对Elasticsearch/Lucene来说，是倒排索引Elasticsearch 是建立在全文搜索引擎库 Lucene 基础上的搜索引擎，它隐藏了 Lucene 的复杂性，取而代之的提供一套简单一致的 RESTful API，不过掩盖不了它底层也是 Lucene 的事实。
Elasticsearch 的倒排索引，其实就是 Lucene 的倒排索引。
2.为什么叫倒排索引：
在没有搜索引擎时，我们是直接输入一个网址，然后获取网站内容，是这样的：
document->to->word通过文章获得里面的单词，就是所谓的【正排索引】，forward index；
后来，我们希望能够输入一个单词，找到含有这个单词，或者和这个单词有关系的文章：
word->to->document于是我们把这种索引，成为inverted index，直译过来，应该叫「反向索引」【倒排索引】
3.倒排索引的内部结构：
ES的核心组件：
请先看第一张图：（索引域）
1.Term Index（单词索引）：为了更快的找到某个单词，我们为单词建立索引
2.Term Dictionary（单词字典）：顾名思义，它里面维护的是Term，可以理解为Term的集合
是文档集合中所有单词的集合
它是保存索引的最小单位
其中记录着指向倒排列表的指针单词字典的实现：
单词词典有两种数据结构实现：B+树和Hash表
哈希表的key是单词的hash值，值是单词的链表，因为hash算法会有冲突的情况发生，所以这里的值是一个集合，里面保存着相同hash值得单词以及改词指向倒排列表的指针
3.Posting List（倒排列表）：倒排列表记录了出现过某个单词的所有文档的文档列表及单词在该文档中出现的位置信息，每条记录称为一个倒排项(Posting)。根据倒排列表，即可获知哪些文档包含某个单词。（PS：实际的倒排列表中并不只是存了文档ID这么简单，还有一些其它的信息，比如：词频（Term出现的次数）、偏移量（offset）等，可以想象成是Python中的元组，或者Java中的对象）
Lucene 的倒排索，增加了最左边的一层「字典树」term index，它不存储所有的单词，只存储单词前缀，通过字典树找到单词所在的块，也就是单词的大概位置，再在块里二分查找，找到对应的单词，再找到单词对应的文档列表，通过docId和其分片ID到对应分片抓取数据，后合并数据返回给客户端。
我们知道，每个文档都有一个ID，如果插入的时候没有指定的话，Elasticsearch会自动生成一个，因此ID字段就不多说了
原生的 Posting List 有两个痛点：
- 如何压缩以节省磁盘空间
压缩，就是尽可能降低每个数据占用的空间，同时又能让信息不失真，能够还原回来。
我们来简化下 Lucene 要面对的问题，假设有这样一个数组：
[73, 300, 302, 332, 343, 372]
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）：
- 如何快速求交并集（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
可见在文档数量不多的时候，使用 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.