倒排索引原理 面试 倒排索引 实现

顾名思义，有倒排索引则对应肯定就有正排索引，首先介绍一下概念：

倒排索引： 

搜索引擎通常检索的场景是：给定几个关键词，找出包含关键词的文档。怎么快速找到包含某个关键词的文档就成为搜索的关键。倒排索引源于实际应用中需要根据属性的值来查找记录，lucene是基于倒排索引实现的。这种索引表中的每一项都包括一个属性值和具有该属性值的各记录的地址。由于不是由记录来确定属性值，而是由属性值来确定记录的位置，因而称为倒排索引(inverted index)。

正排索引：

正排缩影是以文档的ID为关键字，表中记录文档中每个字的位置信息，查找时扫描表中每个文档中字的信息直到找出所有包含查询关键字的文档。查询效率非常低下。

一句话描述：

倒排索引记录了某个关键字在哪些文档中，正排索引记录了文档包含了哪些关键字。

带有倒排索引的文件我们称为倒排索引文件，简称倒排文件(inverted file)。
倒排索引一般表示为一个关键词，然后是它的频度（出现的次数），位置（出现在哪一篇文章或网页中，及有关的日期，作者等信息），它相当于为互联网上几千亿页网页做了一个索引，好比一本书的目录、标签一般。读者想看哪一个主题相关的章节，直接根据目录即可找到相关的页面。不必再从书的第一页到最后一页，一页一页的查找。

倒排索引名词概念：

文档(Document)：一般搜索引擎的处理对象是互联网网页，而文档这个概念要更宽泛些，代表以文本形式存在的存储对象，相比网页来说，涵盖更多种形式，比如Word，PDF，html，XML等不同格式的文件都可以称之为文档。再比如一封邮件，一条短信，一条微博也可以称之为文档。在本书后续内容，很多情况下会使用文档来表征文本信息。

文档集合(Document Collection)：由若干文档构成的集合称之为文档集合。比如海量的互联网网页或者说大量的电子邮件都是文档集合的具体例子。

文档编号(Document ID)：在搜索引擎内部，会将文档集合内每个文档赋予一个唯一的内部编号，以此编号来作为这个文档的唯一标识，这样方便内部处理，每个文档的内部编号即称之为“文档编号”，后文有时会用DocID来便捷地代表文档编号。

单词编号(Word ID)：与文档编号类似，搜索引擎内部以唯一的编号来表征某个单词，单词编号可以作为某个单词的唯一表征。

倒排索引(Inverted Index)：倒排索引是实现“单词-文档矩阵”的一种具体存储形式，通过倒排索引，可以根据单词快速获取包含这个单词的文档列表。倒排索引主要由两个部分组成：“单词词典”和“倒排文件”。

单词词典(Lexicon)：搜索引擎的通常索引单位是单词，单词词典是由文档集合中出现过的所有单词构成的字符串集合，单词词典内每条索引项记载单词本身的一些信息以及指向“倒排列表”的指针。

倒排列表(PostingList)：倒排列表记载了出现过某个单词的所有文档的文档列表及单词在该文档中出现的位置信息，每条记录称为一个倒排项(Posting)。根据倒排列表，即可获知哪些文档包含某个单词。

倒排文件(Inverted File)：所有单词的倒排列表往往顺序地存储在磁盘的某个文件里，这个文件即被称之为倒排文件，倒排文件是存储倒排索引的物理文件。

集群(Cluster)：ES集群是一个或多个节点的集合，它们共同存储了整个数据集，并提供了联合索引以及可跨所有节点的搜索能力。

多节点组成的集群拥有冗余能力，它可以在一个或几个节点出现故障时保证服务的整体可用性。

集群靠其独有的名称进行标识，默认名称为“elasticsearch”。节点靠其集群名称来决定加入哪个ES集群，一个节点只能属一个集群。

如果不考虑冗余能力等特性，仅有一个节点的ES集群一样可以实现所有的存储及搜索功能。

节点(Node)：运行了单个实例的ES主机称为节点，它是集群的一个成员，可以存储数据、参与集群索引及搜索操作。

类似于集群，节点靠其名称进行标识，默认为启动时自动生成的随机Marvel字符名称。

用户可以按需要自定义任何希望使用的名称，但出于管理的目的，此名称应该尽可能有较好的识别性。

节点通过为其配置的ES集群名称确定其所要加入的集群。

分片(Shard)和副本(Replica)：ES的“分片(shard)”机制可将一个索引内部的数据分布地存储于多个节点，它通过将一个索引切分为多个底层物理的Lucene索引完成索引数据的分割存储功能，这每一个物理的Lucene索引称为一个分片(shard)。

每个分片其内部都是一个全功能且独立的索引，因此可由集群中的任何主机存储。创建索引时，用户可指定其分片的数量，默认数量为5个。

Shard有两种类型：primary和replica，即主shard及副本shard。

Primary shard用于文档存储，每个新的索引会自动创建5个Primary shard，当然此数量可在索引创建之前通过配置自行定义，不过，一旦创建完成，其Primary shard的数量将不可更改。

Replica shard是Primary Shard的副本，用于冗余数据及提高搜索性能。

每个Primary shard默认配置了一个Replica shard，但也可以配置多个，且其数量可动态更改。ES会根据需要自动增加或减少这些Replica shard的数量。

ES集群可由多个节点组成，各Shard分布式地存储于这些节点上。

ES可自动在节点间按需要移动shard，例如增加节点或节点故障时。简而言之，分片实现了集群的分布式存储，而副本实现了其分布式处理及冗余功能。

 

关于这些概念之间的关系，如下图所示：

倒排索引原理：

设有两篇文章1和2：

文章1的内容为：Tom lives in Guangzhou,I live in Guangzhou too. 　　

文章2的内容为：He once lived in Shanghai.

<1>取得关键词

由于倒排索引是基于关键词索引和查询的，首先我们要取得这两篇文章的关键词，通常我们需要如下处理措施： 　　

a.我们现在有的是文章内容，即一个字符串，我们先要找出字符串中的所有单词，即分词。英文单词由于用空格分隔，比较好处理。中文单词间是连在一起的需要特殊的分词处理。 　 　

b.文章中的”in”, “once” “too”等词没有什么实际意义，中文中的“的”“是”等字通常也无具体含义，这些不代表概念的词可以过滤掉 　

c.用户通常希望查“He”时能把含“he”，“HE”的文章也找出来，所以所有单词需要统一大小写。 　　

d.用户通常希望查“live”时能把含“lives”，“lived”的文章也找出来，所以需要把“lives”，“lived”还原成“live” 　　

e.文章中的标点符号通常不表示某种概念，也可以过滤掉 　　

在lucene中以上措施由Analyzer类完成。 经过上面处理后，

文章1的所有关键词为：[tom] [live] [guangzhou] [i] [live] [guangzhou] 　 　

文章2的所有关键词为：[he] [live] [shanghai]

<2>建立倒排索引

有了关键词后，我们就可以建立倒排索引了。上面的对应关系是：“文章号”对“文章中所有关键词”。倒排索引把这个关系倒过来，变成: “关键词”对“拥有该关键词的所有文章号”。

文章1，2经过倒排后变成 　　

关键词 文章号 　　 guangzhou 1 　　 he 2 　　 i 1 　　 live 1,2 　　 shanghai 2 　　 tom 1

 

通常仅知道关键词在哪些文章中出现还不够，我们还需要知道关键词在文章中出现次数和出现的位置，通常有两种位置：

a.字符位置，即记录该词是文章中第几个字符（优点是关键词亮显时定位快）；

b.关键词位置，即记录该词是文章中第几个关键词（优点是节约索引空间、词组（phase）查询快），lucene中记录的就是这种位置。 　　

加上“出现频率”和“出现位置”信息后，我们的索引结构变为： 　　

关键词 文章号[出现频率] 出现位置 　　 guangzhou 1[2] 3，6 　　 he 2[1] 1 　　 i 1[1] 4 　　 live 1[2] 2，5, 2[1] 2 　　 shanghai 2[1] 3 　　 tom 1[1] 1

以live 这行为例我们说明一下该结构：live在文章1中出现了2次，文章2中出现了一次，它的出现位置为“2,5,2”这表示什么呢？我们需要结合文章号和出现频率来分析，文章1中出现了2次，那么“2,5”就表示live在文章1中出现的两个位置，文章2中出现了一次，剩下的“2”就表示live是文章2中第 2个关键字。

单词词典：

单词词典是倒排索引中非常重要的组成部分，它用来维护文档集合中出现过的所有单词的相关信息，同时用来记载某个单词对应的倒排列表在倒排文件中的位置信息。在支持搜索时，根据用户的查询词，去单词词典里查询，就能够获得相应的倒排列表，并以此作为后续排序的基础。
对于一个规模很大的文档集合来说，可能包含几十万甚至上百万的不同单词，能否快速定位某个单词，这直接影响搜索时的响应速度，所以需要高效的数据结构来对单词词典进行构建和查找，常用的数据结构包括哈希加链表结构和树形词典结构。

1. 哈希加链表
下图是这种词典结构的示意图。这种词典结构主要由两个部分构成：

主体部分是哈希表，每个哈希表项保存一个指针，指针指向冲突链表，在冲突链表里，相同哈希值的单词形成链表结构。之所以会有冲突链表，是因为两个不同单词获得相同的哈希值，如果是这样，在哈希方法里被称做是一次冲突，可以将相同哈希值的单词存储在链表里，以供后续查找。

　　　　　　　　　　　　　　　　　　　　　　

　　在建立索引的过程中，词典结构也会相应地被构建出来。比如在解析一个新文档的时候，对于某个在文档中出现的单词T，首先利用哈希函数获得其哈希值，之后根据哈希值对应的哈希表项读取其中保存的指针，就找到了对应的冲突链表。如果冲突链表里已经存在这个单词，说明单词在之前解析的文档里已经出现过。如果在冲突链表里没有发现这个单词，说明该单词是首次碰到，则将其加入冲突链表里。通过这种方式，当文档集合内所有文档解析完毕时，相应的词典结构也就建立起来了。

       在响应用户查询请求时，其过程与建立词典类似，不同点在于即使词典里没出现过某个单词，也不会添加到词典内。以图7为例，假设用户输入的查询请求为单词3，对这个单词进行哈希，定位到哈希表内的2号槽，从其保留的指针可以获得冲突链表，依次将单词3和冲突链表内的单词比较，发现单词3在冲突链表内，于是找到这个单词，之后可以读出这个单词对应的倒排列表来进行后续的工作，如果没有找到这个单词，说明文档集合内没有任何文档包含单词，则搜索结果为空。

2. 树形结构
       B树（或者B+树）是另外一种高效查找结构，下图是一个 B树结构示意图。B树与哈希方式查找不同，需要字典项能够按照大小排序（数字或者字符序），而哈希方式则无须数据满足此项要求。
       B树形成了层级查找结构，中间节点用于指出一定顺序范围的词典项目存储在哪个子树中，起到根据词典项比较大小进行导航的作用，最底层的叶子节点存储单词的地址信息，根据这个地址就可以提取出单词字符串。

　　　　　　　　　　　　　　　　

不可变性

写入磁盘的倒排索引是不可变的，它有如下好处： 
* 不需要锁。如果从来不需要更新一个索引，就不必担心多个程序同时尝试修改。 
* 一旦索引被读入文件系统的缓存(译者:在内存)，它就一直在那儿，因为不会改变。只要文件系统缓存有足够的空间，大部分的读会直接访问内存而不是磁盘。这有助于性能提升。 
* 在索引的声明周期内，所有的其他缓存都可用。它们不需要在每次数据变化了都重建，因为数据不会变。 
* 写入单个大的倒排索引，可以压缩数据，较少磁盘IO和需要缓存索引的内存大小。

当然，不可变的索引有它的缺点，首先是它不可变！你不能改变它。如果想要搜索一个新文档，必须重见整个索引。这不仅严重限制了一个索引所能装下的数据，还有一个索引可以被更新的频次。

索引和分片

Elasticsearch底层依赖的Lucene，引入了per-segment search的概念。一个段(segment)是有完整功能的倒排索引，但是现在Lucene中的索引指的是段的集合。  

一个Lucene索引在Elasticsearch称为分片，一个Elasticsearch索引是分片的集合。

Elasticsearch在索引中搜索时，它发送查询到每一个属于索引的分片，然后合并每个分片的结果到一个全局的结果集。

按段写入磁盘的流程如下：

    1、新文档的Lucene索引到达内存缓存

    

     2、提交后新的段添加到提交点，并清空内存缓存

    

    3、在从内存缓存提交到磁盘的过程中，文档会先被写入到文件系统缓存，这一步的代价比刷新到磁盘的代价低，而在文件缓存就可以像其他文件一样被打开读取。而Lucene在此时就可以对这个未完成提交的文档进行搜索。

    

    Elasticsearch中，写入和打开一个新段的过程叫refresh，默认情况每个分片每秒自动刷新一次，所以称Elasticsearch是近实时搜索的。文档的变化并不是立即对搜索可见，但会在一秒之内变为可见。

段合并

    Elasticsearch通过后台进行段合并，合并时会将旧的已删除的文档从文件系统清除。

    1、两个提交了的段和一个未提交的段正在被合并到一个更大的段

    

    2、一旦合并结束，老的段被删除

    

 

持久化变更

没用fsync同步文件系统缓存到磁盘，我们不能确保电源失效，甚至正常退出应用后，数据的安全。为了ES的可靠性，需要确保变更持久化到磁盘。

我们说过一次全提交同步段到磁盘，写提交点，这会列出所有的已知的段。在重启，或重新打开索引时，ES使用这次提交点决定哪些段属于当前的分片。

当我们通过每秒的刷新获得近实时的搜索，我们依然需要定时地执行全提交确保能从失败中恢复。但是提交之间的文档怎么办？我们也不想丢失它们。

ES增加了事务日志（translog），来记录每次操作。有了事务日志，过程现在如下：

2. 当一个文档被索引，它被加入到内存缓存，同时加到事务日志。
   图1：新的文档加入到内存缓存，同时写入事务日志 



3. refresh使得分片的进入如下图描述的状态。每秒分片都进行refeash：

• 内存缓冲区的文档写入到段中，但没有fsync。
• 段被打开，使得新的文档可以搜索。
• 缓存被清除

图2：经过一次refresh，缓存被清除，但事务日志没有 

1. 随着更多的文档加入到缓存区，写入日志，这个过程会继续
   图3：事务日志会记录增长的文档
2. 不时地，比如日志很大了，新的日志会创建，会进行一次全提交：

• 内存缓存区的所有文档会写入到新段中。
• 清除缓存
• 一个提交点写入硬盘
• 文件系统缓存通过fsync操作flush到硬盘
• 事务日志被清除

事务日志记录了没有flush到硬盘的所有操作。当故障重启后，ES会用最近一次提交点从硬盘恢复所有已知的段，并且从日志里恢复所有的操作。

事务日志还用来提供实时的CRUD操作。当你尝试用ID进行CRUD时，它在检索相关段内的文档前会首先检查日志最新的改动。这意味着ES可以实时地获取文档的最新版本。

图4：flush过后，段被全提交，事务日志清除 

##flush API 
在ES中，进行一次提交并删除事务日志的操作叫做 flush。分片每30分钟，或事务日志过大会进行一次flush操作。

flush API可用来进行一次手动flush： 
“`Javascript 
POST /blogs/_flush <1>

POST /_flush?wait_for_ongoing <2> 
`` 
- <1> flush索引blogs` 
- <2> flush所有索引，等待操作结束再返回

你很少需要手动flush，通常自动的就够了。

当你要重启或关闭一个索引，flush该索引是很有用的。当ES尝试恢复或者重新打开一个索引时，它必须重放所有事务日志中的操作，所以日志越小，恢复速度越快。

跨分片查询

ES是通过hash(文档ID) % 主分片数来确认分片的位置的，因为ES的主分片数量不可变

跨分片查询时，客户端发送一个 search 请求到 Node 3 ， Node 3 会创建一个大小为 from + size 的空优先队列。
Node 3 将查询请求转发到索引的每个主分片或副本分片中。每个分片在本地执行查询并添加结果到大小为 from + size 的本地有序优先队列中。
每个分片返回各自优先队列中所有文档的 ID 和排序值给协调节点，也就是 Node 3 ，它合并这些值到自己的优先队列中来产生一个全局排序后的结果列表。

删除和更新

段是不可改变的，所以既不能从把文档从旧的段中移除，也不能修改旧的段来进行反映文档的更新。 取而代之的是，每个提交点会包含一个 .del 文件，文件中会列出这些被删除文档的段信息。

当一个文档被 “删除” 时，它实际上只是在 .del 文件中被 标记 删除。一个被标记删除的文档仍然可以被查询匹配到， 但它会在最终结果被返回前从结果集中移除。

文档更新也是类似的操作方式：当一个文档被更新时，旧版本文档被标记删除，文档的新版本被索引到一个新的段中。 可能两个版本的文档都会被一个查询匹配到，但被删除的那个旧版本文档在结果集返回前就已经被移除。

在 段合并 , 我们展示了一个被删除的文档是怎样被文件系统移除的。

合并段

通过每秒自动刷新创建新的段，用不了多久段的数量就爆炸了。有太多的段是一个问题。每个段消费文件句柄，内存，cpu资源。更重要的是，每次搜索请求都需要依次检查每个段。段越多，查询越慢。

ES通过后台合并段解决这个问题。小段被合并成大段，再合并成更大的段。

这是旧的文档从文件系统删除的时候。旧的段不会再复制到更大的新段中。

这个过程你不必做什么。当你在索引和搜索时ES会自动处理。这个过程如图：两个提交的段和一个未提交的段合并为了一个更大的段所示：

1. 索引过程中，refresh会创建新的段，并打开它。
2. 合并过程会在后台选择一些小的段合并成大的段，这个过程不会中断索引和搜索。
   图1：两个提交的段和一个未提交的段合并为了一个更大的段
3. 下图描述了合并后的操作：

• 新的段flush到了硬盘。
• 新的提交点写入新的段，排除旧的段。
• 新的段打开供搜索。
• 旧的段被删除。

图2：段合并完后，旧的段被删除 

合并大的段会消耗很多IO和CPU，如果不检查会影响到搜素性能。默认情况下，ES会限制合并过程，这样搜索就可以有足够的资源进行。