rch

Elasticsearch构建于Lucene之上Elasticsearch实际上是一个分布式的、实时的搜索和分析引擎它构建在Apache

Lucene搜索引擎库的基础上。

Lucene提供了全文搜索和索引功能而Elasticsearch在此基础上构建了更多功能如分布式性能、实时数据索引、聚合分析、RESTful

Elasticsearch的高级功能Elasticsearch扩展了Lucene并提供了一种更高级的搜索和分析功能。

它支持JSON文档存储分布式架构复杂的查询语言实时索引等。

简化的APIElasticsearch提供了一个简化的RESTful

API使其更易于使用和集成到应用程序中。

这使得开发人员能够轻松地构建搜索和分析功能而无需深入了解Lucene的复杂性。

分布式和水平扩展Elasticsearch专注于分布式搜索和分析可以轻松扩展到数百台甚至数千台服务器。

这使得它成为大规模数据处理和分析的有力工具。

动态索引Elasticsearch具有实时索引功能可以实时更新和检索数据适用于大量数据的变化和分析。

1.1

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

1.2

Lucene是Apache下的一个开放源代码的全文检索引擎工具包。

提供了完整的查询引擎和索引引擎部分文本分析引擎英文与德文两种西方语言。

Lucene的目的是为软件开发人员提供一个简单易用的工具包以方便的在目标系统中实现全文检索的功能。

可以使用Lucene实现全文检索。

2.2

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

在应用中为数据库中的数据提供全文检索实现。

开发独立的搜索引擎服务、系统。

对于数据量大、数据结构不固定的数据可采用全文检索方式搜索。

2.3

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

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

3.跨平台解决方案

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

2.4

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

Lucene

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

3.1

类似数据库的表的概念但是与传统表的概念会有很大的不同。

传统关系型数据库或者NoSQL数据库的表在创建时至少要定义表的Scheme定义表的主键或列等会有一些明确定义的约束。

而Lucene的Index则完全没有约束。

Lucene的Index可以理解为一个文档收纳箱你可以往内部塞入新的文档或者从里面拿出文档但如果你要修改里面的某个文档则必须先拿出来修改后再塞回去。

这个收纳箱可以塞入各种类型的文档文档里的内容可以任意定义Lucene都能对其进行索引。

3.2

用户提供的源是一条条记录它们可以是文本文件、字符串或者数据库表的一条记录等等。

一条记录经过索引之后就是以一个Document的形式存储在索引文件中的。

用户进行搜索也是以Document列表的形式返回。

一个Index内会包含多个Document。

写入Index的Document会被分配一个唯一的ID即Sequence

3.3

一个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

Lucene中索引和搜索的最小单位一个Field会由一个或多个Term组成Term是由Field经过Analyzer分词产生。

Term

Dictionary即Term词典是根据条件查找Term的基本索引。

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

3.5

一个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

DictionaryLucene中对数据索引的构建会在Segment

Flush时而非实时构建目的是为了构建最高效索引。

当然它可引入另外一套索引机制在数据实时写入时即构建但这套索引实现会与当前Segment内索引不同需要引入额外的写入时索引以及另外一套查询机制有一定复杂度。

3.6

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♪(ω)