ElasticSearch与Lucene是什么关系？Lucene又是什么？

一. ElasticSearch 与 Lucene 的关系

Elasticsearch（ES）和Apache Lucene之间有密切的关系，可以总结如下：

Elasticsearch构建于Lucene之上：Elasticsearch实际上是一个分布式的、实时的搜索和分析引擎，它构建在Apache Lucene搜索引擎库的基础上。Lucene提供了全文搜索和索引功能，而Elasticsearch在此基础上构建了更多功能，如分布式性能、实时数据索引、聚合分析、RESTful API等。
Elasticsearch的高级功能：Elasticsearch扩展了Lucene，并提供了一种更高级的搜索和分析功能。它支持JSON文档存储，分布式架构，复杂的查询语言，实时索引等。
简化的API：Elasticsearch提供了一个简化的RESTful API，使其更易于使用和集成到应用程序中。这使得开发人员能够轻松地构建搜索和分析功能，而无需深入了解Lucene的复杂性。
分布式和水平扩展：Elasticsearch专注于分布式搜索和分析，可以轻松扩展到数百台甚至数千台服务器。这使得它成为大规模数据处理和分析的有力工具。
动态索引：Elasticsearch具有实时索引功能，可以实时更新和检索数据，适用于大量数据的变化和分析。

1.1 结构关系图

Lucene是Apache下的一个子项目，是一个开放源代码的全文检索引擎工具包，但它不是一个完整的全文检索引擎，而是一个全文检索引擎的架构，提供了完整的查询引擎和索引引擎，它是ES实现全文检索的核心基础，索引文档以及搜索索引的的核心流程都是在Lucene中完成的。

1.2 整体处理流程

二. Apache Lucene 概述

2.1 Lucene介绍

Lucene是Apache下的一个开放源代码的全文检索引擎工具包。提供了完整的查询引擎和索引引擎，部分文本分析引擎（英文与德文两种西方语言）。Lucene的目的是为软件开发人员提供一个简单易用的工具包，以方便的在目标系统中实现全文检索的功能。可以使用Lucene实现全文检索。

2.2 Lucene适用场景

这项技术几乎适用于任何需要结构化搜索、全文搜索、分面、跨高维向量的最近邻搜索、拼写纠正或查询建议的应用程序。

在应用中为数据库中的数据提供全文检索实现。
开发独立的搜索引擎服务、系统。
对于数据量大、数据结构不固定的数据可采用全文检索方式搜索。

2.3 Lucene功能

Lucene通过一个简单的API提供了强大的功能。

1.可扩展的高性能索引

在现代硬件上超过800GB/小时
小RAM要求——只有1MB堆
增量索引与批量索引一样快
索引大小大约为索引文本大小的20-30%

2.强大、准确、高效的搜索算法

排名搜索——最好的结果首先返回
许多强大的查询类型：短语查询、通配符查询、邻近查询、范围查询等
现场搜索（例如标题、作者、内容）
高维向量的最近邻搜索
按任何字段排序
合并结果的多索引搜索
允许同时更新和搜索
灵活的刻面、突出显示、连接和结果分组
快速、节省内存和容错的建议器
可插拔排名模型，包括向量空间模型和Okapi BM25
可配置的存储引擎（编解码器）

3.跨平台解决方案

可作为Apache许可证下的开源软件，它允许您在商业和开源程序中使用Lucene
100%纯Java
其他可用的与索引兼容的编程语言的实现

2.4 Lucene架构

结构化数据搜索与非结构化数据搜索对比分析见下图：

搜索应用程序和Lucene之间的关系，也反映了利用Lucene构建搜索应用程序的流程：

三. Lucene 基本概念

在深入解读Lucene之前，先了解下Lucene的几个基本概念，以及这几个概念背后隐藏的一些内容。

3.1 Index(索引)

类似数据库的表的概念，但是与传统表的概念会有很大的不同。传统关系型数据库或者NoSQL数据库的表，在创建时至少要定义表的Scheme，定义表的主键或列等，会有一些明确定义的约束。而Lucene的Index，则完全没有约束。Lucene的Index可以理解为一个文档收纳箱，你可以往内部塞入新的文档，或者从里面拿出文档，但如果你要修改里面的某个文档，则必须先拿出来修改后再塞回去。这个收纳箱可以塞入各种类型的文档，文档里的内容可以任意定义，Lucene都能对其进行索引。

3.2 Document(文档)

用户提供的源是一条条记录，它们可以是文本文件、字符串或者数据库表的一条记录等等。一条记录经过索引之后，就是以一个Document的形式存储在索引文件中的。用户进行搜索，也是以Document列表的形式返回。

一个Index内会包含多个Document。写入Index的Document会被分配一个唯一的ID，即Sequence Number（序列号，更多被叫做DocId）。

3.3 Field(字段)

一个Document会由一个或多个Field组成，Field是Lucene中数据索引的最小定义单位。Lucene提供多种不同类型的Field，例如StringField、TextField、LongFiled或NumericDocValuesField等，Lucene根据Field的类型（FieldType）来判断该数据要采用哪种类型的索引方式（Invert Index、Store Field、DocValues或N-dimensional等）。

例如，一篇文章可以包含“标题”、“正文”、“最后修改时间”等信息域，这些信息域就是通过Field在Document中存储的。

Field有两个属性可选：存储和索引。通过存储属性你可以控制是否对这个Field进行存储；通过索引属性你可以控制是否对该Field进行索引。

如果对标题和正文进行全文搜索，所以我们要把索引属性设置为真，同时我们希望能直接从搜索结果中提取文章标题，所以我们把标题域的存储属性设置为真。但是由于正文域太大了，我们为了缩小索引文件大小，将正文域的存储属性设置为假，当需要时再直接读取文件；我们只是希望能从搜索解果中提取最后修改时间，不需要对它进行搜索，所以我们把最后修改时间域的存储属性设置为真，索引属性设置为假。上面的三个域涵盖了两个属性的三种组合，还有一种全为假的没有用到，事实上Field不允许你那么设置，因为既不存储又不索引的域是没有意义的。

3.4 Term和Term Dictionary

Lucene中索引和搜索的最小单位，一个Field会由一个或多个Term组成，Term是由Field经过Analyzer（分词）产生。Term Dictionary即Term词典，是根据条件查找Term的基本索引。

Term由两部分组成：它表示的词语和这个词语所出现的Field的名称。

3.5 Segment(段)

一个Index会由一个或多个sub-index构成，sub-index被称为Segment。Lucene的Segment设计思想，与LSM类似但又有些不同，继承了LSM中数据写入的优点，但是在查询上只能提供近实时而非实时查询。

Lucene中的数据写入会先写内存的一个Buffer（类似LSM的MemTable，但是不可读），当Buffer内数据到一定量后会被Flush成一个Segment，每个Segment有自己独立的索引，可独立被查询，但数据永远不能被更改。这种模式避免了随机写，数据写入都是Batch和Append，能达到很高的吞吐量。Segment中写入的文档不可被修改，但可被删除，删除的方式也不是在文件内部原地更改，而是会由另外一个文件保存需要被删除的文档的DocID，保证数据文件不可被修改。Index的查询需要对多个Segment进行查询并对结果进行合并，还需要处理被删除的文档，为了对查询进行优化，Lucene会有策略对多个Segment进行合并，这点与LSM对SSTable的Merge类似。

Segment在被Flush或Commit之前，数据保存在内存中，是不可被搜索的，这也就是为什么Lucene被称为提供近实时而非实时查询的原因。读了它的代码后，发现它并不是不能实现数据写入即可查，只是实现起来比较复杂。原因是Lucene中数据搜索依赖构建的索引（例如倒排依赖Term Dictionary），Lucene中对数据索引的构建会在Segment Flush时，而非实时构建，目的是为了构建最高效索引。当然它可引入另外一套索引机制，在数据实时写入时即构建，但这套索引实现会与当前Segment内索引不同，需要引入额外的写入时索引以及另外一套查询机制，有一定复杂度。

3.6 Sequence Number(序列号)

Sequence Number（后面统一叫DocId）是Lucene中一个很重要的概念，数据库内通过主键来唯一标识一行记录，而Lucene的Index通过DocId来唯一标识一个Doc。不过有几点要特别注意：

DocId实际上并不在Index内唯一，而是Segment内唯一，Lucene这么做主要是为了做写入和压缩优化。那既然在Segment内才唯一，又是怎么做到在Index级别来唯一标识一个Doc呢？方案很简单，Segment之间是有顺序的，举个简单的例子，一个Index内有两个Segment，每个Segment内分别有100个Doc，在Segment内DocId都是0-100，转换到Index级的DocId，需要将第二个Segment的DocId范围转换为100-200。
DocId在Segment内唯一，取值从0开始递增。但不代表DocId取值一定是连续的，如果有Doc被删除，那可能会存在空洞。
一个文档对应的DocId可能会发生变化，主要是发生在Segment合并时。

Lucene内最核心的倒排索引，本质上就是Term到所有包含该Term的文档的DocId列表的映射。所以Lucene内部在搜索的时候会是一个两阶段的查询，第一阶段是通过给定的Term的条件找到所有Doc的DocId列表，第二阶段是根据DocId查找Doc。Lucene提供基于Term的搜索功能，也提供基于DocId的查询功能。

DocId采用一个从0开始底层的Int32值，是一个比较大的优化，同时体现在数据压缩和查询效率上。例如数据压缩上的Delta策略、ZigZag编码，以及倒排列表上采用的SkipList等，这些优化后续会详述。

感谢您的阅读，别忘了点赞、关注、收藏一波~ Thanks♪(･ω･)ﾉ 😊