搜索引擎Lucene
第一章Lucene简介
Lucene是apache软件基金会jakarta项目组的一个子项目，是一个开放源代码[的全文检索引擎工具包，即它不是一个完整的全文检索引擎，而是一个全文检索引擎的架构，提供了完整的查询引擎和索引引擎，部分文本分析引擎（英文与德文两种西方语言）。Lucene的目的是为软件开发人员提供一个简单易用的工具包，以方便的在目标系统中实现全文检索的功能，或者是以此为基础建立起完整的全文检索引擎。
第二章lucene索引的建立
的五个基础类
索引的建立，Lucene 提供了五个基础类，分别是Document, Field, IndexWriter, Analyzer, Directory。以下是他们的用途：
Document
Document的含义为文档，在Lucene中，它代表一种逻辑文件。Lucene本身无法对物理文件建立索引，而只能识别并处理Document的类型文件。Lucene从Document取出相关的数据源并根据属性配置进行相应的处理。
Field
对象是用来描述一个文档的某个属性的
lucene中的field也具有一些特定的类型如
在中，Field内部包含两个静态的内部类分别是Store和Index详细的描述了Field的属性，它们分别表示Field的储存方式和索引方式。
Store类有3个公有的静态属性：
:表示该Field不需要储存。
:表示该Field需要储存。
:表示使用压缩方式来保存这个Field的值。
Index有4个公有的静态属性：
:表示该Field不需要索引，也就是用户不需要去查找该Field的值。
:表示该Field先被分词再被索引。
TOKENIZED:表示不对该Field进行分词，但是要对他进行索引，也就是该Field会被用户查找。
:表示对该Field进行索引，但是不使用Analyzer，同时禁止它参加评分，主要是为了减少内存的消耗。
Analyzer
在一个文档被索引之前，首先需要对文档内容进行分词处理，这部分工作就是由Analyzer 来做的。Analyzer 类是一个抽象类，它有多个实现。针对不同的语言和应用需要选择适合的Analyzer。Analyzer 把分词后的内容交给IndexWriter 来建立索引。
IndexWriter
IndexWriter 是Lucene 用来创建索引的一个核心的类，他的作用是把一个个的Document 对象加到索引中来。
Directory
这个类代表了Lucene 的索引的存储的位置，这是一个抽象类，它目前有两个实现，第一个是FSDirectory，它表示一个存储在文件系统中的索引的位置。第二个是RAMDirectory，它表示一个存储在内存当中的索引的位置。
建立索引过程
的初始化
在Lucene中，IndexWrite的主要作用是对索引进行创建，加入Document,合并各种索引段，以及控制与索引相关的各方面，它是Lucene的索引主要操作者。
3个公有的构造函数：
要获得一个IndexWrite的实例，就需要从它的构造函数入手尝试。具体的构造函数如下：public IndexWrite(String path, Analyzer a, Boolean create)
public IndexWrite(File path , Analyzer a, Boolean create)
public IndexWrite(Directory d, Analyzer a, Boolean create)
第一个参数为索引存放路径，第二个参数Analyzer为分词器，第三个参数是一个Boolean 类型的值，这个参数的含义是：在由第一个参数所指定的路径处，删除原目录内的所有内容重新构建索引：或是追加新的Document。
像索引添加文档
IndexWrite准备好以后，就可以想索引目录中添加Document。IndexWrite提供了很简单的接口以供开发人员进行Document的添加：
public void addDocument(Document doc)
public void addDocument(Document doc，Analyzer analyzer)
注意：在使用addDocument方法加入所有的Document后，一定要使用IndexWrite的close方法来关闭索引器，使所有在I/O缓存中的数据都写入到磁盘上，关闭各种流。这样才能最终完成索引的建立。如果没有关闭，就会发现索引目录中内除了一个segment 文件外一无所有。很多初学者在刚开始使用Lucene时经常忘记关闭IndexWrite，这样会导致索引的数据滞留在缓存中，未写入磁盘，有可能连目录的锁也没有去除。在下次对同一个目录加入索引文件的时候可能会提示目录处于锁定状态而造成无法加入文件。
限制每个Field中词条的数量
有必要为Lucene限制每个Field内可以建立索引的词条数。
public void setMaxFieldLength（int maxFieldLength）
索引过程的优化
合并因子mergeFactor
说明：无论是磁盘上创建新segment还是将segment合并，都需要进行磁盘的I/O操作，相对于内存的操作来说，这种磁盘I/O操作是比较费时的。因此，当mergeFactor取比较小的值时，内存中驻留的文档数量较少，向磁盘写入segment的操作较多，故此时将占用较小的内存，但是索引的建立由于I/O操作频繁所以会比较慢。而当mergeFactor 取较大值时，内存中驻留的Document数量较多，向磁盘写入segemnt的操作较少，故此时将占用较多的内存，但索引的建立速度会比较快。
maxMergeDocs
一个较大的MaxMergeDocs适用于应对大批量的文档索引建立，而增量式的索引则使用较小的MaxMergeDocs。
minMergeDocs
当索引将被存到磁盘中时，需要首先保存在内存中，minMergeDocs就是用来限制这个内存中的文档数量的。
索引的合并和优化
FSDirectory 与RAMDirectory
对于lucene来说这两种目录都可以作为索引的存储路径，FSDirectory指的是在文件系统中的一个路径。当lucene向其中写入索引时，会直接将索引写到磁盘上，RAMDirectory
是内存中的区域，虽然向其中添加document的过程与使用FSDirectory中的内存写入磁盘，当虚拟机退出后，里面的内容也会随之消失。因此需要将RAMDirectory中的内容转移到FSDirectory中。
代码：
从索引中删除文档
索引的读取工具IndexReader删除
IndexReader 主要负责对索引的各种读取和维护工作，如打开一个索引、取得索引中的某个文档、获取索引中的总文档的数量，甚至从索引中删除某个文档。
生成实例方法
IndexReader reader = ( INDEX_STORE_PATH );
方法
(0);
在luncene的内部使用类似回收站的机制来管理Document的删除，在每个Document 被索引中删除时，它只相当于被扔进了回收站，并未实际删除。
既然是回收站，Lucene提供了undeleteAll()方法实现反删除。真正的实现从一个索引中删除文档需要使用IndexWriter对索引optimize一次，luncene就会重新为每个文档分配ID值，这样那些标记为已删除的Document就真正的被无理删除了。
IndexWriter writer = new IndexWriter( INDEX_STORE_PATH,new StandardAnalyzer(),false );
();
使用Field信息来删除批量文档
IndexReader的deleteDocuments()方法是一个能批量删除索引的方法，它删除索引是按照词条进行的，也就是说，每个词条都可以用其所在的Field和他的值来表示。
Lucene同步法则
开发人员容易忽略掉同步问题，一旦发生这种情况，索引的完整性和数据的一致性就遇到了挑战。
出现在想索引中添加文档时或将文档从索引中删除时，会在IndexWrite初始化时创建，然后在调用IndexWriter的close()方法是被释放。另外，会在Indexreader使用delete方法删除文档时创建，并在调用IndexReader的close()方法是被释放。
主要是与segment合并和读取操作相关，例如，他出现在IndexWriter初始化时，但是一旦当segment的信息被读取完毕，他会立刻被释放。另外，当调用IndexWriter的addIndexes()或mergeSegments()方法时，都会生成这个锁。
的新类：IndexModifier类
IndexModifier，它集成了IndexWriter的大部分功能和IndexReader中对索引的删除功能。第三章Lucene的搜索
Lucene里与搜索相关的API多数被包含在包中。其中最重要的是IndexSearch类。在Lucene中，所有与搜索相关的操作都需要用到这个类。
的构造方法
public IndexSearch( String path )throws IOException
public IndexSearch(Directory directory)throws IOException
public IndexSearch( IndexReader r )
最简单的使用
代码
的多种search方法
Must 最终结果Must_not子句的查询结果
使用它时,需要实例化一个sort对象,并使用Searcher提供的search( Query,Sort )
接口来实现。
的构造方法
public Sort();
INDEXORDER)
按一个或多个Field来排序
Sort sort = new Sort();
SortField f1 = new SortField( ”bookNumber”,,false );
SortField f2 = new SortField( ”publishdate”,,false );
( new SortField[]{f1,f2} )
Hits hits = ( q,sort )
搜索的过滤器
搜索时过滤器是一种减少搜索范围的方式，即使搜索结果匹配，但是由于文档已经被过滤，所以仍然不会返回给客户，有了这种特性就可以实现很多功能，比如可以用它来实现一种安全机制，既保护某些文档无法被检索到
过滤器的基本结构
Public abstract BitSet bits( IndexReader reader )throws IOException;
BitSets是一种“位集合”队列，这个队列的每个元素都只有两种取值，即true或false，lucene以这种值来代表文档是否被过滤，也就是说，当lucene返回结果时，会先遍历BitSet，仅将那些对应值为true的文档返回。
将检索结果限定在某个给定的Field值范围
RangeFilte filter = new
RangeFilter( “publishdate”,”1970-01-01”,”1990-01-01”,”true”,”true” );
Hits hits = ( q,filter );
在结果中查询
当一次检索完毕后，希望能从上一次检索的结果集合中进行二次检索
第五章文本分析器
空格分词器
空格解析器(WhitespaceAnalyzer)
空格解析器利用空格将文本中的各个单词分割解析出来。这种解析器对带有空格的印欧语系书写方式的文本都能处理WhitespaceAnalyzer的结构简单。如下所示
从图科看出，WhitespaceAnalyzer 继承自Analyzer 。在继承的方法中创建了一个WhitespaceTokenizer 实例。大部分解析的分词功能是由Tokenizer 类实现的 空格分词器(WhitespaceTokenizer)
WhitespaceTokenizer 继承自抽象类CharTokenizer ，WhitespaceTokenizer 的next 方
法也继承自CharTokenizer 类 标准分词器 标准解析器
标准解析器依靠标准分次器（StandardTokenizer ）将输入的文本解析为token 流。
我们对其内部有特色的属性与方法深入剖析。该解析器特有属性与方法为： 属性；停用表（stopwords ）
停用表中存放的是一些高频率出现的英文单词，中文文字，高频此信息量小会带来索引文件增大
方法：tokenStream 方法,TokenStream 的层次结构
StopFilter
ProterStemfilter
LowerCaseFilter
StandardFilter
TokenStream
TokenFilter
Tokenizer
CharTokenizer StandardTokenizer
letterTokenizer
WhitespaceTokenizer
LowerCaseTokenizer
标准过滤转换为小写字符去除高频词
标准分词器（StandTokenizer）
标准分次器构造简单，包含的方法复杂。它的主要方法是next方法，这个方法被创建索引的过程调用。
标准过滤器（StandardFilter）标准过滤器也有同样的next方法
构造自己的分词器
Lucene内置了不少的解析器。但是遇到特殊的情况。Luncene的内置解析器有时并不能满足需求，比如中文的文本内容就需要自己定制解析器。
对于中文分词，一般有两种方法：
词库法，需要一个相当丰富的词库，能够识别出语句中包含的单词。
词元法，将单词按照n元语法（n-gram）方式切分出来，比如（n=2）切分“学历史知识”，可以得到“学历”，“历史”，“史知”，“知识”。使用词元法分析的最大优点是不需要维护词库，但是会产生无意义的单词。CJKAnalyzer（Lucene的Sandlbox包里，中文分词器）就是采用词元法（n=2）实现的解析器。
设计自己的解析器的思路如下：采用词库法，从分割后的人民日报里面有的分词结构统计出各个单词出现的频率，抽取出词汇作为词库，然后对需要分析的句子进行拆分，按照这些词在词库中标注的频率，通过Dijkstra算法把频率总合和最高的一组选取出来，这组词就是拆分后得到的最优结果。
采用Dijkstra算法来实现分词算法的原因是我们可以得到每个词在文集中出现的次数，那么不同的词在文集中的频率也是不一样的。所以，通过Dijkstra算法，对不同的词进行组合中频率总和最高的哪一组合。
第六章Lucene相关话题
对word、execl和pdf的处理
PDFBox是最常见的一种pdf文件抽取工具，下载地址为：projects/pdfbox/将下在的文件部署到工程中。
POI用来处理Excel和Word文件格式。POI是Apache的jakata项目的Poi子项目，下载地址为POI是完全的java Excel和java Word解决方案。POI子项目包括：
POIFS,HSSF,HDF,HPSF
实例代码如工程ch7
封装了Lucene的框架Compass
Compass是一套使用了Lucene的搜索引擎框架，它提供了一套开源的、高性能的、可灵活配置的搜索框架，可谓用户的用用程序提供搜索功能，不仅如此他还可以同Spring、hibernate等已有的框架进行结合。为使用者提供搜索服务
Compass的下载地址为Compass的使用方式跟hibernate方式很像，这里就不多做介绍了。
一、为什么使用lucene 1、Lucene不是一个完整的全文索引应用，而是是一个用JAVA写的全文索引引擎工具包，它可以方便的嵌入到各种应用中实现针对应用的全文索引/检索功能。这样的定位，使得lucene有很高的抽象层次，便于扩展和整合到已有的系统。因为对于大多数的全文搜索应用来说，我们需要的是一个开发工具包而不是最终产品（虽然很多搜索引擎也可以扩展特性功能）。这也是程序员最愿意接受的封装层次。 2、Lucene的API接口设计的比较通用，输入输出结构都很像数据库的表==>记录==>字段，所以很多传统的应用的文件、数据库等都可以比较方便的映射到Lucene的存储结构/接口中。（上面语句有些来自在应用中加入全文检索功能——基于JAVA的全文索引引擎Lucene简介）。 二、lucene4.0新特性较重要部分 1、全部使用字节( utf-8 tytes )替代string来构建 term directory 。 带来的好处是：索引文件读取速度 30 倍的提升；占用原来大约10%的内存；搜索过程由于去掉了字符串的转化速度也会明显提升； 但是如果说这上面的好处只是一个副产品，你会怎么想？没错，Mysql有MyIsam，Innodb等诸多引擎供我们选择的，Lucene为什么不能向这个方向发展呢？ 实现这个机制的模块叫：Codec （编码器），你可以实现自己的Codec 来进行自定义的扩展，很显然Codec的操作对象是Segment 。
2、支持多线程建索引，支持：concurrent flushing。 了解过Lucene 3.X的同学们都知道，诸如XXXPerThread 的类在建索引的时候已经支持多线程了，但是当每个线程的内存达到指定上限(maxBufferedDocs or ramMaxBufferSizeMB)的时候就需要写到硬盘上，而这个过程仍然不是多线程的，仍然需要一个个排队Flush到硬盘。Lucene 4.0 终于支持 concurrent flushing 了。DocumentsWriterPerThread ，Lucene 4.0 的Concurrent Flushing 正是这个类来实现的。 3、基于有限自动机的模糊匹配算法（FSA算法），FuzzyQuery FuzzyQuery 这类查询估计大家用的比较少。在英文中单词拼写错误，比如： Lucene， Licene , lucen 等就可以用FuzzyQuery来进行查询提高查全率。 在lucene 4.0 之前的FuzzyQuery 的实现非常耗费cpu，实现算法也很暴力。具体过程是：读取每个term，然后计算每个term与查询词的“编辑距离”，如果在指定的范围内则返回。 Lucene 4.0 使用Levenshtein Automaton 的来衡量文字的"编辑距离" ，使用有限状态自动机来进行计算。以数百倍的效率提升了FuzzyQuery 的效率。 三、lucene4.0正式版亮点功能： 一、通过解码器Codec 机制 Lucene 索引格式与Lucene架构解耦，变成了Plugin方式实现，包括：Terms , Postings lists ,Stored 字段,Term Vectors 等都可以以自定义的格式予以支持。正如Mysql支持多种存储引擎一样，现在Lucene也可以了。
深入理解lucene原理 一：什么是索引，为什么需要索引 对非结构化数据也即对全文数据的搜索主要有两种方法： 一种是顺序扫描法(Serial Scanning)：所谓顺序扫描，比如要找内容包含某一个字符串的文件，就是一个文档一个文档的看，对于每一个文档，从头看到尾，如果此文档包含此字符串，则此文档为我们要找的文件，接着看下一个文件，直到扫描完所有的文件。如利用windows的搜索也可以搜索文件内容，只是相当的慢。如果你有一个80G硬盘，如果想在上面找到一个内容包含某字符串的文件，不花他几个小时，怕是做不到。Linux下的grep命令也是这一种方式。大家可能觉得这种方法比较原始，但对于小数据量的文件，这种方法还是最直接，最方便的。但是对于大量的文件，这种方法就很慢了。 有人可能会说，对非结构化数据顺序扫描很慢，对结构化数据的搜索却相对较快（由于结构化数据有一定的结构可以采取一定的搜索算法加快速度），那么把我们的非结构化数据想办法弄得有一定结构不就行了吗？ 这种想法很天然，却构成了全文检索的基本思路，也即将非结构化数据中的一部分信息提取出来，重新组织，使其变得有一定结构，然后对此有一定结构的数据进行搜索，从而达到搜索相对较快的目的。 这部分从非结构化数据中提取出的然后重新组织的信息，我们称之索引 例如：字典，字典的拼音表和部首检字表就相当于字典的索引 二：索引包含哪些东西 其实是由于我们想要搜索的信息和非结构化数据中所存储的信息不一致造成的。
非结构化数据中所存储的信息是每个文件包含哪些字符串，已知文件，欲求字符串相对容易，也即是从文件到字符串的映射。 而我们想搜索的信息是哪些文件包含此字符串，也即已知字符串，欲求文件，也即从字符串到文件的映射。两者恰恰相反。 于是如果索引总能够保存从字符串到文件的映射，则会大大提高搜索速度。 由于从字符串到文件的映射是文件到字符串映射的反向过程，于是保存这种信息的索引称为反向索引。 左边保存的是一系列字符串，称为词典。每个字符串都指向包含此字符串的文档(Document)链表，此文档链表称为倒排表(Posting List)。 三：索引的创建过程 1.全文索引相对于顺序扫描的优势：一次索引，多次使用 2.创建索引的步骤： (1)要索引的原文档 (2)将原文档传给分词组件(Tokenizer) 分词组件会做如下事情：(此过程称为Tokenize) a.将文档分成一个一个的单词 b.去除标点符号 c.去除停词(Stop Word)停词就是语句中无意义的词汇，英语中比如“the”,“a”，“this”等 每一种分词组件(Tokenize)都有一个停词集合 经过分词组件分词后得到的结果称为(词元)Token
由于数据库索引不是为全文索引设计的，因此，使用like "%keyword%"时，数据库索引是不起作用的，在使用like查询时，搜索过程又变成类似于一页页翻书的遍历过程了，所以对于含有模糊查询的数据库服务来说，LIKE对性能的危害是极大的。如果是需要对多个关键词进行模糊匹配：like"%keyword1%" and like "%keyword2%" ...其效率也就可想而知了。 所以建立一个高效检索系统的关键是建立一个类似于科技索引一样的反向索引机制，将数据源（比如多篇文章）排序顺序存储的同时，有另外一个排好序的关键词列表，用于存储关键词==>文章映射关系，利用这样的映射关系索引：[关键词==>出现关键词的文章编号，出现次数（甚至包括位置：起始偏移量，结束偏移量），出现频率]，检索过程就是把模糊查询变成多个可以利用索引的精确查询的逻辑组合的过程。从而大大提高了多关键词查询的效率，所以，全文检索问题归结到最后是一个排序问题。 由此可以看出模糊查询相对数据库的精确查询是一个非常不确定的问题，这也是大部分数据库对全文检索支持有限的原因。Lucene最核心的特征是通过特殊的索引结构实现了传统数据库不擅长的全文索引机制，并提供了扩展接口，以方便针对不同应用的定制。 可以通过一下表格对比一下数据库的模糊查询： Lucene全文索引引擎数据库 索引将数据源中的数据都通过全文索引一一建立反向索引对于LIKE查询来说，数据传统的索引是根本用不上的。数据需要逐个便利记录进 行GREP式的模糊匹配，比有索引的搜索速度要有多个数量级的下降。 匹配效果通过词元(term)进行匹配，通过语言分析接口的实 现，可以实现对中文等非英语的支持。 使用：like "%net%" 会把netherlands也匹 配出来， 多个关键词的模糊匹配：使用like "%com%net%"：就不能匹配词序颠倒 的https://www.doczj.com/doc/5a4665776.html, 匹配度有匹配度算法，将匹配程度（相似度）比较高的结果排在前面。没有匹配程度的控制：比如有记录中net出现5词和出现1次的，结果是一样的。 结果输出通过特别的算法，将最匹配度最高的头100条结果 输出，结果集是缓冲式的小批量读取的。 返回所有的结果集，在匹配条目非常多的 时候（比如上万条）需要大量的内存存放 这些临时结果集。 可定制性通过不同的语言分析接口实现，可以方便的定制出 符合应用需要的索引规则（包括对中文的支持）没有接口或接口复杂，无法定制 结论高负载的模糊查询应用，需要负责的模糊查询的规则，索引的资料量比较大使用率低，模糊匹配规则简单或者需要模糊查询的资料量少 全文检索和数据库应用最大的不同在于：让最相关的头100条结果满足98%以上用户的需求 Lucene的创新之处： 大部分的搜索（数据库）引擎都是用B树结构来维护索引，索引的更新会导致大量的IO操作，Lucene在实现中，对此稍微有所改进：不是维护一个索引文件，而是在扩展索引的时候不断创建新的索引文件，然后定期的把这些新的小索引文件合并到原先的大索引中（针对不同的更新策略，批次的大小可以调整），这样在不影响检索的效率的前提下，提高了索引的效率。 Lucene和其他一些全文检索系统/应用的比较： Lucene其他开源全文检索系统 增量索引和批量索引可以进行增量的索引(Append)，可以对于大量 数据进行批量索引，并且接口设计用于优化批 量索引和小批量的增量索引。 很多系统只支持批量的索引，有时数 据源有一点增加也需要重建索引。 数据源Lucene没有定义具体的数据源，而是一个文档 的结构，因此可以非常灵活的适应各种应用 （只要前端有合适的转换器把数据源转换成相 应结构）， 很多系统只针对网页，缺乏其他格式 文档的灵活性。 索引内容抓取Lucene的文档是由多个字段组成的，甚至可以 控制那些字段需要进行索引，那些字段不需要 索引，近一步索引的字段也分为需要分词和不 需要分词的类型： 需要进行分词的索引，比如：标题，文章内 容字段 不需要进行分词的索引，比如：作者/日期 字段 缺乏通用性，往往将文档整个索引了
在应用中加入全文检索功能 ——基于Java的全文索引引擎Lucene简介 作者：车东 Email: https://www.doczj.com/doc/5a4665776.html,/https://www.doczj.com/doc/5a4665776.html, 写于：2002/08 最后更新：09/09/2006 17:09:05 Feed Back >> (Read this before you ask question) 版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本声明 https://www.doczj.com/doc/5a4665776.html,/tech/lucene.html 关键词：Lucene java full-text search engine Chinese word segment 内容摘要： Lucene是一个基于Java的全文索引工具包。 1.基于Java的全文索引引擎Lucene简介：关于作者和Lucene的历史 2.全文检索的实现：Luene全文索引和数据库索引的比较 3.中文切分词机制简介：基于词库和自动切分词算法的比较 4.具体的安装和使用简介：系统结构介绍和演示 5.Hacking Lucene：简化的查询分析器，删除的实现，定制的排序，应用 接口的扩展 6.从Lucene我们还可以学到什么 基于Java的全文索引/检索引擎——Lucene Lucene不是一个完整的全文索引应用，而是是一个用Java写的全文索引引擎工具包，它可以方便的嵌入到各种应用中实现针对应用的全文索引/检索功能。 Lucene的作者：Lucene的贡献者Doug Cutting是一位资深全文索引/检索专家，曾经是V-Twin搜索引擎(Apple的Copland操作系统的成就之一)的主要开发者，后在Excite担任高级系统架构设计师，目前从事于一些INTERNET底层架构的研究。他贡献出的Lucene的目标是为各种中小型应用程序加入全文检索功能。 Lucene的发展历程：早先发布在作者自己的https://www.doczj.com/doc/5a4665776.html,，后来发布在SourceForge，2001年年底成为APACHE基金会jakarta的一个子项目：https://www.doczj.com/doc/5a4665776.html,/lucene/ 已经有很多Java项目都使用了Lucene作为其后台的全文索引引擎，比较著名的有： Jive：WEB论坛系统；
Luc e ne全文检索的应用 及检索效率测试研究3 彭 哲 陈敬文 【摘 要】使用Lucene设计一个全文检索系统,系统由三大功能模块组成:索引模块、检索模块和存储模块。第二部分着重分析PDF数据转换,X M L文档设计,索引的分词、建立及效率等技术难点,并对中文分词分析器、索引文件膨胀率、索引影响因子及检索系统并对检索响应时间进行测试。应关注X M L数据库的安全性。【关键词】Lucence X M L 全文检索 效率 Abstract:Using lucene de sign a full t ext retrieval syst em,including index mo dule,retrieval mo dule,a nd dat a ba se mo dule1Mainly a nalyze how to tra nsform PDF to X M L,de signing of X M L dat a ba se,Chine se word se gment ation,founding a nd efficiency of indexe s,then t e st s a nalyzer,exp a nsivity,f a ctors of indexe s a nd re sponding time of se arching1The security of X M L dat a ba se should be p aid att ention to1 K ey w ords:Lucene X M L full t ext retrieval efficiency Lucene不是一个完整的全文检索应用程序,而是一个高性能的J a va全文检索工具包,它可以方便地嵌入到各种应用中实现针对应用的全文检索功能。Lucene以其开放源代码的特性、优异的索引结构和良好的系统架构,得到了越来越广泛的应用。 本文使用Lucene设计并实现了一个全文检索系统,与关系数据库相比,采用X M L作为数据存储容器,实现了单个数据库操作,并在大信息量环境下极大地节省了存储空间,提高了检索的速度。 1 系统分析与设计 本文实现的全文跨库检索系统由三大功能模块组成:索引模块、检索模块和存储模块[1]。 111 索引模块 Lucene最核心的特征就在于它特殊的索引结构可以提高检索效率,这也是我们选择Lucene的重要原因。Lucene使用的是倒排文件索引结构,它把每个关键词、关键词在文中出现频率、关键词在文中位置分别作为词典文件(Term Dictionary)、频率文件(Fre quencie s)、位置文件(Po sitions)保存。其中词典文件不仅保存每个关键词,还保留了指向频率文件和位置文件的指针,通过指针可以找到该关键词的频率信息和位置信息。 同时,关键词在索引文件中的排放顺序是按照字符顺序排列的,所以Lucene可以用二元搜索算法快速定位关键词。 另外,Lucene中使用了Field的概念,用于表达信息所在位置(如标题中、文章中、url中),在建立索引时,该Field信息也记录在词典文件中。由于每个关键词一定属于一个或多个Field,所以每个关键词都有一个Field信息。 为了减少索引文件的大小,Lucene对索引还使用了压缩技术,首先,对词典文件中的关键词进行了压缩,关键词压缩为<前缀长度,后缀>;其次,大量用到了对数字的压缩,数字只保存与上一个值的差值。 在维护索引文件时,Lucene与其他B树结构的索引有所不同,它是在扩展索引的时候不断创建新的索引文件,然后定期把这些新的小索引文件合并到原先的大索引中,这样避免了大量的IO操作,在不影响检索效率的前 3本文系国家社科基金重大项目“建设创新型国家的信息服务体制与信息保障体系研究”(项目编号:06&ZD031)课题成果之一。
搜索引擎Lucene 第一章Lucene简介 Lucene是apache软件基金会jakarta项目组的一个子项目，是一个开放源代码[的全文检索引擎工具包，即它不是一个完整的全文检索引擎，而是一个全文检索引擎的架构，提供了完整的查询引擎和索引引擎，部分文本分析引擎（英文与德文两种西方语言）。Lucene的目的是为软件开发人员提供一个简单易用的工具包，以方便的在目标系统中实现全文检索的功能，或者是以此为基础建立起完整的全文检索引擎。 第二章lucene索引的建立 的五个基础类 索引的建立，Lucene 提供了五个基础类，分别是Document, Field, IndexWriter, Analyzer, Directory。以下是他们的用途： Document Document的含义为文档，在Lucene中，它代表一种逻辑文件。Lucene本身无法对物理文件建立索引，而只能识别并处理Document的类型文件。Lucene从Document取出相关的数据源并根据属性配置进行相应的处理。 Field 对象是用来描述一个文档的某个属性的 lucene中的field也具有一些特定的类型如
在中，Field内部包含两个静态的内部类分别是Store和Index详细的描述了Field的属性，它们分别表示Field的储存方式和索引方式。 Store类有3个公有的静态属性： :表示该Field不需要储存。 :表示该Field需要储存。 :表示使用压缩方式来保存这个Field的值。 Index有4个公有的静态属性： :表示该Field不需要索引，也就是用户不需要去查找该Field的值。 :表示该Field先被分词再被索引。 TOKENIZED:表示不对该Field进行分词，但是要对他进行索引，也就是该Field会被用户查找。 :表示对该Field进行索引，但是不使用Analyzer，同时禁止它参加评分，主要是为了减少内存的消耗。 Analyzer
开放源代码的全文检索引擎 Lucene ――介绍、系统结构与源码实现分析 第一节全文检索系统与Lucene简介 一、什么是全文检索与全文检索系统？ 全文检索是指计算机索引程序通过扫描文章中的每一个词，对每一个词建立一个索引，指明该词在文章中出现的次数和位置，当用户查询时，检索程序就根据事先建立的索引进行查找，并将查找的结果反馈给用户的检索方式。这个过程类似于通过字典中的检索字表查字的过程。 全文检索的方法主要分为按字检索和按词检索两种。按字检索是指对于文章中的每一个字都建立索引，检索时将词分解为字的组合。对于各种不同的语言而言，字有不同的含义，比如英文中字与词实际上是合一的，而中文中字与词有很大分别。按词检索指对文章中的词，即语义单位建立索引，检索时按词检索，并且可以处理同义项等。英文等西方文字由于按照空白切分词，因此实现上与按字处理类似，添加同义处理也很容易。中文等东方文字则需要切分字词，以达到按词索引的目的，关于这方面的问题，是当前全文检索技术尤其是中文全文检索技术中的难点，在此不做详述。 全文检索系统是按照全文检索理论建立起来的用于提供全文检索服务的软件系统。一般来说，全文检索需要具备建立索引和提供查询的基本功能，此外现代的全文检索系统还需要具有方便的用户接口、面向WWW[1]的开发接口、二次应用开发接口等等。功能上，全文检索系统核心具有建立索引、处理查询返回结果集、增加索引、优化索引结构等等功能，外围则由各种不同应用具有的功能组成。结构上，全文检索系统核心具有索引引擎、查询引擎、文本分析引擎、对外接口等等，加上各种外围应用系统等等共同构成了全文检索系统。图1.1展示了上述全文检索系统的结构与功能。
版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本声明。 https://www.doczj.com/doc/5a4665776.html,/tech/lucene.html -------------------------------------------------------------------------------- Lucene是一个基于Java的全文索引工具包。 基于Java的全文索引引擎Lucene简介：关于作者和Lucene的历史 全文检索的实现：Luene全文索引和数据库索引的比较 中文切分词机制简介：基于词库和自动切分词算法的比较 具体的安装和使用简介：系统结构介绍和演示 Hacking Lucene：简化的查询分析器，删除的实现，定制的排序，应用接口的扩展 从Lucene我们还可以学到什么 基于Java的全文索引/检索引擎——Lucene Lucene不是一个完整的全文索引应用，而是是一个用Java写的全文索引引擎工具包，它可以方便的嵌入到各种应用中实现针对应用的全文索引/检索功能。 Lucene的作者：Lucene的贡献者Doug Cutting是一位资深全文索引/检索专家，曾经是V-Twin 搜索引擎(Apple的Copland操作系统的成就之一)的主要开发者，后在Excite担任高级系统架构设计师，目前从事于一些INTERNET底层架构的研究。他贡献出的Lucene的目标是为各种中小型应用程序加入全文检索功能。 Lucene的发展历程：早先发布在作者自己的https://www.doczj.com/doc/5a4665776.html,，后来发布在SourceForge，2001年年底成为APACHE基金会jakarta的一个子项目：https://www.doczj.com/doc/5a4665776.html,/lucene/ 已经有很多Java项目都使用了Lucene作为其后台的全文索引引擎，比较著名的有： Jive：WEB论坛系统； Eyebrows：邮件列表HTML归档/浏览/查询系统，本文的主要参考文档“TheLucene search engine: Powerful, flexible, and free”作者就是EyeBrows系统的主要开发者之一，而EyeBrows已经成为目前APACHE项目的主要邮件列表归档系统。 Cocoon:基于XML的web发布框架，全文检索部分使用了Lucene Eclipse:基于Java的开放开发平台，帮助部分的全文索引使用了Lucene 对于中文用户来说，最关心的问题是其是否支持中文的全文检索。但通过后面对于Lucene 的结构的介绍，你会了解到由于Lucene良好架构设计，对中文的支持只需对其语言词法分析接口进行扩展就能实现对中文检索的支持。 全文检索的实现机制 Lucene的API接口设计的比较通用，输入输出结构都很像数据库的表==>记录==>字段，所以很多传统的应用的文件、数据库等都可以比较方便的映射到Lucene的存储结构/接口中。总体上看：可以先把Lucene当成一个支持全文索引的数据库系统。
一、Lucene 数据源组织结构 举个列子，比如我们想要检索文件的路径，修改时间和内容。我们可以创建三个Field对象分别存储这三种数据： 我们可以创建一个Document对象，加入这三个Field，来表示一个文档文件需要被检索的三种数据。 总结：下面的图很清楚的说明Lucene的数据源表示形式 Lucene首先将这三个数据源在内存中组织成Document、Field 如下表： Document 和Field在Lucene中的作用是巨大的。我们都知道Lucene可以对任何形式的数据源建立索引，比如字符串、纯文本、XML、HTML等数据形式。怎么多杂乱无章的数据
必须组织成统一有效的结构才能更好的处理，Document / Field 无疑做到了这一点。 二、IndexWrite索引创建 我们对content目录中1.txt、2.txt、3.txt这三个英文文档的文件名，路径，内容建立索引。代码如下： 其中，IndexWriter索引器用来创建索引。Document和Field类表示这三个文档的结构如下： 1、建立索引的方法：addDocument(Document) 该方法是用来创建索引的。我们进一步看看这个方法的源码：
其中docWriter.addDocument(doc,analyzer);调用了DocumentWriter类来创建一个Document 对象的索引。 三、DocumentWriter处理流程 DocumentsWriter是由IndexWriter调用来负责对多个document建立索引的核心类，但整个索引过程并不是由一个对象来完成的。而是有一系列的对象组成的处理链(IndexingChain)来完成的(这个过程就像流水线生产汽车)。下面是DocumentWriter开始建立索引的源代码。
下面说的主要是lucene如何进行搜索，相比于建索引，搜索可能更能提起大家的兴趣。lucene的主要搜索的API 下面通过表格来看一下lucene用到的主要的搜索API 类目的 IndexSeacher搜索操作的入口，所有搜索操作都是通过IndexSeacher实例使用一个重载的search方法来实现 Query(及其子类)具体的Query子类为每一种特定类型的查询进行逻辑上的封装。Query实例被传递到IndexSearcher的search方法中 QueryParser将用户输入的（并且可读的）查询表达式处理为一个具体的Query对象 TopDocs保持由IndexSearcher.search()方法返回的具有较高评分的顶部文档 ScoreDoc提供对TopDocs中每条搜索结果的访问接口 对特定项进行搜索 其中IndexSearcher是对索引中文档进行搜索的核心类，我们下面的例子中就会对subject域进行索引，使用的是Query的子类TermQuery。 测试程序如下： 1p u b l i c v o i d t e s t T e r m()t h r o w s E x c e p t i o n{ 2D i r e c t o r y d i r=T e s t U t i l.g e t B o o k I n d e x D i r e c t o r y();//A 3I n d e x S e a r c h e r s e a r c h e r=n e w I n d e x S e a r c h e r(d i r);//B 4 5T e r m t=n e w T e r m("s u b j e c t","a n t"); 6Q u e r y q u e r y=n e w T e r m Q u e r y(t); 7T o p D o c s d o c s=s e a r c h e r.s e a r c h(q u e r y,10); 8a s s e r t E q u a l s("A n t i n A c t i o n",//C 91,d o c s.t o t a l H i t s);//C 10 11t=n e w T e r m("s u b j e c t","j u n i t"); 12d o c s=s e a r c h e r.s e a r c h(n e w T e r m Q u e r y(t),10); 13a s s e r t E q u a l s("A n t i n A c t i o n,"+//D 14"J U n i t i n A c t i o n,S e c o n d E d i t i o n",//D 152,d o c s.t o t a l H i t s);//D 16 17s e a r c h e r.c l o s e(); 18d i r.c l o s e(); 19} 当然在不同的情况下你可以改变其中的代码来搜索你想要的东西。
另外，如果是在选择全文引擎，现在也许是试试Sphinx的时候了：相比Lucene速度更快，有中文分词的支持，而且内置了对简单的分布式检索的支持； 基于Java的全文索引/检索引擎——Lucene Lucene不是一个完整的全文索引应用，而是是一个用Java写的全文索引引擎工具包，它可以方便的嵌入到各种应用中实现针对应用的全文索引/检索功能。 Lucene的作者：Lucene的贡献者Doug Cutting是一位资深全文索引/检索专家，曾经是V-Twin搜索引擎(Apple的Copland操作系统的成就之一)的主要开发者，后在Excite担任高级系统架构设计师，目前从事于一些INTERNET底层架构的研究。他贡献出的Lucene的目标是为各种中小型应用程序加入全文检索功能。 Lucene的发展历程：早先发布在作者自己的https://www.doczj.com/doc/5a4665776.html,，后来发布在SourceForge，2001年年底成为APACHE基金会jakarta的一个子项目： https://www.doczj.com/doc/5a4665776.html,/lucene/ 已经有很多Java项目都使用了Lucene作为其后台的全文索引引擎，比较著名的有： 对于中文用户来说，最关心的问题是其是否支持中文的全文检索。但通过后面对于Lucene 的结构的介绍，你会了解到由于Lucene良好架构设计，对中文的支持只需对其语言词法分析接口进行扩展就能实现对中文检索的支持。 全文检索的实现机制
全文检索≠ like "%keyword%" 通常比较厚的书籍后面常常附关键词索引表（比如：北京：12, 34页，上海：3,77页……），它能够帮助读者比较快地找到相关内容的页码。而数据库索引能够大大提高查询的速度原理也是一样，想像一下通过书后面的索引查找的速度要比一页一页地翻内容高多少倍……而索引之所以效率高，另外一个原因是它是排好序的。对于检索系统来说核心是一个排序问题。 由于数据库索引不是为全文索引设计的，因此，使用like "%keyword%"时，数据库索引是不起作用的，在使用like查询时，搜索过程又变成类似于一页页翻书的遍历过程了，所以对于含有模糊查询的数据库服务来说，LIKE对性能的危害是极大的。如果是需要对多个关键词进行模糊匹配：like"%keyword1%" and like "%keyword2%" ...其效率也就可想而知了。 所以建立一个高效检索系统的关键是建立一个类似于科技索引一样的反向索引机制，将数据源（比如多篇文章）排序顺序存储的同时，有另外一个排好序的关键词列表，用于存储关键词==>文章映射关系，利用这样的映射关系索引：[关键词==>出现关键词的文章编号，出现次数（甚至包括位置：起始偏移量，结束偏移量），出现频率]，检索过程就是把模糊查询变成多个可以利用索引的精确查询的逻辑组合的过程。从而大大提高了多关键词查询的效率，所以，全文检索问题归结到最后是一个排序问题。 由此可以看出模糊查询相对数据库的精确查询是一个非常不确定的问题，这也是大部分数据库对全文检索支持有限的原因。Lucene最核心的特征是通过特殊的索引结构实现了传统数据库不擅长的全文索引机制，并提供了扩展接口，以方便针对不同应用的定制。
全文检索与Lucene学习 全文检索与Lucene学习 本文是我最近针对Lucene3.3.0进行的总结，并提供了大量的实现Demo，常用的基本都有，下载地址：https://www.doczj.com/doc/5a4665776.html,/detail/a_2cai/3594154 1 概述 概念：Lucene不是一个完整的全文索引应用，而是是一个用Java写的全文索引引擎工具包，它可以方便的嵌入到各种应用中实现针对应用的全文索引/检索功能。 当前的版本有：Java版的，.NET版的（不完全），网上也有C++重写的，其他各类语言大部分也都有重写的。 简单地说它就两个功能：索引和检索。 主要应用：全文检索，顾名思义即在文件文本中搜索是否含有某个词之类的。（实质不一定是大文本） 全文检索是指计算机索引程序通过扫描文章中的每一个词，对每一个词建立一个索引，指明该词在文章中出现的次数和位置，当用户查询时，检索程序就根据事先建立的索引进行查找，并将查找的结果反馈给用户的检索方式。这个过程类似于通过字典中的检索字表查字的过程。 全文检索使用的理由：执行模糊查询都需要对全表扫描或索引扫描意味着消耗大量IO，如果模糊查询经常发生，会造成数据库性能恶化。（当然不一定非得是对大文件的检索，字段的模糊检索也是如此） 通常比较厚的书籍后面常常附关键词索引表（比如：北京：12, 34页，上海：3,77页……），它能够帮助读者比较快地找到相关内容的页码。而数据库索引能够大大提高查询的速度原理也是一样，想像一下通过书后面的索引查找的速度要比一页一页地翻内容高多少倍……而索引之所以效率高，另外一个原因是它是排好序的。对于检索系统来说核心是一个排序问题。 由于数据库索引不是为全文索引设计的，因此，使用like "%keyword%"时，数据库索引是不起作用的，在使用like查询时，搜索过程又变成类似于一页页翻书的遍历过程了，所以对于含有模糊查询的数据库服务来说，LIKE对性能的危
Lucene3.0之索引（1）：开篇 1 倒排索引 倒排索引是满足实际应用而设计的一种数据结构。倒排索引的每一个元素是一个索引项，每一个索引项是由关键字属性值和关键字关联结果，或者记录的存放地址组成。倒排索引是利用索引关键字直接确定文档列表，最后确定希望找到的文档列表。与传统的顺序查找和记录组织方式相反，因此称为倒排索引。通常把采用倒排索引方式组织的文件或者倒排索引和文档主文件一起称为倒排文件。 2 Lucence索引器 2.1 模式 2.1.1 独立索引模式：每个Document独立索引成一个文件 2.1.2 符合索引模式：等待索引的全部Document索引成一个文件 2.2 结构 索引项->索引域->索引文档->索引段->索引 2.2.1索引域的属性 1、域的名称（String类型） 2、域存储的值 3、Store Store.YES：保持索引和原始信息 Store.NO：信息只索引，但不保存 4、Index Index.ANAL YZED：分词并建立索引 Index.ANAL YZED_NO_NORMS：分词并建立索引，同时index-time，document boosting和field length normalization这几个域不使用。 Index.NO：不建立索引 Index.NOT_ANAL YZED：不分词，但建立索引 Index.NOT_ANAL YZED_NO_NORMS：不分词，建立索引，同时index-time，document boosting和field length normalization这几个域不使用。 5、Field.TermVector：表示域内信息是否需要分词。 2.2.2 索引项 索引项是索引管理的最小单元。在程序中没有显示的调用，它是利用分词器，在后台自动把一个域的值进行分隔。得到的每个独立元素称为一个索引项，用来建立索引。 2.3 格式 复合索引模式（默认）：可以减少索引文件的数量，便于管理和使用，适用于静态索引。多文件索引格式适用于动态索引。 2.3.1 多文件索引格式 使用一系列索引文件分别存储索引，分散管理数据的索引存储格式。多文件索引在打开时需要读取大量文件，会大大占用系统的文件句柄等资源，造成系统响应速度慢，甚至系统崩溃。 主要的索引文件及功能： 1、segment_*：描述一组索引的参数，使用文件头固定格式描述后面的内容，包括每个独立新建索引的大小，属性等。
Lucene实践：全文检索的基本原理 一、总论 根据https://www.doczj.com/doc/5a4665776.html,/java/docs/index.html定义： "Apache Lucene(TM) is a high-performance, full-featured text search engine library written entirely in Java. It is a technology suitable for nearly any application that requires full-text search, especially cross-platform." Lucene是一个高效的，基于Java的全文检索库。 所以在了解Lucene之前要费一番工夫了解一下全文检索。 那么什么叫做全文检索呢？这要从我们生活中的数据说起。 我们生活中的数据总体分为两种：结构化数据和非结构化数据。 ?结构化数据：指具有固定格式或有限长度的数据， 如数据库，元数据等。 ?非结构化数据：指不定长或无固定格式的数据，如 邮件，word文档等。 当然有的地方还会提到第三种，半结构化数据，如XML，HTML等，当根据需要可按结构化数据来处理，也可抽取出纯文本按非结构化数据来处理。 非结构化数据又一种叫法叫全文数据。 按照数据的分类，搜索也分为两种： ?对结构化数据的搜索：如对数据库的搜索，用SQL 语句。再如对元数据的搜索，如利用windows搜索 对文件名，类型，修改时间进行搜索等。 ?对非结构化数据的搜索：如利用windows的搜索也 可以搜索文件内容，Linux下的grep命令，再如用 Google和百度可以搜索大量内容数据。 对非结构化数据也即对全文数据的搜索主要有两种方法： 一种是顺序扫描法(Serial Scanning)：所谓顺序扫描，比如要找内容包含某一个字符串的文件，就是一个文档一个文档的看，对于每一个文档，从头看到尾，如果此文档包含此字符串，则此文档为我们要找的文件，接着看下一个文件，直到扫描完所有的文件。如利用windows的搜索也可以搜索文件内容，只是相当的慢。如果你有一个80G硬盘，如果想在上面找到一个内容包含某字符串的文件，不花他几个小时，怕是做不到。Linux下的grep命令也是这一种方式。大家可能觉得这种方法比较原始，但
Lucene：基于Java的全文检索引擎简介 Lucene是一个基于Java的全文索引工具包。 对于中文用户来说，最关心的问题是其是否支持中文的全文检索。但通过后面对于Lucene 的结构的介绍，你会了解到由于Lucene良好架构设计，对中文的支持只需对其语言词法分析接口进行扩展就能实现对中文检索的支持。
全文检索≠ like "%keyword%" 通常比较厚的书籍后面常常附关键词索引表（比如：北京：12, 34页，上海：3,77页……），它能够帮助读者比较快地找到相关内容的页码。而数据库索引能够大大提高查询的速度原理也是一样，想像一下通过书后面的索引查找的速度要比一页一页地翻内容高多少倍……而索引之所以效率高，另外一个原因是它是排好序的。对于检索系统来说核心是一个排序问题。 由于数据库索引不是为全文索引设计的，因此，使用like "%keyword%"时，数据库索引是不起作用的，在使用like查询时，搜索过程又变成类似于一页页翻书的遍历过程了，所以对于含有模糊查询的数据库服务来说，LIKE对性能的危害是极大的。如果是需要对多个关键词进行模糊匹配：like"%keyword1%" and like "%keyword2%" ...其效率也就可想而知了。 所以建立一个高效检索系统的关键是建立一个类似于科技索引一样的反向索引机制，将数据源（比如多篇文章）排序顺序存储的同时，有另外一个排好序的关键词列表，用于存储关键词==>文章映射关系，利用这样的映射关系索引：[关键词==>出现关键词的文章编号，出现次数（甚至包括位置：起始偏移量，结束偏移量），出现频率]，检索过程就是把模糊查询变成多个可以利用索引的精确查询的逻辑组合的过程。从而大大提高了多关键词查询的效率，所以，全文检索问题归结到最后是一个排序问题。