模具东莞网站建设,科技资讯,徐州seo外包公司,暴雪国服回归消息今天最新(转自http://hi.baidu.com/sz_xiaofeng/blog/item/7f3c33ed033444d1b31cb1b2.html)Lucene是一个基于Java的全文索引工具包。 基于Java的全文索引引擎Lucene简介#xff1a;关于作者和Lucene的历史全文检索的实现#xff1a;Luene全文索引和数据库索引的比较中文切分词机制简介… (转自http://hi.baidu.com/sz_xiaofeng/blog/item/7f3c33ed033444d1b31cb1b2.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的发展历程早先发布在作者自己的http://www.lucene.com/后来发布在SourceForge2001年年底成为APACHE基金会jakarta的一个子项目http://jakarta.apache.org/lucene/ 已经有很多Java项目都使用了Lucene作为其后台的全文索引引擎比较著名的有 JiveWEB论坛系统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和数据库 Lucene数据库索引数据源doc(field1,field2...) doc(field1,field2...) \ indexer / _____________ | Lucene Index| -------------- / searcher \ 结果输出Hits(doc(field1,field2) doc(field1...))索引数据源record(field1,field2...) record(field1..) \ SQL: insert/ _____________ | DB Index | ------------- / SQL: select \结果输出results(record(field1,field2..) record(field1...))Document一个需要进行索引的“单元”一个Document由多个字段组成Record记录包含多个字段Field字段Field字段Hits查询结果集由匹配的Document组成RecordSet查询结果集由多个Record组成全文检索 ≠ like %keyword% 通常比较厚的书籍后面常常附关键词索引表比如北京12, 34页上海3,77页……它能够帮助读者比较快地找到相关内容的页码。而数据库索引能够大大提高查询的速度原理也是一样想像一下通过书后面的索引查找的速度要比一页一页地翻内容高多少倍……而索引之所以效率高另外一个原因是它是排好序的。对于检索系统来说核心是一个排序问题。 由于数据库索引不是为全文索引设计的因此使用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和其他一些全文检索系统/应用的比较 Lucene其他开源全文检索系统增量索引和批量索引可以进行增量的索引(Append)可以对于大量数据进行批量索引并且接口设计用于优化批量索引和小批量的增量索引。很多系统只支持批量的索引有时数据源有一点增加也需要重建索引。数据源Lucene没有定义具体的数据源而是一个文档的结构因此可以非常灵活的适应各种应用只要前端有合适的转换器把数据源转换成相应结构很多系统只针对网页缺乏其他格式文档的灵活性。索引内容抓取Lucene的文档是由多个字段组成的甚至可以控制那些字段需要进行索引那些字段不需要索引近一步索引的字段也分为需要分词和不需要分词的类型 需要进行分词的索引比如标题文章内容字段 不需要进行分词的索引比如作者/日期字段缺乏通用性往往将文档整个索引了语言分析通过语言分析器的不同扩展实现可以过滤掉不需要的词an the of 等西文语法分析将jumps jumped jumper都归结成jump进行索引/检索非英文支持对亚洲语言阿拉伯语言的索引支持缺乏通用接口实现查询分析通过查询分析接口的实现可以定制自己的查询语法规则比如 多个关键词之间的 - and or关系等 并发访问能够支持多用户的使用 关于亚洲语言的的切分词问题(Word Segment) 对于中文来说全文索引首先还要解决一个语言分析的问题对于英文来说语句中单词之间是天然通过空格分开的但亚洲语言的中日韩文语句中的字是一个字挨一个所有首先要把语句中按“词”进行索引的话这个词如何切分出来就是一个很大的问题。 首先肯定不能用单个字符作(si-gram)为索引单元否则查“上海”时不能让含有“海上”也匹配。 但一句话“北京天安门”计算机如何按照中文的语言习惯进行切分呢“北京 天安门” 还是“北 京 天安门”让计算机能够按照语言习惯进行切分往往需要机器有一个比较丰富的词库才能够比较准确的识别出语句中的单词。 另外一个解决的办法是采用自动切分算法将单词按照2元语法(bigram)方式切分出来比如北京天安门 北京 京天 天安 安门。 这样在查询的时候无论是查询北京 还是查询天安门将查询词组按同样的规则进行切分北京天安安门多个关键词之间按与and的关系组合同样能够正确地映射到相应的索引中。这种方式对于其他亚洲语言韩文日文都是通用的。 基于自动切分的最大优点是没有词表维护成本实现简单缺点是索引效率低但对于中小型应用来说基于2元语法的切分还是够用的。基于2元切分后的索引一般大小和源文件差不多而对于英文索引文件一般只有原文件的30%-40%不同 自动切分词表切分实现实现非常简单实现复杂查询增加了查询分析的复杂程度适于实现比较复杂的查询语法规则存储效率索引冗余大索引几乎和原文一样大索引效率高为原文大小的30左右维护成本无词表维护成本词表维护成本非常高中日韩等语言需要分别维护。还需要包括词频统计等内容适用领域嵌入式系统运行环境资源有限分布式系统无词表同步问题多语言环境无词表维护成本对查询和存储效率要求高的专业搜索引擎目前比较大的搜索引擎的语言分析算法一般是基于以上2个机制的结合。关于中文的语言分析算法大家可以在Google查关键词wordsegment search能找到更多相关的资料。 安装和使用 下载http://jakarta.apache.org/lucene/ 注意Lucene中的一些比较复杂的词法分析是用JavaCC生成的JavaCCJavaCompilerCompiler纯Java的词法分析生成器所以如果从源代码编译或需要修改其中的QueryParser、定制自己的词法分析器还需要从https://javacc.dev.java.net/下载javacc。 lucene的组成结构对于外部应用来说索引模块(index)和检索模块(search)是主要的外部应用入口 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/一些公用的数据结构简单的例子演示一下Lucene的使用方法索引过程从命令行读取文件名多个将文件分路径(path字段)和内容(body字段)2个字段进行存储并对内容进行全文索引索引的单位是Document对象每个Document对象包含多个字段Field对象针对不同的字段属性和数据输出的需求对字段还可以选择不同的索引/存储字段规则列表如下 方法切词索引存储用途Field.Text(String name, String value)YesYesYes切分词索引并存储比如标题内容字段Field.Text(String name, Reader value)YesYesNo切分词索引不存储比如META信息不用于返回显示但需要进行检索内容Field.Keyword(String name, String value)NoYesYes不切分索引并存储比如日期字段Field.UnIndexed(String name, String value)NoNoYes不索引只存储比如文件路径Field.UnStored(String name, String value)YesYesNo只全文索引不存储public class IndexFiles { //使用方法: IndexFiles [索引输出目录] [索引的文件列表] ... public static void main(String[] args) throws Exception { String indexPath args[0]; IndexWriter writer; //用指定的语言分析器构造一个新的写索引器第3个参数表示是否为追加索引 writer new IndexWriter(indexPath, new SimpleAnalyzer(), false); for (int i1; iargs.length; i) { System.out.println(Indexing file args[i]); InputStream is new FileInputStream(args[i]); //构造包含2个字段Field的Document对象 //一个是路径path字段不索引只存储 //一个是内容body字段进行全文索引并存储 Document doc new Document(); doc.add(Field.UnIndexed(path, args[i])); doc.add(Field.Text(body, (Reader) new InputStreamReader(is))); //将文档写入索引 writer.addDocument(doc); is.close(); }; //关闭写索引器 writer.close(); }} 索引过程中可以看到 语言分析器提供了抽象的接口因此语言分析(Analyser)是可以定制的虽然lucene缺省提供了2个比较通用的分析器SimpleAnalyser和StandardAnalyser这2个分析器缺省都不支持中文所以要加入对中文语言的切分规则需要修改这2个分析器。Lucene并没有规定数据源的格式而只提供了一个通用的结构Document对象来接受索引的输入因此输入的数据源可以是数据库WORD文档PDF文档HTML文档……只要能够设计相应的解析转换器将数据源构造成成Docuement对象即可进行索引。对于大批量的数据索引还可以通过调整IndexerWrite的文件合并频率属性mergeFactor来提高批量索引的效率。 检索过程和结果显示 搜索结果返回的是Hits对象可以通过它再访问DocumentField中的内容。 假设根据body字段进行全文检索可以将查询结果的path字段和相应查询的匹配度(score)打印出来public class Search { public static void main(String[] args) throws Exception { String indexPath args[0], queryString args[1]; //指向索引目录的搜索器 Searcher searcher new IndexSearcher(indexPath); //查询解析器使用和索引同样的语言分析器 Query query QueryParser.parse(queryString, body, new SimpleAnalyzer()); //搜索结果使用Hits存储 Hits hits searcher.search(query); //通过hits可以访问到相应字段的数据和查询的匹配度 for (int i0; ihits.length(); i) { System.out.println(hits.doc(i).get(path) ; Score: hits.score(i)); }; }}在整个检索过程中语言分析器查询分析器甚至搜索器Searcher都是提供了抽象的接口可以根据需要进行定制。 Hacking Lucene 简化的查询分析器 个人感觉lucene成为JAKARTA项目后画在了太多的时间用于调试日趋复杂QueryParser而其中大部分是大多数用户并不很熟悉的目前LUCENE支持的语法 Query :: ( Clause )*Clause :: [, -] [TERM :] ( TERM | ( Query )) 中间的逻辑包括and or - ||等符号而且还有短语查询和针对西文的前缀/模糊查询等个人感觉对于一般应用来说这些功能有一些华而不实其实能够实现目前类似于Google的查询语句分析功能其实对于大多数用户来说已经够了。所以Lucene早期版本的QueryParser仍是比较好的选择。 添加修改删除指定记录Document Lucene提供了索引的扩展机制因此索引的动态扩展应该是没有问题的而指定记录的修改也似乎只能通过记录的删除然后重新加入实现。如何删除指定的记录呢删除的方法也很简单只是需要在索引时根据数据源中的记录ID专门另建索引然后利用IndexReader.delete(Termterm)方法通过这个记录ID删除相应的Document。 根据某个字段值的排序功能 lucene缺省是按照自己的相关度算法score进行结果排序的但能够根据其他字段进行结果排序是一个在LUCENE的开发邮件列表中经常提到的问题很多原先基于数据库应用都需要除了基于匹配度score以外的排序功能。而从全文检索的原理我们可以了解到任何不基于索引的搜索过程效率都会导致效率非常的低如果基于其他字段的排序需要在搜索过程中访问存储字段速度回大大降低因此非常是不可取的。 但这里也有一个折中的解决方法在搜索过程中能够影响排序结果的只有索引中已经存储的docID和score这2个参数所以基于score以外的排序其实可以通过将数据源预先排好序然后根据docID进行排序来实现。这样就避免了在LUCENE搜索结果外对结果再次进行排序和在搜索过程中访问不在索引中的某个字段值。 这里需要修改的是IndexSearcher中的HitCollector过程... scorer.score(new HitCollector() { private float minScore 0.0f; public final void collect(int doc, float score) { if (score 0.0f // ignore zeroed buckets (bitsnull || bits.get(doc))) { // skip docs not in bits totalHits[0]; if (score minScore) { /* 原先Lucene将docID和相应的匹配度score例入结果命中列表中 * hq.put(new ScoreDoc(doc, score)); // update hit queue * 如果用doc 或 1/doc 代替 score就实现了根据docID顺排或逆排 * 假设数据源索引时已经按照某个字段排好了序而结果根据docID排序也就实现了 * 针对某个字段的排序甚至可以实现更复杂的score和docID的拟合。 */ hq.put(new ScoreDoc(doc, (float) 1/doc )); if (hq.size() nDocs) { // if hit queue overfull hq.pop(); // remove lowest in hit queue minScore ((ScoreDoc)hq.top()).score; // reset minScore } } } } }, reader.maxDoc()); 更通用的输入输出接口 虽然lucene没有定义一个确定的输入文档格式但越来越多的人想到使用一个标准的中间格式作为Lucene的数据导入接口然后其他数据比如PDF只需要通过解析器转换成标准的中间格式就可以进行数据索引了。这个中间格式主要以XML为主类似实现已经不下45个数据源: WORD PDF HTML DB other \ | | | / XML中间格式 | Lucene INDEX 目前还没有针对MSWord文档的解析器因为Word文档和基于ASCII的RTF文档不同需要使用COM对象机制解析。这个是我在Google上查的相关资料http://www.intrinsyc.com/products/enterprise_applications.asp另外一个办法就是把Word文档转换成texthttp://www.winfield.demon.nl/index.html 索引过程优化 索引一般分2种情况一种是小批量的索引扩展一种是大批量的索引重建。在索引过程中并不是每次新的DOC加入进去索引都重新进行一次索引文件的写入操作文件I/O是一件非常消耗资源的事情。 Lucene先在内存中进行索引操作并根据一定的批量进行文件的写入。这个批次的间隔越大文件的写入次数越少但占用内存会很多。反之占用内存少但文件IO操作频繁索引速度会很慢。在IndexWriter中有一个MERGE_FACTOR参数可以帮助你在构造索引器后根据应用环境的情况充分利用内存减少文件的操作。根据我的使用经验缺省Indexer是每20条记录索引后写入一次每将MERGE_FACTOR增加50倍索引速度可以提高1倍左右。 搜索过程优化 lucene支持内存索引这样的搜索比基于文件的I/O有数量级的速度提升。http://www.onjava.com/lpt/a/3273而尽可能减少IndexSearcher的创建和对搜索结果的前台的缓存也是必要的。 Lucene面向全文检索的优化在于首次索引检索后并不把所有的记录Document具体内容读取出来而起只将所有结果中匹配度最高的头100条结果TopDocs的ID放到结果集缓存中并返回这里可以比较一下数据库检索如果是一个10,000条的数据库检索结果集数据库是一定要把所有记录内容都取得以后再开始返回给应用结果集的。所以即使检索匹配总数很多Lucene的结果集占用的内存空间也不会很多。对于一般的模糊检索应用是用不到这么多的结果的头100条已经可以满足90%以上的检索需求。 如果首批缓存结果数用完后还要读取更后面的结果时Searcher会再次检索并生成一个上次的搜索缓存数大1倍的缓存并再重新向后抓取。所以如果构造一个Searcher去查1120条结果Searcher其实是进行了2次搜索过程头100条取完后缓存结果用完Searcher重新检索再构造一个200条的结果缓存依此类推400条缓存800条缓存。由于每次Searcher对象消失后这些缓存也访问那不到了你有可能想将结果记录缓存下来缓存数尽量保证在100以下以充分利用首次的结果缓存不让Lucene浪费多次检索而且可以分级进行结果缓存。 Lucene的另外一个特点是在收集结果的过程中将匹配度低的结果自动过滤掉了。这也是和数据库应用需要将搜索的结果全部返回不同之处。 我的一些尝试 支持中文的Tokenizer这里有2个版本一个是通过JavaCC生成的对CJK部分按一个字符一个TOKEN索引另外一个是从SimpleTokenizer改写的对英文支持数字和字母TOKEN对中文按迭代索引。基于XML数据源的索引器XMLIndexer因此所有数据源只要能够按照DTD转换成指定的XML就可以用XMLIndxer进行索引了。根据某个字段排序按记录索引顺序排序结果的搜索器IndexOrderSearcher因此如果需要让搜索结果根据某个字段排序可以让数据源先按某个字段排好序比如PriceField这样索引后然后在利用这个按记录的ID顺序检索的搜索器结果就是相当于是那个字段排序的结果了。 从Lucene学到更多 Luene的确是一个面对对象设计的典范 所有的问题都通过一个额外抽象层来方便以后的扩展和重用你可以通过重新实现来达到自己的目的而对其他模块而不需要简单的应用入口Searcher, Indexer并调用底层一系列组件协同的完成搜索任务所有的对象的任务都非常专一比如搜索过程QueryParser分析将查询语句转换成一系列的精确查询的组合(Query),通过底层的索引读取结构IndexReader进行索引的读取并用相应的打分器给搜索结果进行打分/排序等。所有的功能模块原子化程度非常高因此可以通过重新实现而不需要修改其他模块。除了灵活的应用接口设计Lucene还提供了一些适合大多数应用的语言分析器实现SimpleAnalyser,StandardAnalyser这也是新用户能够很快上手的重要原因之一。 这些优点都是非常值得在以后的开发中学习借鉴的。作为一个通用工具包Lunece的确给予了需要将全文检索功能嵌入到应用中的开发者很多的便利。 此外通过对Lucene的学习和使用我也更深刻地理解了为什么很多数据库优化设计中要求比如 尽可能对字段进行索引来提高查询速度但过多的索引会对数据库表的更新操作变慢而对结果过多的排序条件实际上往往也是性能的杀手之一。很多商业数据库对大批量的数据插入操作会提供一些优化参数这个作用和索引器的merge_factor的作用是类似的20%/80%原则查的结果多并不等于质量好尤其对于返回结果集很大如何优化这头几十条结果的质量往往才是最重要的。尽可能让应用从数据库中获得比较小的结果集因为即使对于大型数据库对结果集的随机访问也是一个非常消耗资源的操作。 参考资料 Apache: Lucene Projecthttp://jakarta.apache.org/lucene/Lucene开发/用户邮件列表归档http://www.mail-archive.com/lucene-devjakarta.apache.org/http://www.mail-archive.com/lucene-userjakarta.apache.org/ The Lucene search engine: Powerful, flexible, and freehttp://www.javaworld.com/javaworld/jw-09-2000/jw-0915-Lucene_p.html Lucene Tutorialhttp://www.darksleep.com/puff/lucene/lucene.html Notes on distributed searching with Lucenehttp://home.clara.net/markharwood/lucene/ 中文语言的切分词http://www.google.com/search?sourceidnavclienthlzh-CNqchinesewordsegment 搜索引擎工具介绍http://searchtools.com/ Lucene作者Cutting的几篇论文和专利http://lucene.sourceforge.net/publications.html Lucene的.NET实现dotLucenehttp://sourceforge.net/projects/dotlucene/ Lucene作者Cutting的另外一个项目基于Java的搜索引擎Nutchhttp://www.nutch.org/ http://sourceforge.net/projects/nutch/ 关于基于词表和N-Gram的切分词比较http://china.nikkeibp.co.jp/cgi-bin/china/news/int/int200302100112.html2005-01-08 Cutting在Pisa大学做的关于Lucene的讲座非常详细的Lucene架构解说 特别感谢前网易CTO许良杰(Jack Xu)给我的指导是您将我带入了搜索引擎这个行业。转载于:https://www.cnblogs.com/likwo/archive/2009/10/20/1586724.html
