无论是solr还是elasticsearch,其底层都是通过lucene来实现的，我们首先学下lucene的原理。

一、lucene简介

Lucene最初是由Doug Cutting开发的，在SourceForge的网站上提供下载。在2001年9月作为高质量的开源Java产品加入到Apache软件基金会的 Jakarta家族中。

它是一个全文检索引擎的架构，提供了完整的创建索引和查询索引，以及部分文本分析的引擎，Lucene的目的是为软件开发人员提供一个简单易用的工具包，以方便在目标系统中实现全文检索的功能，或者是以此为基础建立起完整的全文检索引擎，Lucene在全文检索领域是一个经典的祖先，现在很多检索引擎都是在其基础上创建的，思想是相通的。

二、索引原理

2.1 数据的查询方式

通常来说，我们在查询数据的时候都是通过顺序扫描的方式，我们需要对每个文档从头到尾进行查看，直到找到我们需要的数据为止。但是这种效率是极低的，需要进行全部文档的扫描。

但是顺序扫描也有其优点：数据准确；缺点也是同样的明显：随着数据量也来越大，效率会越来越低。

渐渐的出现了更加快速的索引方式：mysql使用的B+tree，HashMap使用的拉链法（又叫开散列法），以及在redis的set类型中使用的跳跃表（lucene中也有使用），以及全文检索技术使用的倒排索引。本文我们主要讲解倒排索引。

2.1.2 倒排索引

lucene使用倒排索引的方式去建立文档和查询数据。

当存储数据时，将数据中的关键词拆分并提取建立索引（就像词典的目录一样）；
当查询的时候，会根据查询的内容在目录中寻找，直到找到查询内容所在的文档。

优点:
1）准确率高
2）不会因为数据量的增加导致查询速度大幅下降。（无论是中文还是英文词典而言，作为目录的数量是固定的，基本没有变化，即使数据量增大了，目录还是那么多）

缺点：
索引文件占用额外的硬盘空间。

使用场景：
适合海量数据的查询。

2.2 索引过程

索引过程

2.3 文档和索引文档

2.3.1 文档

文档documents.png

分别表示两条文档记录，id分别是1和2，每个文档有自己的field属性。

2.3.2 索引文档

如上面的文档所指示，我们在存储时会对以上的文档内容进行分词，从而建立索引文档。

分词结构如下所示：
1、2、张三、李四、黑龙江、省、黑龙江省、双鸭山、哈尔滨、市、双鸭山市、哈尔滨市。

索引文档.png

左侧表示关键字，右侧是存储文档数据的id。

2.4 底层存储结构

存储结构.png

在上图中，Segment作文数据文件是真实存在的，索引与文档作为其内部的逻辑结构。

segment

上图中还有个lock，这是控制并发写时，保证数据正确性的措施。

在以上的存储结构中，有几个关键点：

索引（index）

在lucene中，一个索引存放在一个文件夹当中。

段（segment）

一个索引由多个段组成。多个段可以合并，减少磁盘的io。

lucene的数据写入会先写如到缓存（buffer）中，当达到一定数量以后，会flush成文一个segment，写入到磁盘当中。每个segement有自己独立的索引，可以单独查询。

segment不会被修改，数据的的写入都是进行批量的追加，避免了随机写的存在，提高了吞吐量。segement可以被删除，但也不是修改segement文件，而是由另外的文件记录需要被删除的documentId。

index的查询是对多个segement文件的查询，其中也包含了处理被删除文件的处理，并对查询结果进行合并。为了进行查询优化，lucene有策略对多个segment进行优化。

文档（document）

文档是我们建立索引的基本单位。不同的文档保存在不同的段当中。一个段中可以包含多篇文档。

新添加的文档是保存在一个新的段中的，随着段的合并策略的执行，最终会被合并到同一个段当中。

域（feild）

一个文档可以包含很多不同类型的信息，它们有着不同的索引方式，可以分开索引。比如文本，时间，数值等类型。不同域的索引方式可以不同。

2.5 词典数据结构

词典数据结构指的是前面我们提到的的倒排索引，我们将文档的关键字拆分，最终组成了这个词典一样的索引结构。
下面看下常见的词典结构：

2.5.1 FST简单介绍

优点：内存占用率低，压缩率较高（2到30倍），查询快，对模糊查询支持好。
缺点：结构复杂，输入要求有序，更新不易。

举个例子：
有abd、abc、acf、ace，那么其插入的方式大致如下所示：

FST.png

2.6 效率优化

优化方式可以通过如下两种方式
1）通过设置缓存区大小，减少flush次数，调节磁盘大量io的问题。
2）索引存放位置：目前有三种方式如下所示：推荐使用MMap