Lucene及全文搜索实现原理

Lucene及全文搜索实现原理

全文搜索

全文搜索是指计算机索引程序通过扫描文章中的每一个词,对每一个词建立一个索引,指明该词在文章中出现的次数和位置,当用户查询时,检索程序就根据事先建立的索引进行查找,并将查找的结果反馈给用户的检索方式。这个过程类似于通过字典中的检索字表查字的过程。全文搜索搜索引擎数据库中的数据。

????全文搜索的过程主要分为两个部分,索引的建立以及索引的搜索。

国内外的全文搜索常用的检索模型主要有向量模型,布尔模型等。

布尔模型

布尔模型是第一个信息检索的模型,可能也是最受争论的模型。它利用布尔运算符连接各个检索词,然后由计算机进行逻辑运算,找出所需信息的一种检索方法。布尔定义了三种基本操作:AND,OR和NOT。

概率检索模型

多是建立在相关性理论基础上,基于对相关性的不同理解而建立了不同的概率检索模型,而且由此导出不同的排序输出原则。可以说相关性原理及排序原理是概率检索模型的理论核心。

向量模型

????向量空间模型(Vector Space Model,VSM)在上世纪70年代由信息检索领域奠基人Salton教授提出来,并成功地应用于著名的SMART文本检索系统。把对文本内容的处理简化为向量空间中的向量运算,它以空间上的相似度表达语义的相似度,直观易懂。当文档被表示为文档空间的向量,就可以通过计算向量之间的相似性来度量文档间的相似性。向量空间模型的数学模型基础是余弦相似性理论,下面先从数学推导上认识余弦相似性理论。

????在同一个N维空间中存在两个非零向量A和B:

????向量A记作

????向量B记作

????向量A和B的夹角为,那么由夹角公式可得:

????夹角余弦值是与向量的长度无关的,仅仅与向量的指向方向相关。当向量A和B向量方向完全相同时,那么两个向量之间的夹角为0,;当A向量和B向量方向完全相反时,那么两个向量之间的夹角为180度,;当A向量和B向量互相垂直时,即夹角为90度,。0度角的余弦值是1,而其他任何角度的余弦值都不大于1,并且其最小值是-1,从而通过两个向量之间的角度的余弦值确定两个向量是否大致指向相同的方向。用向量夹角余弦值来衡量相似度:

余弦相似度通常用于正空间,因此给出的值为0到1之间。如下图所示,假设两个文档doc1和doc2,doc1和doc2在向量空间中分别用向量和向量来表示。

关键词查询向量为的夹角为的夹角为。通过计算得出查询向量和doc1之间的相似性:

????计算得出查询向量和doc2之间的相似性:

????比较的大小可以得出文档1和文档哪个和查询关键词相关度更大。

Lucene

Lucene的评分公式

????向量空间模型是信息检索领域中一种成熟和基础的检索模型。这种方法以3维空间中的向量作为类比,维度就是做好索引的term,比如这里以3个主要的关键词百度、招聘、java为三个维度,通过文档在各个维度上的权重,每个文档以及查询都会在空间中有一个向量,直观的看起来,两个向量越相似,则他们的夹角越小,所以cos值越大,则两个向量越相似,同理便可以将3维空间推广到多维空间去。

????用向量空间模型,便将相关性转化为相似性,根据点积和模的定义,可以得到下式:

现在的问题就变成,如何求得每个维度上的term在文档中的权重,在向量空间模型中,特征权重的计算框架是TF*IDF框架,这里TF(Term Frequency)就是term在文档中的词频,TF值越大,说明该篇文档相对于这个term来说更加重要,因此权重应该更高;而IDF(Inverse Document Frequency)则是term在整个文档集中占的比重。IDF的主要思想是,如果包含词条t的文档越少,IDF越大,则说明词条t具有很好的类别区分能力。

????如果一个词越常见,那么分母就越大,逆文档频率就越小越接近0。分母之所以要加1,是为了避免分母为0。

????可以看到,TF-IDF与一个词在文档中的出现次数成正比,与该词在整个语言中的出现次数成反比。

有了以上基础之后可以对Lucene的公式进行简单的推导

  1. 令查询向量,文档向量
  2. 由于用户在输入查询串时,一般不会输入相同的查询词,因此简单设置

    ,


????需要注意的是只有当词都存在于q和d中才不为0。

  1. 查询向量长度,可能大家会认为由于评分时需要比较的是查询向量余文档向量的相似度,查询向量的长度对于所有文档的相似度而言是相同的,因此实际中就可以舍去,但实际并没有舍去;
  2. 对于文档向量长度,lucene并没有采用标准的公式即:,而是设置成默认的开根号(词的个数)
  3. 文档得分

实际上当不是标准公式的时候,最终的得分也就不是两个向量的余弦了。这里不是lucene的最终公式,而是给出了大体的架子。

Lucene中的完整打分公式:

coord(q,d):协调因子,它的计算是基于文档d中所包含的所有可供查询的词条数量

queryNorm:在给出每个查询条目的方差和后,计算某查询的标准化值

tf:单词t在文档d中出现的词频

idf:单词t在文档集中的比重

t.getBoost():在搜索过程中影响评分的参数

norm(t,d):字段的标准化值

?

Lucene索引建立及索引搜索

非结构化数据中所存储的信息是每个文件包含哪些字符串,也即已知文件,欲求字符串相对容易,也即是从文件到字符串的映射。而我们想搜索的信息是哪些文件包含此字符串,也即已知字符串,欲求文件,也即从字符串到文件的映射。两者恰恰相反。于是如果索引总能够保存从字符串到文件的映射,则会大大提高搜索速度。

由于从字符串到文件的映射是文件到字符串映射的反向过程,于是保存这种信息的索引称为反向索引 。

反向索引的所保存的信息一般如下:

假设我的文档集合里面有100篇文档,为了方便表示,我们为文档编号从1到100,得到下面的结构

左边保存的是一系列字符串,称为词典。每个字符串都指向包含此字符串的文档(Document)链表,此文档链表称为倒排表 (Posting List)。有了索引,便使保存的信息和要搜索的信息一致,可以大大加快搜索的速度。比如说,我们要寻找既包含字符串"lucene"又包含字符串"solr"的文档,我们只需要以下几步:

1. 取出包含字符串"lucene"的文档链表。

2. 取出包含字符串"solr"的文档链表。

3. 通过合并链表,找出既包含"lucene"又包含"solr"的文件。

看到这个地方,有人可能会说,全文检索的确加快了搜索的速度,但是多了索引的过程,两者加起来不一定比顺序扫描快多少。的确,加上索引的过程,全文检索不一定比顺序扫描快,尤其是在数据量小的时候更是如此。而对一个很大量的数据创建索引也是一个很慢的过程。然而两者还是有区别的,顺序扫描是每次都要扫描,而创建索引的过程仅仅需要一次,以后便是一劳永逸的了,每次搜索,创建索引的过程不必经过,仅仅搜索创建好的索引就可以了。这也是全文搜索相对于顺序扫描的优势之一:一次索引,多次使用。

索引结构如下

ElasticSearch

????有了单机的Lucene知识基础,可以再深入了解一下分布式的ElasticSearch。Elasticsearch是一个基于Apache Lucene的分布式可扩展的实时搜索和分析引擎。

????Elasticsearch在建立索引的时候,会将索引拆分成多个shard,每个 shard 存储部分数据。拆分多个 shard 是有好处的,一是支持横向扩展,二是提高性能。这个 shard 的数据实际是有多个备份,就是说每个 shard 都有一个?primary shard,负责写入数据,但是还有几个?replica shard。primary shard?写入数据之后,会将数据同步到其他几个?replica shard?上去。


通过这个 replica 的方案,每个 shard 的数据都有多个备份,如果某个机器宕机了,没关系啊,还有别的数据副本在别的机器上呢。

es 集群多个节点,会自动选举一个节点为 master 节点,这个 master 节点其实就是干一些管理的工作的,比如维护索引元数据、负责切换 primary shard 和 replica shard 身份等。要是 master 节点宕机了,那么会重新选举一个节点为 master 节点。

如果是非 master节点宕机了,那么会由 master 节点,让那个宕机节点上的 primary shard 的身份转移到其他机器上的 replica shard。接着你要是修复了那个宕机机器,重启了之后,master 节点会控制将缺失的 replica shard 分配过去,同步后续修改的数据之类的,让集群恢复正常。

说得更简单一点,就是说如果某个非 master 节点宕机了。那么此节点上的 primary shard 不就没了。那好,master 会让 primary shard 对应的 replica shard(在其他机器上)切换为 primary shard。如果宕机的机器修复了,修复后的节点也不再是 primary shard,而是 replica shard。

es读取数据的过程

查询,GET某一条数据,写入了某个document,这个document会自动给你分配一个全局唯一的id,doc id,同时也是根据doc id进行hash路由到对应的primary shard上面去。也可以手动指定doc id,比如用订单id,用户id。

1)客户端发送请求到任意一个node,成为coordinate node

2)coordinate node对document进行路由,将请求转发到对应的node,此时会使用round-robin随机轮询算法,在primary shard以及其所有replica中随机选择一个,让读请求负载均衡

3)接收请求的node返回document给coordinate node

4)coordinate node返回document给客户端

查询的时候根据某一id查询doc,这时候就是找一个协调节点,协调节点根据id路由找到shard然后返回数据

原文地址:https://www.cnblogs.com/kexinxin/p/11687644.html

时间: 2024-11-08 18:55:17

Lucene及全文搜索实现原理的相关文章

Apache Solr采用Java开发、基于Lucene的全文搜索服务器

http://docs.spring.io/spring-data/solr/ 首先介绍一下solr: Apache Solr (读音: SOLer) 是一个开源.高性能.采用Java开发.基于Lucene的全文搜索服务器,文档通过Http利用XML加到一个搜索集合中,查询该集合也是通过 http收到一个XML/JSON响应来实现.Solr 中存储的资源是以 Document 为对象进行存储的.每个文档由一系列的 Field 构成,每个 Field 表示资源的一个属性.Solr 中的每个 Doc

使用lucene实现全文搜索

讲解之前,先来分享一些资料 首先呢,学习任何一门新的亦或是旧的开源技术,百度其中一二是最简单的办法,先了解其中的大概,思想等等.这里就贡献一个讲解很到位的ppt.已经被我转成了PDF,便于搜藏. 其次,关于第一次编程初探,建议还是查看官方资料.百度到的资料,目前Lucene已经更新到4.9版本,这个版本需要1.7以上的JDK,所以如果还用1.6甚至是1.5的小盆友,请参考低版本,由于我用的1.6,因此在使用Lucene4.0. 这是Lucene4.0的官网文档:http://lucene.apa

Lucene全文搜索原理与使用

本文中主要是对于Lucene全文搜索的基础原理进行简单的分析,以及Lucene实现全文搜索的流程,之后就是Lucene在Java中的最简单使用:创建索引,查询索引库: 本文中使用的Lucene主要是4.10.3和6.0.0,两个版本的原理相同,但是API的使用并不相同: 1.结构化数据与非结构化数据 2.非结构化数据搜索 3.全文搜索 4.搜索如何实现 5.Lucene实现全文搜索流程 6.Lucene的API使用 1.结构化数据与非结构化数据 结构化数据:指具有固定格式或有限长度的数据,如数据

全文搜索服务器solr

什么是solr? solr是一个独立的企业级搜索应用服务器,本质是基于Lucene(一个开源的全文检索引擎工具包)的全文搜索服务器. 搜索引擎的原理是倒排索引. 倒排索引的原理,如何建立倒排索引表的.Lucene会先给所有的数据一个文档编号,将所有的内容进行分词操作,然后,将每个分词和对应的文档编号一起存储,最后将相同的分词合并,放入索引库中.当输入关键词进行搜索时,首先会对关键词也进行分词操作,然后将分词和索引库中的分词进行匹配,获取对应的文档编号,根据匹配度对文档进行排序显示. 为什么要使用

linux集群系列(三):Solr全文搜索服务器部署(Solr-5.2.1)

Solr介绍 Solr作用 Solr是一个高性能,采用Java5开发,基于Lucene的全文搜索服务器.同时对其进行了扩展,提供了比Lucene更为丰富的查询语言,同时实现了可配置.可扩展并对查询性能进行了优化,并且提供了一个完善的功能管理界面,是一款非常优秀的全文搜索引擎. Solr下载 http://archive.apache.org/dist/lucene/solr/ Solr应用部署 部署准备: 1.      Linux系统已经安装了jdk和tomcat 2.      solr压缩

全文搜索技术——Solr

1.   学习计划 1. Solr的安装及配置 a)    Solr整合tomcat b)    Solr后台管理功能介绍 c)    配置中文分析器 2. 使用Solr的后台管理索引库 a)    添加文档 b)     删除文档 c)    修改文档 d)    查询文档 3. 使用SolrJ管理索引库 a)    添加文档 b)    修改文档 c)    删除文档 d)    查询文档 4. 电商搜索案例实现 a)    案例分析 b)    案例实现 2.   需求分析 使用Solr实

初识Lucene 4.5全文搜索

近期想研究下lucene,但网络上的教程大多都是lucne 3.x版本的讲解.可是lucene版本的更新速度快的惊人,目前已经到了4.8版了,只好去查阅官方文档.虽然英文不大好,但稍微对比了下发现3.x版本至4.x版本的修改非常之大.接下来我就以4.5版来操作,分享下我对luence的初步认识. 先给大家看一张图(来至<Lucene  in  action>): 此图很形象的描述了lucene的基本流程,简而言之就是:1.创建索引:2.检索索引. 太深的道理与原理我目前也还是一知半解,所以就以

全文搜索原理简单解析

文前声明:本人只是知识的搬运工,文中许多知识和观点大多数都是来自于网络或书本,因为没有记录的习惯学习研究完,便忘记名称了,如若还记得,在文后自会添加备注. 注:这是本人的第一篇薄文,水平相形见拙,有错误之处,欢迎指正. 今年的计划是存储领域,希望能深入的了解其原理,如果能有创造性的写出一个自己的文件系统出来就更好了,到目前为止尚无动工的迹象,估计会顺延至明年了吧! 我的计划正好赶上公司的总规划,于是便接了“大数据”的活.刚开始进入这一行,走了不少弯路,说多了都是泪(这不是本文的主题,就此打住,后

记一次企业级爬虫系统升级改造(五):基于JieBaNet+Lucene.Net实现全文搜索

实现效果: 上一篇文章有附全文搜索结果的设计图,下面截一张开发完成上线后的实图: 基本风格是模仿的百度搜索结果,绿色的分页略显小清新. 目前已采集并创建索引的文章约3W多篇,索引文件不算太大,查询速度非常棒. 刀不磨要生锈,人不学要落后.每天都要学一些新东西. 基本技术介绍: 还记得上一次做全文搜索是在2013年,主要核心设计与代码均是当时的架构师写的,自己只能算是全程参与. 当时使用的是经典搭配:盘古分词+Lucene.net. 前几篇文章有说到,盘古分词已经很多年不更新了,我在Support