Lucene倒排索引简述 之索引表

一、前言

倒排索引是全文检索的根基，理解了倒排索引之后才能算是入门了全文检索领域。倒排索引的的概念很简单，也很好理解。但如你知道在全文检索领域Lucene可谓是独领风骚。所以你真的了解Lucene的倒排了吗？Lucene是如何实现这个结构的呢？

倒排索引如此重要，深入理解索引结构显然是非常有益的，对于理解Lucene的索引和搜索流程都非常关键，进而可以参与自定义搜索统计的计算函数扩展开发。

本文我们将对Lucene的倒排索引的实现原理和技术细节展开具体的研读和剖析。

二、理论

在学术上，倒排索引结构非常简明，非常好理解。如下

也许你已经很了解倒排索引了，下面这张图你也已经看过很多次了。本文将从你熟悉的部分开始，一步步深入去扣这张图的一个个细节。这里有二部分内容对应分别称之为：

1. 索引，索引词表。倒排索引并不需要扫描整个文档集，而是对文档进行预处理，识别出文档集中每个词。
2. 倒排表，倒排表中的每一个条目也可以包含词在文档中的位置信息（如词位置、句子、段落），这样的结构有利于实现邻近搜索。词频和权重信息，用于文档的相关性计算。

倒排索引由两部分组成，所有独立的词列表称为索引，词对应的一系列表统称为倒排表。
—— 来自《信息检索》

如图，整个倒排索引分两部分，左边是Term Dictionary，我们就叫Dictionary吧；右边是Postings List。

1. 索引表，叫Terms Dictionary，是由于一系列的Term组成的。
2. 倒排表，称Postings List，即是由所有的Term对应的Postings组成的。

实际上Lucene所用的信息信息检索方面的术语基本跟Information Retrieval（《信息检索》原版）保持一致。比如Term、Dictionary、Postings等。

首先，有必须解释一下，每个Segment中的每个字段（Field)都有这么一个结构，且相互独立。其次，她是不可变的，即是不能添加和更改。至于不可变的原因很多，简单说有两方面：一方面是更新对磁盘来说不够友好；另一方面是写性能的影响，同时还引发各种并发问题。

我们先这么来想这个问题，如果用HashMap来实现这个结构，非常贴近这个结构了。这个结构应该是这样的，Map<String, List<Integer>>。这个Map的Key的即是Term，那它的Value即是Postings。所以它的Key的集合即是Dictionary了，这与上图的结构太贴切了。由于HashMap的Key查找还是用了HashTable，所以它还解决Dictionary的快速查找的问题，这真的是太美好了。

这就是一个hello world版的倒排索引的实现了。

三、Lucene的实现

全文搜索引擎通常是需要存储大量的文本，不仅是Postings可能会是非常巨大，同样Dictionary的大小极可能也是非常庞大。因此上面说的实现方式是完全不可能的，真正的搜索引擎的倒排索引实现都极其复杂，因为它直接影响了搜索性能和功能。

实际上Lucene的索引实现也是几经升级优化，每个版本都有或大或小的差异，这里只看Lucene6.x/7.x的实现。

Lucene的实现非常高级，它的关键特性是能够将整个排索引系列化存储在磁盘上，同时它必须是能够满足快速读写的需求。L