lucene.net mysql_Lucene入门

最新推荐文章于 2022-06-08 20:05:59 发布

喻毅嘉

最新推荐文章于 2022-06-08 20:05:59 发布

阅读量171

点赞数

文章标签： lucene.net mysql

本文链接：https://blog.csdn.net/weixin_32659227/article/details/113402693

版权

1.Lucene与数据库全文检索比较

Lucene 是 Apache Jakarta

的一个子项目，是一个全文检索的搜索引擎库.在接触Lucene之前，我了解不少数据库都实现了全文检索功能。所以我觉得很奇怪：为什么不用数据库提供的供全文检索功能呢？我找了不少资料，车东的一篇文章《Lucene：基于Java的全文检索引擎简介》阐述的比较详细。这里摘录了其中的一段文字：

由于数据库索引不是为全文索引设计的，因此，使用like

"%keyword%"时，数据库索引是不起作用的，在使用like查询时，搜索过程又变成类似于一页页翻书的遍历过程了，所以对于含有模糊查询的数据库服务来说，LIKE对性能的危害是极大的。如果是需要对多个关键词进行模糊匹配：like"%keyword1%"

and like "%keyword2%" ...其效率也就可想而知了。

所以建立一个高效检索系统的关键是建立一个类似于科技索引一样的反向索引机制，将数据源(比如多篇文章)排序顺序存储的同时，有另外一个排好序的关键词列表，用于存储关键词==>文章映射关系，利用这样的映射关系索引：[关键词==>出现关键词的文章编号，出现次数(甚至包括位置：起始偏移量，结束偏移量)，出现频率]，检索过程就是把模糊查询变成多个可以利用索引的精确查询的逻辑组合的过程。从而大大提高了多关键词查询的效率，所以，全文检索问题归结到最后是一个排序问题。

由此可以看出模糊查询相对数据库的精确查询是一个非常不确定的问题，这也是大部分数据库对全文检索支持有限的原因。Lucene最核心的特征是通过特殊的索引结构实现了传统数据库不擅长的全文索引机制，并提供了扩展接口，以方便针对不同应用的定制。

Lucene全文索引引擎

数据库

索引

将数据源中的数据都通过全文索引一一建立反向索引

对于LIKE查询来说，数据传统的索引是根本用不上的。数据需要逐个便利记录进行GREP式的模糊匹配，比有索引的搜索速度要有多个数量级的下降。

匹配效果

通过词元(term)进行匹配，通过语言分析接口的实现，可以实现对中文等非英语的支持。

使用：like "%net%"

会把netherlands也匹配出来，

多个关键词的模糊匹配：使用like

"%com%net%"：就不能匹配词序颠倒的xxx.net..xxx.com

匹配度

有匹配度算法，将匹配程度(相似度)比较高的结果排在前面。

没有匹配程度的控制：比如有记录中net出现5词和出现1次的，结果是一样的。

结果输出

通过特别的算法，将最匹配度最高的头100条结果输出，结果集是缓冲式的小批量读取的。

返回所有的结果集，在匹配条目非常多的时候(比如上万条)需要大量的内存存放这些临时结果集。

可定制性

通过不同的语言分析接口实现，可以方便的定制出符合应用需要的索引规则(包括对中文的支持)

没有接口或接口复杂，无法定制

结论

高负载的模糊查询应用，需要负责的模糊查询的规则，索引的资料量比较大

使用率低，模糊匹配规则简单或者需要模糊查询的资料量少

全文检索和数据库应用最大的不同在于：让最相关的头100条结果满足98%以上用户的需求。和数据库全文检索相比，Lucene的创新之处：

大部分的搜索(数据库)引擎都是用B树结构来维护索引，索引的更新会导致大量的IO操作，Lucene在实现中，对此稍微有所改进：不是维护一个索引文件，而是在扩展索引的时候不断创建新的索引文件，然后定期的把这些新的小索引文件合并到原先的大索引中(针对不同的更新策略，批次的大小可以调整)，这样在不影响检索的效率的前提下，提高了索引的效率。

另外Lucene还有两个优点：

(1)Apache Lucene是一个开放源程序的搜寻器引擎

(2)可以轻易地为Java软件加入全文搜寻功能。

我想这也就是Lucene为什么这么火的原因把。

2.全文检索简介

目前比较成熟的全文检索算法有：

inverted file 倒排文件

signature file 签名文档

suffix arrays 后继数组

除此之外，全文搜索还涉及到很多复杂的技术，从索引技术到存取策略，还有压缩技术等等。所以说全文检索是一门比较前沿的技术。

做全文检索之前，要作一些预先处理，比如去除一些无意义的副词、定语和与业务无关的词语后的关键词检索，其实全文检索的关键内容在建立关键词上而不在检索本身，也就是如何将内容中的无关词语去除，那样检索的索引效率才能更高，检索本身也更有意义和价值。

TRS之类的应用都有自己的关键词知识库，这是它们成功的重要因素。同时它们对组织数据都有一定的要求，不是对一个普通的文本文件就可以检索的。

全文检索主要的应用领域是：图书馆数据库、情报数据库、专利数据库、医药数据库、办公自动化、历史资料库、电子出版系统、等等。

3.lucene简介

Lucene的知识主要分为索引、搜索、分析器、性能优化几个部分。只要掌握了这些知识，lucene运用也就可以得心应手了。

(1)lucene的包结构

org.apache.Lucene.search/ 搜索入口

org.apache.Lucene.index/ 索引入口

org.apache.Lucene.analysis/ 语言分析器

org.apache.Lucene.queryParser/ 查询分析器

org.apache.Lucene.document/ 存储结构

org.apache.Lucene.store/ 底层IO/存储结构

org.apache.Lucene.util/ 一些公用的数据结构

(2)lucene主要类

IndexWriter的主要作用是对索引进行创建,加入Document,合并各种索引段,以及控制与索引相关的各方面,他是Lucene的索引的主要操作者

InswzReader的作用是负责对索引的各种读取和维护工作.如打开一个索引,取得索引中的某个文档,获得索引中的总文档数量

Analyzer:分析器,主要用于分析搜索引擎遇到的各种文本。常用的有StandardAnalyzer分析器,StopAnalyzer分析器,WhitespaceAnalyzer分析器等。

Directory:索引存放的位置;lucene提供了两种索引存放的位置，一种是磁盘，一种是内存。相应地lucene提供了FSDirectory和RAMDirectory两个类。FSDirectory指的是在文件系统中的一个路径.因此,当Lucene向其中写入索引的时候,会直接将索引写到磁盘上.RAMDirectory则是内存中的一块区域.

Document:在Lucene中,代表一种逻辑文件,相当于一个要进行索引的单元，任何想要被索引的文件都必须转化为Document对象才能进行索引。

Field：如果把Document可以看作是数据库的一行记录，那么Field可以看作是数据库的字段.在索引中的每个Document含有一个或多个字段，具体化为Field类。每个字段相应于数据的一个片段，将在搜索时查询或从索引中重新获取。Lucene提供四个不同的字段类型，你可以从中做出选择：

Keyword—不被分析，但是被索引并逐字存储到索引中。这个类型适合于原始值需要保持原样的字段，如URL、文件系统路径、日期、个人名称、社会安全号码、电话号码等等。例如，我们在Indexer(列表1.1)中把文件系统路径作为Keyword字段。

UnIndexed

—不被分析也不被索引，但是它的值存储到索引中。这个类型适合于你需要和搜索结果一起显示的字段(如URL或数据库主键)，但是你从不直接搜索它的值。因为这种类型字段的原始值存储在索引中，这种类型不适合于存放比较巨大的值，如果索引大小是个问题的话。

UnStored—和UnIndexed相反。这个字段类型被分析并索引但是不存储在索引中。它适合于索引大量的文本而不需要以原始形式重新获得它。例如网页的主体或任休其它类型的文本文档。

Text

—被分析并索引。这就意味着这种类型的字段可以被搜索，但是要小心字段大小。如果要索引的数据是一个String，它也被存储；但如果数据(如我们的

Indexer例子)是来自一个Reader，它就不会被存储。这通常是混乱的来源，所以在使用Field.Text时要注意这个区别。

Term:Term是搜索的基本单元。与Field对象类似，它由一对字符串元素组成：字段的名称和字段的值。

IndexSearcher:是lucene中最基本的检索工具，所有的检索都会用到IndexSearcher工具;

Query:查询，lucene中支持模糊查询，语义查询，短语查询，组合查询等等,如有TermQuery,BooleanQuery,RangeQuery,WildcardQuery等一些类。