国产永久av在线,韩日一区二区,校园春色亚洲色图

淘声依旧 — Wed, 29 Oct 2008 02:08:00 GMT

1, highlighter.setTextFragmenter(new SimpleFragmenter(15))
�q�个控制昄��的结果数量多��?
�l�果展现:
String result= highlighter.getBestFragment(tokenStream, hits.doc(i).get("key"));

淘声依旧 2008-10-29 10:08 发表评论

[转]lucene学习�W�记�?-- 关于高亮昄��和显�C�部分原始文件的原则

淘声依旧 — Wed, 29 Oct 2008 02:06:00 GMT

高亮昄��查询��?br />
有一个能使搜索引擎变得更友好的办法，那就是向你的用户提供一些搜索命中结果的上下文，而且更�ؓ重要的是�q�样做是非常有用的。最好的例子��是本系�l�用户在查找天气Web服务时的搜烦�l�果。如下图1所�C�，每个命中�l�果包括了匹配文档的三行左右的内容，�q�且��查询项高亮昄��? 来。通常�Q�我们只需要对搜烦��?上下文内�Ҏ(gu��)��览一眼就��以了解该结果是否值得我们深入地进行研�I��?br />

�?.1 高亮昄��查询��?br />

Highlighter 最�q�已�l�充分升�U��ؓ一个复杂而灵�zȝ��工具。Highlighter包括了三个主要部分：�D�划分器�Q�Fragmenter�Q�、计分器�Q�Scorer�Q�和格式化器�Q�Formatter�Q�。这几个部分对应于Java的同名接口，�q�且每部分都有一个内�|�的实现以便我们使用。最��单的Highlighter��返回在匚w��周围的最��x��落，�q��用HTML�?lt;B>��这些项标记出来�Q?br />
String text = “The quick brown fox jumps over the lazy dog”;
TermQuery query = new TermQuery(new Term(“field”, “fox”));
Scorer scorer = new QueryScorer(query);
Highlighter highlighter = new Highlighter(scorer);
TokenStream tokenStream =
new SimpleAnalyzer().tokenStream(“field”,
new StringReader(text));
System.out.println(highlighter.getBestFragment(tokenStream,text));
前述代码��生如下输�?br />
The quick brown fox jumps over the lazy dog

Highlighter不仅需要你提供记分器和需要高亮显�C�的文本�Q�还需要一个TokenStream实例。这个TokenStream实例是由分析器生成的。�ؓ了成功地寚w��q�行高亮昄��Q�Query中的�q�些��w��要匹配TokenStream产生的Token实例。我们提供的文本则被用于生成 TokenStream�Q�而这个TokenStream又被用作高亮昄��的原始文本。每个由TokenStream生成的Token实例都包含语汇单元的位置信息�Q�这些信息用来指�C�原始文本中高亮部分的�v始和�l�束位置�?

Highlighter利用Fragmenter��原始文本分割成多个片段。内�|�的SimpleFragmenter��原始文本分割成相同大小的片�D�，片段默认的大��ؓ100个字�W�。这个大��是可控制的�?br />
QueryScorer是内�|�的计分器。计分器的工作首先是��片�D�|��序。QueryScorer使用的项是从用户输入的查询中得到的；它会从原始输入的�? 词、词�l�和布尔查询中提取项�Q��ƈ且基于相应的加权因子�Q�boost factor�Q�给它们加权。�ؓ了便于QueryScoere使用�Q�还必须�Ҏ(gu��)��询的原始形式�q�行重写。比如，带通配�W�查询、模�p�查询、前�~�查询以及范围查询 �{�，都被重写为BoolenaQuery中所使用的项。在��Query实例传递到QueryScorer之前�Q�可以调�? Query.rewrite(IndexReader)�Ҏ(gu��)��来重写Query对象�Q�否则，你必��ȝ��保用戯��入的查询文本��是Lucene直接可以处理最�? 本的��）�?br />
最后，格式化器�Q�Formatter�Q�用于装饰项文本。如果不指定其他的格式化器，Lucene会默认��用内�|�的格式化器 SimpleHTMLFormatter�Q�这个格式化器将会用HTML的黑体开始标�{�（begin bold tags �Q�和黑体�l�束标签�Q�end bold tags �Q�来标识出高亮显�C�的��Ҏ(gu��)��本。Highlighter默认��C��用SimpleHTMLFormatter�? SimpleFragmenter�q�两个格式化器。每一个由Formatter高亮昄��的项都将会带有一个语汇单元评分。当使用QueryScorer �Ӟ��q�个评分��作为查询该��的加权因子。这个语汇单元评分能够被用来军_��该项的重要性。要利用�q�个�Ҏ(gu��)��就必须实现自定义的格式化器�?br />
注：我们��目所用到�?Lucene API是基于最新版Lucene2.1的，如果你用的是以前版本可能�q�些例子不能很好的运行。不�q�我觉得看了以上的东西，再结合网上大量的Lucene�? 料还有一些例子就能对Lucene有一定的理解了，最��L��可以开始��用Lucene着手项目了�?br /> 另外�Q�在文章开始提��C��Q�我们以前一起做��目时没有��用过Lucene�Q�这�ơ是我们团队的�n宁同学开始接触Lucene�Q�然后在我们��目中��用这个工��P�� 我是在他指导的基��上对Lucene有一点点的理解而已。感兴趣的可以就��目中的更细节问题跟赵宁同学联系�Q�MSN:program- maker@hotmail.com

淘声依旧 2008-10-29 10:06 发表评论

[转]lucene学习�W�记十一 -- 建烦引优�?复杂排序HitCollector,匚w��法

淘声依旧 — Wed, 29 Oct 2008 02:06:00 GMT

1, 提高建烦引的速度

/**
* 在IndexWriter中有一个MERGE_FACTOR参数可以帮助你在构造烦引器后根据应用环境的情况充分利用内存减少文�g的操作。根据我的��用经验：�~�省Indexer是每20条记录烦引后写入一�ơ，每将MERGE_FACTOR增加50倍，索引速度可以提高1倍左叟�?br /> */
indexWriter.setMergeFactor(1000);

2, 排序
« �?汉化 �?国际�?| (回到Blog入口)|(回到首页) | Resin学习�W�记 »

Lucene�Q�基于Java的全文检索引擎简�?br /> 作者：车东发表于：2002-08-06 18:08 最后更��C��Q?007-04-12 11:04
版权声明�Q�可以�Q意�{载，转蝲时请务必以超链接形式标明文章原始出处和作者信息及本声明�?br /> http://www.chedong.com/tech/lucene.html
--------------------------------------------------------------------------------
Lucene是一个基于Java的全文烦引工具包�?br />
��Z��Java的全文烦引引擎Lucene��介：关于作者和Lucene的历�?
全文��索的实现�Q�Luene全文索引和数据库索引的比�?
中文切分词机制简介：��Z��词库和自动切分词��法的比�?
具体的安装和使用��介：�pȝ��l�构介绍和演�C?
Hacking Lucene�Q�简化的查询分析器，删除的实玎ͼ�定制的排序，应用接口的扩�?
从Lucene我们�q�可以学��C��?
��Z��Java的全文烦�?��索引擎——Lucene

Lucene不是一个完整的全文索引应用�Q�而是是一个用Java写的全文索引引擎工具包，它可以方便的嵌入到各�U�应用中实现针对应用的全文烦�?��索功能�?br />
Lucene的作者：Lucene的�A献者Doug Cutting是一位资深全文烦�?��索专�Ӟ��曄��是V-Twin搜烦引擎(Apple的Copland操作�pȝ��的成��׃��一)的主要开发者，后在 Excite担�Q高��pȝ��架构设计师，目前从事于一些INTERNET底层架构的研�I�。他贡献出的Lucene的目标是为各�U�中��型应用�E�序加入全文��? 功能�?br />
Lucene的发展历�E�：早先发布在作者自��q��www.lucene.com�Q�后来发布在SourceForge�Q?001�q�年底成为APACHE基金�? jakarta的一个子��目�Q�http://jakarta.apache.org/lucene/

已经有很多Java��目都��用了Lucene作�ؓ其后台的全文索引引擎�Q�比较著名的有：

Jive�Q�WEB论坛�pȝ��Q?
Eyebrows�Q�邮件列表HTML归档/��览/查询�pȝ��Q�本文的主要参考文�?#8220;TheLucene search engine: Powerful, flexible, and free”作者就是EyeBrows�pȝ��的主要开发者之一�Q�而EyeBrows已经成�ؓ目前APACHE��目的主要邮件列表归档系�l��?
Cocoon:��Z��XML的web发布框架�Q�全文检索部分��用了Lucene
Eclipse:��Z��Java的开攑ּ�发��^収ͼ�帮助部分的全文烦引��用了Lucene

对于中文用户来说�Q�最兛_��的问题是其是否支持中文的全文��索。但通过后面对于Lucene的结构的介绍�Q�你会了解到�׃��Lucene良好架构设计�Q�对中文的支持只需对其语言词法分析接口�q�行扩展��p��实现对中文检索的支持�?br />
全文��索的实现机制

Lucene的API接口设计的比较通用�Q�输入输出结构都很像数据库的�?=>记录==>字段�Q�所以很多传�l�的应用的文件、数据库�{�都可以�? 较方便的映射到Lucene的存储结�?接口中。��M��上看�Q�可以先把Lucene当成一个支持全文烦引的数据库系�l��?br />
比较一下Lucene和数据库�Q?br />
Lucene 数据�?
索引数据源：doc(field1,field2...) doc(field1,field2...) \ indexer / _____________ | Lucene Index| -------------- / searcher \ �l�果输出�Q�Hits(doc(field1,field2) doc(field1...)) 索引数据源：record(field1,field2...) record(field1..) \ SQL: insert/ _____________ | DB Index | ------------- / SQL: select \�l�果输出�Q�results(record(field1,field2..) record(field1...))
Document�Q�一个需要进行烦引的“单元”
一个Document由多个字�D늻��?Record�Q�记录，包含多个字段
Field�Q�字�D?Field�Q�字�D?
Hits�Q�查询结果集�Q�由匚w��的Document�l�成 RecordSet�Q�查询结果集�Q�由多个Record�l�成

全文��?≠ like "%keyword%"

通常比较厚的书籍后面常常附关键词索引表（比如�Q�北京：12, 34��，上�v�Q?,77��?#8230;…�Q�，它能够帮助读者比较快地找到相兛_��容的��늠�。而数据库索引能够大大提高查询的速度原理也是一��P��惛_��一下通过书后面的�? 引查扄��速度要比一��一��地��d��定w��多少�?#8230;…而烦引之所以效率高�Q�另外一个原因是它是排好序的。对于检索系�l�来说核心是一个排序问题�?br />
�׃��数据库烦引不是�ؓ全文索引设计的，因此�Q��用like "%keyword%"�Ӟ��数据库烦引是不�v作用的，在��用like查询�Ӟ��搜烦�q�程又变成类��g��一��页��M��的遍历过�E�了�Q�所以对于含有模�p�查询的数据�? 服务来说�Q�LIKE�Ҏ(gu��)��能的危��x��极大的。如果是需要对多个关键词进行模�p�匹配：like"%keyword1%" and like "%keyword2%" ...其效率也��可惌��知了�?br />
所以徏立一个高效检索系�l�的关键是徏立一个类��g��U�技索引一��L��反向索引机制�Q�将数据源（比如多篇文章�Q�排序顺序存储的同时�Q�有另外一个排好序的关键词�? 表，用于存储关键�?=>文章映射关系�Q�利用这��L��映射关系索引�Q�[关键�?=>出现关键词的文章�~�号�Q�出现次敎ͼ�甚至包括位置�Q��v始偏�U? 量，�l�束偏移量）�Q�出现频率]�Q�检索过�E�就是把模糊查询变成多个可以利用索引的精��查询的逻辑�l�合的过�E�。从而大大提高了多关键词查询的效率，所以，全文 ��索问题归�l�到最后是一个排序问题�?br />
由此可以看出模糊查询相对数据库的�_��查询是一个非�怸��定的问题，�q�也是大部分数据库对全文��索支持有限的原因。Lucene最核心的特征是通过�Ҏ(gu��)��? 索引�l�构实现了传�l�数据库不擅长的全文索引机制�Q��ƈ提供了扩展接口，以方侉K��对不同应用的定制�?br />
可以通过一下表格对比一下数据库的模�p�查询：

Lucene全文索引引擎数据�?
索引 ��数据源中的数据都通过全文索引一一建立反向索引对于LIKE查询来说�Q�数据传�l�的索引是根本用不上的。数据需要逐个便利记录�q�行GREP式的模糊匚w��Q�比有烦引的搜烦速度要有多个数量�U�的下降�?
匚w��效果通过词元(term)�q�行匚w��Q�通过语言分析接口的实玎ͼ�可以实现对中文等非英语的支持�?使用�Q�like "%net%" 会把netherlands也匹配出来，
多个关键词的模糊匚w��Q��用like "%com%net%"�Q�就不能匚w��词序颠倒的xxx.net..xxx.com
匚w��?有匹配度��法�Q�将匚w��E�度�Q�相似度�Q�比较高的结果排在前面�?没有匚w��E�度的控�Ӟ��比如有记录中net出现5词和出现1�ơ的�Q�结果是一��L��?
�l�果输出通过特别的算法，��最匚w��度最高的�?00条结果输出，�l�果集是�~�冲式的��批量读取的�?�q�回所有的�l�果集，在匹配条目非常多的时候（比如上万条）需要大量的内存存放�q�些临时�l�果集�?
可定制�?通过不同的语�a�分析接口实现�Q�可以方便的定制出符合应用需要的索引规则�Q�包括对中文的支持）没有接口或接口复杂，无法定制
�l�论高负载的模糊查询应用�Q�需要负责的模糊查询的规则，索引的资料量比较�?使用率低�Q�模�p�匹配规则简单或者需要模�p�查询的资料量少

全文��索和数据库应用最大的不同在于�Q�让最相关的头100条结果满��?8%以上用户的需�?br />
Lucene的创��C��处：

大部分的搜烦�Q�数据库�Q�引擎都是用B树结构来�l�护索引�Q�烦引的更新会导致大量的IO操作�Q�Lucene在实��C��Q�对此稍微有所改进�Q�不是维护一个烦引文 �Ӟ��而是在扩展烦引的时候不断创建新的烦引文�Ӟ��然后定期的把�q�些新的��烦引文件合�q�到原先的大索引中（针对不同的更新策略，�Ҏ(gu��)��的大��可以调��_��Q�这�? 在不影响��索的效率的前提下�Q�提高了索引的效率�?br />
Lucene和其他一些全文检索系�l?应用的比较：

Lucene 其他开源全文检索系�l?
增量索引和批量烦�?可以�q�行增量的烦�?Append)�Q�可以对于大量数据进行批量烦引，�q�且接口设计用于优化扚w��索引和小扚w��的增量烦引�?很多�pȝ��只支持批量的索引�Q�有时数据源有一点增加也需要重建烦引�?
数据�?Lucene没有定义具体的数据源�Q�而是一个文档的�l�构�Q�因此可以非常灵�zȝ��适应各种应用�Q�只要前端有合适的转换器把数据源�{换成相应�l�构�Q�，很多�pȝ��只针对网��，�~�Z��其他格式文档的灵�z�L��?
索引内容抓取 Lucene的文档是由多个字�D늻�成的�Q�甚臛_��以控刉��些字�D�需要进行烦引，那些字段不需要烦引，�q�一步烦引的字段也分为需要分词和不需要分词的�c�d��Q?br /> 需要进行分词的索引�Q�比如：标题�Q�文章内容字�D?br /> 不需要进行分词的索引�Q�比如：作�?日期字段 �~�Z��通用性，往往��文档整个烦引了
语言分析通过语言分析器的不同扩展实现�Q?br /> 可以�q��o掉不需要的词：an the of �{�，
西文语法分析�Q�将jumps jumped jumper都归�l�成jump�q�行索引/��?br /> 非英文支持：对亚�z�语�a��Q�阿拉伯语言的烦引支�?�~�Z��通用接口实现
查询分析通过查询分析接口的实玎ͼ�可以定制自己的查询语法规则：
比如�Q?多个关键词之间的 + - and or关系�{?　
�q�发讉K�� 能够支持多用��L��使用　

关于亚洲语言的的切分词问�?Word Segment)

对于中文来说�Q�全文烦引首先还要解决一个语�a�分析的问题，对于英文来说�Q�语句中单词之间是天焉��过�I�格分开的，但亚�z�语�a�的中日韩文语句中的字是一个字挨一个，所有，首先要把语句中按“�?#8221;�q�行索引的话�Q�这个词如何切分出来��是一个很大的问题�?br />
首先�Q�肯定不能用单个字符�?si-gram)为烦引单元，否则�?#8220;上�v”�Ӟ��不能让含�?#8220;��上”也匹配�?br />
但一句话�Q?#8220;北京天安�?#8221;�Q�计��机如何按照中文的语�a�习惯�q�行切分呢？
“北京天安�?#8221; �q�是“�?�?天安�?#8221;�Q�让计算��够按照语�a�习惯�q�行切分�Q�往往需要机器有一个比较丰富的词库才能够比较准��的识别��句中的单词�?br />
另外一个解决的办法是采用自动切分算法：��单词按�?元语�?bigram)方式切分出来�Q�比如：
"北京天安�? ==> "北京京天天安安门"�?br />
�q�样�Q�在查询的时候，无论是查�?北京" �q�是查询"天安�?�Q�将查询词组按同��L��规则�q�行切分�Q?北京"�Q?天安安门"�Q�多个关键词之间按与"and"的关�pȝ��合，同样能够正确地映��到相应的烦引中。这�U�方式对于其他亚�z�语�a��Q�韩文，日文都是通用的�?br />
��Z��自动切分的最大优�Ҏ(gu��)��没有词表�l�护成本�Q�实现简单，�~�点是烦引效率低�Q�但对于中小型应用来��_��Z��2元语法的切分�q�是够用的。基�?元切分后的烦引一般大��和源文件差不多�Q�而对于英文，索引文�g一般只有原文�g�?0%-40%不同�Q?br />

自动切分词表切分
实现实现非常��?实现复杂
查询增加了查询分析的复杂�E�度�Q?适于实现比较复杂的查询语法规�?
存储效率索引冗余大，索引几乎和原文一样大索引效率高，为原文大��的30�Q�左�?
�l�护成本无词表维护成�?词表�l�护成本非常高：中日韩等语言需要分别维护�?br /> �q�需要包括词频统计等内容
适用领域嵌入式系�l�：�q�行环境资源有限
分布式系�l�：无词表同步问�?br /> 多语�a�环境�Q�无词表�l�护成本 �Ҏ(gu��)��询和存储效率要求高的专业搜烦引擎

目前比较大的搜烦引擎的语�a�分析��法一般是��Z��以上2个机制的�l�合。关于中文的语言分析��法�Q�大家可以在Google查关键词"wordsegment search"能找到更多相关的资料�?br />
安装和��?br />
下蝲�Q�http://jakarta.apache.org/lucene/

注意�Q�Lucene中的一些比较复杂的词法分析是用JavaCC生成的（JavaCC�Q�JavaCompilerCompiler�Q�纯Java的词法分�? 生成器）�Q�所以如果从源代码编译或需要修改其中的QueryParser、定制自��q��词法分析器，�q�需要从 https://javacc.dev.java.net/下蝲javacc�?br />
lucene的组成结构：对于外部应用来说索引模块(index)和检索模�?search)是主要的外部应用入口

org.apache.Lucene.search/ 搜烦入口
org.apache.Lucene.index/ 索引入口
org.apache.Lucene.analysis/ 语言分析�?
org.apache.Lucene.queryParser/ 查询分析�?
org.apache.Lucene.document/ 存储�l�构
org.apache.Lucene.store/ 底层IO/存储�l�构
org.apache.Lucene.util/ 一些公用的数据�l�构

��单的例子演示一下Lucene的��用方法：

索引�q�程�Q�从命��o行读取文件名�Q�多个）�Q�将文�g分�\�?path字段)和内�?body字段)2个字�D�进行存储，�q�对内容�q�行全文索引�Q�烦引的单位�? Document对象�Q�每个Document对象包含多个字段Field对象�Q�针对不同的字段属性和数据输出的需求，对字�D�还可以选择不同的烦�?存储�? �D�规则，列表如下�Q?�Ҏ(gu��)�� 切词索引存储用�?
Field.Text(String name, String value) Yes Yes Yes 切分词烦引�ƈ存储�Q�比如：标题�Q�内容字�D?
Field.Text(String name, Reader value) Yes Yes No 切分词烦引不存储�Q�比如：META信息�Q?br /> 不用于返回显�C�，但需要进行检索内�?
Field.Keyword(String name, String value) No Yes Yes 不切分烦引�ƈ存储�Q�比如：日期字段
Field.UnIndexed(String name, String value) No No Yes 不烦引，只存储，比如�Q�文件�\�?
Field.UnStored(String name, String value) Yes Yes No 只全文烦引，不存�?

public class IndexFiles { //使用�Ҏ(gu��)��Q? IndexFiles [索引输出目录] [索引的文件列表] ... public static void main(String[] args) throws Exception { String indexPath = args[0]; IndexWriter writer; //用指定的语言分析器构造一个新的写索引器（�W?个参数表�C�是否�ؓ�q�加索引�Q?writer = new IndexWriter(indexPath, new SimpleAnalyzer(), false); for (int i=1; i); InputStream is = new FileInputStream(args); //构造包�?个字�D�Field的Document对象 //一个是路径path字段�Q�不索引�Q�只存储 //一个是内容body字段�Q�进行全文烦引，�q�存�?Document doc = new Document(); doc.add(Field.UnIndexed("path", args)); doc.add(Field.Text("body", (Reader) new InputStreamReader(is))); //��文档写入烦�? writer.addDocument(doc); is.close(); }; //关闭写烦引器 writer.close(); }}　索引�q�程中可以看刎ͼ�

语言分析器提供了抽象的接口，因此语言分析(Analyser)是可以定制的�Q�虽然lucene�~�省提供�?个比较通用的分析器 SimpleAnalyser和StandardAnalyser�Q�这2个分析器�~�省都不支持中文�Q�所以要加入对中文语�a�的切分规则，需要修改这2个分�? 器�?
Lucene�q�没有规定数据源的格式，而只提供了一个通用的结构（Document对象�Q�来接受索引的输入，因此输入的数据源可以是：数据库，WORD�? 档，PDF文档�Q�HTML文档……只要能够设计相应的解析�{换器��数据源构造成成Docuement对象卛_��q�行索引�?
对于大批量的数据索引�Q�还可以通过调整IndexerWrite的文件合�q��率属性（mergeFactor�Q�来提高扚w��索引的效率�?
��索过�E�和�l�果昄��Q?br />
搜烦�l�果�q�回的是Hits对象�Q�可以通过它再讉K��Document==>Field中的内容�?br />
假设�Ҏ(gu��)��body字段�q�行全文��索，可以��查询结果的path字段和相应查询的匚w��?score)打印出来�Q?br />
public class Search { public static void main(String[] args) throws Exception { String indexPath = args[0], queryString = args[1]; //指向索引目录的搜索器 Searcher searcher = new IndexSearcher(indexPath); //查询解析器：使用和烦引同��L��语言分析�?Query query = QueryParser.parse(queryString, "body", new SimpleAnalyzer()); //搜烦�l�果使用Hits存储 Hits hits = searcher.search(query); //通过hits可以讉K��到相应字�D늚�数据和查询的匚w��?for (int i=0; i Hacking Lucene

��化的查询分析�?br />
个�h感觉lucene成�ؓJAKARTA��目后，��d��了太多的旉��用于调试日趋复杂QueryParser�Q�而其中大部分是大多数用户�q�不很熟�(zh��n)�的�Q�目前LUCENE支持的语法：

Query ::= ( Clause )*
Clause ::= ["+", "-"] [ ":"] ( | "(" Query ")")

中间的逻辑包括�Q�and or + - &&||�{�符��P��而且�q�有"短语查询"和针对西文的前缀/模糊查询�{�，个�h感觉对于一般应用来��_��q�些功能有一些华而不实，其实能够实现目前�c�M��于Google的查询语句分析功能其实对于大多数用户来说已经够了。所以，Lucene早期版本的QueryParser仍是比较好的选择�?br />
��d��修改删除指定记录�Q�Document�Q?br />
Lucene提供了烦引的扩展机制�Q�因此烦引的动态扩展应该是没有问题的，而指定记录的修改也似乎只能通过记录的删除，然后重新加入实现。如何删除指定的记录呢？删除的方法也很简单，只是需要在索引时根据数据源中的记录ID专门另徏索引�Q�然后利用IndexReader.delete(Termterm) �Ҏ(gu��)��通过�q�个记录ID删除相应的Document�?br />
�Ҏ(gu��)��某个字段值的排序功能

lucene�~�省是按照自��q��相关度算法（score�Q�进行结果排序的�Q�但能够�Ҏ(gu��)��其他字段�q�行�l�果排序是一个在LUCENE的开发邮件列表中�l�常提到�? 问题�Q�很多原先基于数据库应用都需要除了基于匹配度�Q�score�Q�以外的排序功能。而从全文��索的原理我们可以了解刎ͼ��M��不基于烦引的搜烦�q�程效率都会 ��D��效率非常的低�Q�如果基于其他字�D늚�排序需要在搜烦�q�程中访问存储字�D�，速度回大大降低，因此非常是不可取的�?br />
但这里也有一个折中的解决�Ҏ(gu��)��Q�在搜烦�q�程中能够媄响排序结果的只有索引中已�l�存储的docID和score�q?个参敎ͼ�所以，��Z��score以外的排序，其实可以通过��数据源预先排好序，然后�Ҏ(gu��)��docID�q�行排序来实现。这样就避免了在LUCENE搜烦�l�果外对�l�果再次�q�行排序和在搜烦�q�程中访问不在烦引中的某个字�D�倹{�?br />
�q�里需要修改的是IndexSearcher中的HitCollector�q�程�Q?br />
...　scorer.score(new HitCollector() { private float minScore = 0.0f; public final void collect(int doc, float score) { if (score > 0.0f && // ignore zeroed buckets (bits==null || bits.get(doc))) { // skip docs not in bits totalHits[0]++; if (score >= minScore) { /* 原先�Q�Lucene��docID和相应的匚w��度score例入�l�果命中列表中： * hq.put(new ScoreDoc(doc, score)); // update hit queue * 如果用doc �?1/doc 代替 score�Q�就实现了根据docID��排或逆排 * 假设数据源烦引时已经按照某个字段排好了序�Q�而结果根据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());

3, 计算匚w��得分. ��于1.0的我们认为是相关的记录了.下面的代码在输出�l�果循环�? 如果要获取完全匹配的记录,

//计算匚w��得分
Explanation explanation = searcher.explain(query, hits.id(i)) ;
System.out.println("匚w��得分:"+explanation.getValue());
System.out.println("=========");

4, 关于短语匚w��的用�?br />
通过短语搜烦�Q�PhraseQuery
索引中包含了各个��的位置信息。PhraseQuery利用�q�些信息��L��索文档，在这些文档集中，我们所查找的各个项之间可能都相隔着一定的距离。例如，假设某个域中包含�?#8220;the quick brown fox jumped over the lazy dog”�q�个短语�Q�即使我们不知道�q�个短语的确切完整写法，也一样可以通过查找域中quick和fox距离相近的文档来扑և�我们需要的文档。当�Ӟ��一个简单的TermQuery也能够通过对这两个��的单独查询成功地找到同��h��档；但是在以上所讨论的情况中�Q�我们仅仅希望查到域中quick的位�|�紧挨着 fox或者隔一个不相关的单词的文档�Q�如quick [不相关的词] fox�Q��?br />
在匹配的情况下，两个��的位置之间允许的最大间隔距��ȝ��为slop。距��L��指项要按��序�l�成�l�定的短语，所需要移动位�|�的�ơ数。我们用刚刚提到的那个短语，看看slop因子是怎么样工作的。首先，我们需要构��Z��个小的基本测试构�Ӟ��E�序里用一个setUp()�Ҏ(gu��)��来烦引一个文档，�q��过 matched(String[], int)�Ҏ(gu��)��构造、执行�ƈ断言一个短语查询与我们的测试文档相匚w��Q?br />

// 建立��h��文档

�׃��只想�C��一下几个短语查询的例子�Q�因此在以上�E�序中我们简化了matched�Ҏ(gu��)��的代码。这个程序按照一定的��序��d��各个��Ҏ(gu��)��q�行短语查询。默认情�? 下，PhraseQuery的slop因子讄��?�Q�即要求查询的结果必��d��我们输入的字�W�串�l�完全精��一致地匚w��。通过setUp()�? matched()�Ҏ(gu��)��Q�测试用例对PhraseQuery的工作方式做��Z��z�的�C��。程序以查询��p�|或超出slop因子作�ؓ其边界：

�?.2 解释短语查询slop因子�Q�短�?#8220;quick fox”需要slop��gؓ1的移动才能和原文档匹配，�?#8220;fox quick”需要slop��gؓ3的移动才能匹�?br />
在短语查询中�Q�虽焉��出现的先后顺序会对slop因子的选取有一定媄响，但是我们不一定需要按照这些项在文档中出现的先后顺序来��它们添加至 PhraseQuery中。例如，如果把上�q�String数组中的两个��w��倒（先是��?#8220;fox”�Q�然后是“quick”�Q�，要和文档匚w��需要移动三个位 �|�，而不是原先的一个了。�ؓ了表辑־�更�Ş象一些，可以思考一下单�?#8220;fox”需要移动多��个位置才能位于单词“quick”的两个位�|�之后。你会发�? fox�U�d��一�ơ到达quick的位�|�，然后再移动两�ơ才能��之变�?#8220;quick X fox”�Q�从而和“quick brown fox”充分地匹配�?br />
�?.2展示了slop位置因子在这两个短语查询场景的应用是如何工作的，下面的测试用例示范了�E�序如何通过slop因子的设�|�实现对String[] {"fox", "quick"}的匹配：

现在我们开始深入学习如何对多个��进行复合查询的问题�?br />
复合��短�?br /> PhraseQuery支持复合��短语（multiple-term phrases�Q�。不��短语中有多��个��，slop因子都规定了��Ҏ(gu��)��序�U�d��位置的所允许的最大倹{��下面看看关于复合项短语查询的一个示例：

到目前�ؓ止，你已�l�了解了短语查询是如何进行匹配的�Q�下面我们把注意力�{向于短语查询�Ҏ(gu��)��档评分的影响�?br />
短语查询评分
短语查询是根据短语匹配所需要的�~�辑距离来进行评分的。项之间距离��小的匹配具有的权重也就��大。短语查询的评分因子如图3.3所�C�。评分与距离成反比关�p�，距离��大的匹配其评分��低�?br />

�?.3 短语查询的评分公�?br />
注：在QueryParser的分析表辑ּ�中双引号里的若干个项被被转换��Z��个PhraseQuery对象。Slop因子的默认值是0�Q�但是你可以�? QueryParser的查询表辑ּ�中加上~n的声明，以此来调整slop因子的倹{��例如，表达�?#8220;quick fox”~3的意义�ؓ�Q��ؓfox和quick��生成一个slop因子�?的PhraseQuery对象。更多关于PhraseQuery和slop因子�? �l�节请参�?.5.6��节。短语由传给QueryParser的分析器�q�行分析�Q�在此过�E�中�q�会加入另外一个复杂的层，�q�个内容��会�?.1.2��节中加以讨论�?/em>

淘声依旧 2008-10-29 10:06 发表评论

[转]lucene学习�W�记�?- 关于�l�果分页

淘声依旧 — Wed, 29 Oct 2008 02:04:00 GMT

一 ,Hits对象是搜索结果的集合主要有下面几个方�?[list=1]

length() ,�q�个�Ҏ(gu��)��记录有多��条�l�果�q�回(lazy loading)

doc(n) �q�回�W�n个记�?/li>

id(in) �q�回�W�n个记录的Document ID

score(n) �W�n个记录的相关�?�U�分) �׃��搜烦的结果一般比较大�Q�从性能上考虑�Q�Hits对象�q�不会真正把所有的�l�果全部取回�Q�默认情况下是保留前100个记�?对于一般的搜烦引擎,100个记录��够了).
分页的处�?/strong>
100条记录还是太多，我们多半会每��|��C?0条记录，然后分�ؓ若干��|��C�，对于分页�Q�一般有两个办法
[list=1]

在session中保留indexreader对象和hit对象�Q�翻��늚�时候提取内�?/li>
不��用session�Q�每�ơ都��单处理�ؓ重新查询 lucene推荐先��用第二个办法�Q�即每次都重新查询，�q�样做的好处是简单方便，不需要考虑session的问题，lucene的查询效率也能保证每�ơ查询时间不长，除非真正有了性能问题�Q�否则不用考虑�W�一个办法�?br />

Lucene面向全文��索的优化在于首次索引��索后�Q��ƈ不把所有的记录�Q�Document�Q�具体内容读取出来，而�v只将所有结果中匚w��度最高的�?00�? �l�果�Q�TopDocs�Q�的ID攑ֈ��l�果集缓存中�q�返回，�q�里可以比较一下数据库��索：如果是一�?0,000条的数据库检索结果集�Q�数据库是一定要把所�? 记录内容都取得以后再开始返回给应用�l�果集的。所以即使检索匹配��L��很多�Q�Lucene的结果集占用的内存空间也不会很多。对于一般的模糊��索应用是用不到这么多的结果的�Q�头100条已�l�可以满��?0%以上的检索需求�?br />
如果首批�~�存�l�果数用完后�q�要��d��更后面的�l�果时Searcher会再�ơ检索�ƈ生成一个上�ơ的搜烦�~�存数大1倍的�~�存�Q��ƈ再重新向后抓取。所以如果构造一个Searcher��L��1�Q?20条结果，Searcher其实是进行了2�ơ搜索过�E�：�?00条取完后�Q�缓存结果用完，Searcher重新��索再构�? 一�?00条的�l�果�~�存�Q�依此类推，400条缓存，800条缓存。由于每�ơSearcher对象消失后，�q�些�~�存也访问那不到了，你有可能惛_��l�果记录�~? 存下来，�~�存数尽量保证在100以下以充分利用首�ơ的�l�果�~�存�Q�不让Lucene��费多次��索，而且可以分��q�行�l�果�~�存�?br />
Lucene的另外一个特�Ҏ(gu��)��在收集结果的�q�程中将匚w��度低的结果自动过滤掉了。这也是和数据库应用需要将搜烦的结果全部返回不同之处�?br /> 我的一些尝�?/font>�Q?/li>

淘声依旧 2008-10-29 10:04 发表评论

[转]lucene学习�W�记�?分词

淘声依旧 — Wed, 29 Oct 2008 02:03:00 GMT

1, Lucene的结构框�Ӟ��
注意�Q�Lucene中的一些比较复杂的词法分析是用JavaCC生成的（JavaCC�Q�JavaCompilerCompiler�Q�纯Java的词�? 分析生成器）�Q�所以如果从源代码编译或需要修改其中的QueryParser、定制自��q��词法分析器，�q�需要从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/ 存储�l�构
org.apache.Lucene.store/ 底层IO/存储�l�构
org.apache.Lucene.util/ 一些公用的数据�l�构

2, 关于计划于词库的分词和一元分�?二元分词的区�? noise.chs 是词库中作�ؓstopword而存在的.请大家注�?
下面做了详细描述:

2006�q?1�?2�?星期�?�?2:39 am · 发表�? 默认

Lucene应用��来��多�Q�在对中文对索引�q�程中，中文分词问题也就��来��重要�?

在已有的分词模式中，目前比较常用的也是比较通用的有一元分词、二元分词和��Z��词库的分词三�U�。一元分词在Java版本上由yysun实现�Q��ƈ且已�l�收�? 到Apache。其实现方式比较��单，卛_��每一个汉字作��Z��个Token�Q�例如：“�q�是中文�?#8221;�Q�在�l�过一元分词模式分词后的结果�ؓ五个Token�Q�这�? 是、中、文、字。而二元分词，则将两个相连的汉字作��Z��个Token划分�Q�例如：“�q�是中文�?#8221;�Q�运用二元分词模式分词后�Q�得到的�l�果为：�q�是、是中、中文、文字�?

一元分词和二元分词实现原理比较��单，基本支持所有东方语�a�。但二者的�~�陷也比较明显。一元分词单�U�的考虑了中文的文字而没有考虑��C��文的词性，例如在上 �q�的例子中，“中文”�?#8220;文字”�q�两个十分明昄��中文词语��没有被识别出来。相反，二元分词则分��Z��太多的冗余的中文词，如上所�q�ͼ�“�q�是”�?#8220;是中”�? 无意义的文字�l�合竟被划分��Z��个词语，而同��L��~�陷�Q�命中的词语也不十分准确�Q�如上：�?#8220;�q�是中文�?#8221;中，“中文�?#8221;�q�个词语应该优先考虑的。而二元分�? 也未能实现�?

��Z��词库的分词实现难度比较大�Q�其模式也有多种�Q�如微��Y在自��q��软�g中的汉语分词、�v量的中文分词研究版，�q�有目前�?Net下实现的使用率较高的猎兔�Q? 和一些其他�h自发实现的分词工��L��{�。其都有自己的分析体�p�，虽然分析�_�ֺ�高，但实现难度大�Q�实现周期长�Q�而且�Q�对一般的中小型应用系�l�来�Ԍ��在精度的�? 求不是十分苛�ȝ��环境下，�q�种模式对系�l�对消耗是一�U�奢侈行为�?

在综合考虑一元分词、二元分词及��Z��词库的分词模式后�Q�我大胆提出一�U�基于StopWord分割的分词模式。这�U�分词模式的设计思想是，针对要分割的�D? 落，先由标点分割成标准的短句。然后根据设定的StopWord�Q�将短句由StopWord最大化分割�Q�分割�ؓ一个个词语。如�Q�输入短句�ؓ“�q�是中文�? ”�Q�设定的StopWord列表为：“�q?#8221;�?#8220;�?#8221;�Q�则最�l�的�l�果为：“中文�?#8221;�?

�q�个例子相对比较��单，举个�E�微长一点的例子�Q�输入短�?#8220;中文软�g需要具有对中文文本的输入、显�C�、编辑、输出等基本功能”�Q�设定的StopWord列表为：“�q?#8221;�?#8220;�?#8221;�?#8220;�?#8221;�?#8220;�?#8221;�?#8220;�{?#8221;�?#8220;需�?#8221;�?#8220;��h��”�Q�则分割出对�l�果列表为：

====================
中文软�g
中文文本
输入
昄��
�~�辑
输出
基本功能
====================

基本实现了想要的�l�果�Q�但其中也不乏不��之处，如上�q�的�l�果�?#8220;中文软�g”�?#8220;中文文本”应该分割��Z��个独立词“中文”�?#8220;软�g”�?#8220;文本”�Q�而不是上�q�的�l�果�?

�q�且�Q�对StopWord列表对设�|�，也是相对比较复杂的环节，没有一个确定的�U�束来设定StopWord。我的想法是�Q�可以将一些无意义的主语，�?#8220;�? ”�?#8220;�?#8221;�?#8220;�?#8221;�?#8220;我们”�?#8220;他们”�{�，动词“�?#8221;�?#8220;�?#8221;�?#8220;�?#8221;�{�等其他各种词性诸�?#8220;�?#8221;�?#8220;�?#8221;�?#8220;一”�?#8220;�?#8221;�?#8220;�?#8221;�?#8220;�?#8221;�{�等 �Q�System32目录下noise.chs文�g里的内容可以作�ؓ参考）作�ؓStopWord�?

noise.chs 是词库中作�ؓstopword而存在的.请大家注�?

3, 关于分词�?�q�可以关注这个帖�?

http://lucene-group.group.javaeye.com/group/blog/58701

自己写的一个基于词库的lucene分词�E�序--ThesaurusAnalyzer

我已�l�测试过.�q�可�?18万分�?

4, lucene的自带分词的��试如下:\

Lucene本��n提供了几个分词接�?我后来有�l�写了一个分词接�?

功能递增如下:

WhitespaceAnalyzer:仅仅是去除空��|��对字�W�没有lowcase�?不支持中�?

SimpleAnalyzer:功能��Z��WhitespaceAnalyzer,��除去letter之外的符号全部过滤掉,�q�且��所有的字符lowcase�?不支持中�?

StopAnalyzer:StopAnalyzer的功能超��了SimpleAnalyzer�Q�在SimpleAnalyzer的基��?
增加了去除StopWords的功�?不支持中�?

StandardAnalyzer:英文的处理能力同于StopAnalyzer.支持中文采用的方法�ؓ单字切分.

ChineseAnalyzer:来自于Lucene的sand box.性能�c�M��于StandardAnalyzer,�~�点是不支持中英文�؜和分�?

CJKAnalyzer:chedong写的CJKAnalyzer的功能在英文处理上的功能和StandardAnalyzer相同
但是在汉语的分词上，不能�q��o掉标点符��P��即��用二元切�?

TjuChineseAnalyzer:我写�?功能最为强�?TjuChineseAnlyzer的功能相当强�?在中文分词方面由于其调用的�ؓ ICTCLAS的java接口.所以其在中文方面性能上同与ICTCLAS.其在英文分词上采用了Lucene的StopAnalyzer,可以去除 stopWords,而且可以不区分大��写,�q��o掉各�c�L��点符�?

�E�序调试�?JBuilder 2005

package org.apache.lucene.analysis;

//Author:zhangbufeng
//TjuAILab(天��|大学人工��实验�?
//2005.9.22.11:00

import java.io.*;
import junit.framework.*;

import org.apache.lucene.*;
import org.apache.lucene.analysis.*;
import org.apache.lucene.analysis.StopAnalyzer;
import org.apache.lucene.analysis.standard.*;
import org.apache.lucene.analysis.cn.*;
import org.apache.lucene.analysis.cjk.*;
import org.apache.lucene.analysis.tjucn.*;
import com.xjt.nlp.word.*;
public class TestAnalyzers extends TestCase {

public TestAnalyzers(String name) {
super(name);
}

public void assertAnalyzesTo(Analyzer a,
String input,
String[] output) throws Exception {
//前面�?dummy"好像没有用到
TokenStream ts = a.tokenStream("dummy", new StringReader(input));
StringReader readerInput=new StringReader(input);
for (int i=0; i Token t = ts.next();
//System.out.println(t);
assertNotNull(t);
//使用下面�q�条语句卛_��以输出Token的每��的text,�q�且用空格分开
System.out.print(t.termText);
System.out.print(" ");
assertEquals(t.termText(), output);
}
System.out.println(" ");
assertNull(ts.next());
ts.close();
}
public void outputAnalyzer(Analyzer a ,String input) throws Exception{
TokenStream ts = a.tokenStream("dummy",new StringReader(input));
StringReader readerInput = new StringReader(input);
while(true){
Token t = ts.next();
if(t!=null){
System.out.print(t.termText);
System.out.print(" ");
}
else
break;

}
System.out.println(" ");
ts.close();
}

public void testSimpleAnalyzer() throws Exception {
//学习使用SimpleAnalyzer();
//SimpleAnalyzer��除去letter之外的符号全部过滤掉,�q�且��所有的字符lowcase�?
Analyzer a = new SimpleAnalyzer();
assertAnalyzesTo(a, "foo bar FOO BAR",
new String[] { "foo", "bar", "foo", "bar" });
assertAnalyzesTo(a, "foo bar . FOO <> BAR",
new String[] { "foo", "bar", "foo", "bar" });
assertAnalyzesTo(a, "foo.bar.FOO.BAR",
new String[] { "foo", "bar", "foo", "bar" });
assertAnalyzesTo(a, "U.S.A.",
new String[] { "u", "s", "a" });
assertAnalyzesTo(a, "C++",
new String[] { "c" });
assertAnalyzesTo(a, "B2B",
new String[] { "b", "b" });
assertAnalyzesTo(a, "2B",
new String[] { "b" });
assertAnalyzesTo(a, "\"QUOTED\" word",
new String[] { "quoted", "word" });
assertAnalyzesTo(a,"zhang ./ bu <> feng",
new String[]{"zhang","bu","feng"});
ICTCLAS splitWord = new ICTCLAS();
String result = splitWord.paragraphProcess("我爱大家 i LOVE chanchan");
assertAnalyzesTo(a,result,
new String[]{"�?,"�?,"大家","i","love","chanchan"});

}

public void testWhiteSpaceAnalyzer() throws Exception {
//WhiterspaceAnalyzer仅仅是去除空��|��对字�W�没有lowcase�?
Analyzer a = new WhitespaceAnalyzer();
assertAnalyzesTo(a, "foo bar FOO BAR",
new String[] { "foo", "bar", "FOO", "BAR" });
assertAnalyzesTo(a, "foo bar . FOO <> BAR",
new String[] { "foo", "bar", ".", "FOO", "<>", "BAR" });
assertAnalyzesTo(a, "foo.bar.FOO.BAR",
new String[] { "foo.bar.FOO.BAR" });
assertAnalyzesTo(a, "U.S.A.",
new String[] { "U.S.A." });
assertAnalyzesTo(a, "C++",
new String[] { "C++" });

assertAnalyzesTo(a, "B2B",
new String[] { "B2B" });
assertAnalyzesTo(a, "2B",
new String[] { "2B" });
assertAnalyzesTo(a, "\"QUOTED\" word",
new String[] { "\"QUOTED\"", "word" });

assertAnalyzesTo(a,"zhang bu feng",
new String []{"zhang","bu","feng"});
ICTCLAS splitWord = new ICTCLAS();
String result = splitWord.paragraphProcess("我爱大家 i love chanchan");
assertAnalyzesTo(a,result,
new String[]{"�?,"�?,"大家","i","love","chanchan"});
}

public void testStopAnalyzer() throws Exception {
//StopAnalyzer的功能超��了SimpleAnalyzer�Q�在SimpleAnalyzer的基��?
//增加了去除StopWords的功�?
Analyzer a = new StopAnalyzer();
assertAnalyzesTo(a, "foo bar FOO BAR",
new String[] { "foo", "bar", "foo", "bar" });
assertAnalyzesTo(a, "foo a bar such FOO THESE BAR",
new String[] { "foo", "bar", "foo", "bar" });
assertAnalyzesTo(a,"foo ./ a bar such ,./<> FOO THESE BAR ",
new String[]{"foo","bar","foo","bar"});
ICTCLAS splitWord = new ICTCLAS();
String result = splitWord.paragraphProcess("我爱大家 i Love chanchan such");
assertAnalyzesTo(a,result,
new String[]{"�?,"�?,"大家","i","love","chanchan"});

}
public void testStandardAnalyzer() throws Exception{
//StandardAnalyzer的功能最为强大，对于中文采用的�ؓ单字切分
Analyzer a = new StandardAnalyzer();
assertAnalyzesTo(a,"foo bar Foo Bar",
new String[]{"foo","bar","foo","bar"});
assertAnalyzesTo(a,"foo bar ./ Foo ./ BAR",
new String[]{"foo","bar","foo","bar"});
assertAnalyzesTo(a,"foo ./ a bar such ,./<> FOO THESE BAR ",
new String[]{"foo","bar","foo","bar"});
assertAnalyzesTo(a,"张步峰是天大学生",
new String[]{"�?,"�?,"�?,"�?,"�?,"�?,"�?,"�?});
//验证去除英文的标点符�?
assertAnalyzesTo(a,"�?/�?,�?.�?,天大<>学生",
new String[]{"�?,"�?,"�?,"�?,"�?,"�?,"�?,"�?});
//验证去除中文的标点符�?
assertAnalyzesTo(a,"张。、步。、峰是。天大。学�?,
new String[]{"�?,"�?,"�?,"�?,"�?,"�?,"�?,"�?});
}
public void testChineseAnalyzer() throws Exception{
//可见ChineseAnalyzer在功能上和standardAnalyzer的功能差不多�Q�但是可能在速度上慢于StandardAnalyzer
Analyzer a = new ChineseAnalyzer();

//�ȝ��?
assertAnalyzesTo(a,"foo bar Foo Bar",
new String[]{"foo","bar","foo","bar"});
assertAnalyzesTo(a,"foo bar ./ Foo ./ BAR",
new String[]{"foo","bar","foo","bar"});
assertAnalyzesTo(a,"foo ./ a bar such ,./<> FOO THESE BAR ",
new String[]{"foo","bar","foo","bar"});
assertAnalyzesTo(a,"张步峰是天大学生",
new String[]{"�?,"�?,"�?,"�?,"�?,"�?,"�?,"�?});
//验证去除英文的标点符�?
assertAnalyzesTo(a,"�?/�?,�?.�?,天大<>学生",
new String[]{"�?,"�?,"�?,"�?,"�?,"�?,"�?,"�?});
//验证去除中文的标点符�?
assertAnalyzesTo(a,"张。、步。、峰是。天大。学�?,
new String[]{"�?,"�?,"�?,"�?,"�?,"�?,"�?,"�?});
//不支持中英文写在一�?
// assertAnalyzesTo(a,"我爱�?i love chanchan",
/// new String[]{"�?,"�?,"�?,"i","love","chanchan"});

}
public void testCJKAnalyzer() throws Exception {
//chedong写的CJKAnalyzer的功能在英文处理上的功能和StandardAnalyzer相同
//但是在汉语的分词上，不能�q��o掉标点符��P��即��用二元切�?
Analyzer a = new CJKAnalyzer();
assertAnalyzesTo(a,"foo bar Foo Bar",
new String[]{"foo","bar","foo","bar"});
assertAnalyzesTo(a,"foo bar ./ Foo ./ BAR",
new String[]{"foo","bar","foo","bar"});
assertAnalyzesTo(a,"foo ./ a bar such ,./<> FOO THESE BAR ",
new String[]{"foo","bar","foo","bar"});

// assertAnalyzesTo(a,"�?/�?,�?.�?,天大<>学生",
// new String[]{"张步","步峰","峰是","是天","天大","大学","学生"});
//assertAnalyzesTo(a,"张。、步。、峰是。天大。学�?,
// new String[]{"张步","步峰","峰是","是天","天大","大学","学生"});
//支持中英文同时写
assertAnalyzesTo(a,"张步峰是天大学生 i love",
new String[]{"张步","步峰","峰是","是天","天大","大学","学生","i","love"});

}
public void testTjuChineseAnalyzer() throws Exception{
/**
* TjuChineseAnlyzer的功能相当强�?在中文分词方面由于其调用的�ؓICTCLAS的java接口.
* 所以其在中文方面性能上同与ICTCLAS.其在英文分词上采用了Lucene的StopAnalyzer,可以去除
* stopWords,而且可以不区分大��写,�q��o掉各�c�L��点符�?
*/
Analyzer a = new TjuChineseAnalyzer();
String input = "体育讯　在被��文淘汰之后�Q�皇马主帅博斯克拒绝接受媒体对球队后防线的批评，同时�q��ؓ自己排出的首发阵容进行了辩护�?+
"“失利是全队的责�Q�Q�而不仅仅是后防线该受指责�Q?#8221;博斯克说�Q?#8220;我�ƈ不认为我们踢得一塌糊涂�?#8221;“我们�q�入了半册��Q�而且在晋�U�的道�\上一路奋 "+
"战。即使是今天的比赛我们也有几个翻�w�的��Z��Q�但我们面对的对手非常强大，他们�t�得非常好�?#8221;“我们的球�q�应该�ؓ�q�去几个赛季里我们在冠军杯中的表现感到骄傌Ӏ?#8221;"+
"博斯克还说。对于博斯克在首发中排出了久疏战�늚�坎比亚烦�Q�赛后有记者提��Z��质疑�Q�认为完全应该将队内的另一 "+
"名球员帕文派遣上��Z��加强后卫�Uѝ��对于这一疑议�Q�博斯克拒绝承担所谓的“责�Q”�Q�认为球队的首发没有问题�?#8220;我们按照整个赛季以来的方式做了，"+
"对于人员上的变化我没有什么可说的�?#8221;对于球队在本赛季的前景，博斯克表�C�皇马还有西甲联赛的冠军作�ؓ目标�?#8220;皇家马�d里在冠军 "+
"杯中战斗��C��最后，我们在联赛中也将�q�么做�?#8221;"+
"A Java User Group is a group of people who share a common interest in Java technology and meet on a regular basis to share"+
" technical ideas and information. The actual structure of a JUG can vary greatly - from a small number of friends and coworkers"+
" meeting informally in the evening, to a large group of companies based in the same geographic area. "+
"Regardless of the size and focus of a particular JUG, the sense of community spirit remains the same. ";

outputAnalyzer(a,input);
//此处我已�l�对大文本进行过��试,不会有问题效果很�?
outputAnalyzer(a,"我爱大家 ,�Q��?I love China 我喜�Ƣ唱�?");
assertAnalyzesTo(a,"我爱大家 ,�Q�。I love China 我喜�Ƣ唱�?,
new String[]{"�?,"大家","i","love","china","喜欢","唱歌"});
}
}

淘声依旧 2008-10-29 10:03 发表评论

[转]lucene学习�W�记�? 几个问题

淘声依旧 — Wed, 29 Oct 2008 02:00:00 GMT

1, 被搜索的�l�果�?如何取得关键字周围的数据. 例如获取�W�一个关键字后面的数�?例如一�D�字�W?

我爱北京天安�?你喜�Ƣ吗.

我搜:北京
获取�l�果如何获取: 北京天安�?.
不要用substring或者正则解决了.那样对于大文本不是解��x��? 因�ؓ�q�个数据没必要全取出�?

�|�上也有人问: 做全文检索时�Q�想把查询到的附�q�的一�D�|��本提取出来，像google那样�Q�如何才能��性能根好�Q?感觉indexof substring�q�些东性能会很差，如果是很大的文本不知道大家有什么根好的办法�Q�获取什么其它组�Ӟ��

按照�?term vectors 中增加了位置和偏�U�M��息�?Grant Ingersoll & Christoph)的bug修改后的提示.应该可以扑ֈ�.

2, 高亮昄��. 下面有一例子说明. ��Z��?.0的那个bug说明也脓(chu��ng)��C��?
Lucene 中文分词�?highlight 昄��

下面�q�个需要外的包: lucene-highlighter-2.2.0.jar 支持.请下�? 否则里面关于高亮昄��的都不会�~�译成功. 下面�E�序是没有问题的.�l�果也对.��是有版主说的问�?

lucene2.0 中文高亮的问题。新手问老问题，知道的大虾赐�?

代码�Q?
public static void main(String[] args) {
try {
String text="上�v麦�ؓ公��N易发展有限公�?;
StandardAnalyzer ssss=new StandardAnalyzer();
QueryParser queryParse = new QueryParser("company_name", ssss);
SimpleHTMLFormatter sHtmlF = new SimpleHTMLFormatter("", "");
Highlighter hh = new Highlighter(sHtmlF,new QueryScorer(queryParse.parse("公司")));
TokenStream t=ssss.tokenStream("company_name",new StringReader(text));
Token tttt=t.next();
System.out.println(hh.getBestFragment(t,text));
} catch (Exception ex) {
}
}
�l�果�Q?
上�v麦�ؓ�?lt;/b>贸易发展有限�?lt;/b>�?lt;/b>

两个问题:
1�Q�怎么让单�?#8220;�?#8221;不高亮。因为我只搜索了“公司”
2�Q�怎么实现公司�q�样的高亮，而不�?lt;b>�?lt;/b>�?lt;/b>

�{?

用中文分词器,,,StandardAnalyzer是单字分词的
1、分词问�?
2、Highlighter highlighter =new Highlighter(new SimpleHTMLFormatter("",""),new QueryScorer(query));
需要有一个好的中文分词工��P��能分��Z��需要的词语�Q�然后加亮。比如你可以用ik-analyzer啊等�{�的�?

2.0bug解决::
22. 增加�?contrib/highlighter �?NullFragmenter , �q�对全文本加亮很有用�?
(Erik Hatcher)

淘声依旧 2008-10-29 10:00 发表评论

[转]lucene学习�W�记六——Lucene的搜�?IndexSearcher)

淘声依旧 — Wed, 29 Oct 2008 01:58:00 GMT

Lucene包括很多�U�不同的搜烦方式�Q�首先生成一个检索器IndexSearcher searcher = new IndexSearcher("Index_Path", new StandardAnalyzer(), true)�Q�然后再调用searcher.search(query)�Q�其中典型的query查询方式有以下几�U�：

1�Q�按词条搜烦�Q?strong>TermQuery�Q�即搜烦某一词条�?br /> �Ҏ(gu��)��如下�Q�Query query = new TermQuery(new Term("field", "keyword"));
其中参数field指欲查找的字�D�，keyword指欲��索的关键字�?/p>
2�Q�在某一范围�c�L��索：RangeQuery
�Ҏ(gu��)��如下�Q�RangeQuery query = new RangeQuery(begin, end, include);
其中参数begin和end均是一个Term对象�Q�分别指在烦引中相应Term的�v始位�|�和�l�束位置。include是一个boolean��|��true表是包含起始和结束位�|�，false表示不包含边界倹{�?/p>
3�Q�多关键字的搜烦�Q?strong>PhraseQuery
�Ҏ(gu��)��如下�Q?br /> PhraseQuery query = new PhraseQuery();
query.add(new Term("content","keyword1"));
query.add(new Term("content","keyword2"));
�? 注意的是PhraseQuery�c�M��有一个setSlop�Ҏ(gu��)��Q�该�Ҏ(gu��)��用于讑֮�一个称之�ؓ"坡度"的变量，来确定关键字之间是否允许、允许多��个无关词汇存在。默认��gؓ0�Q�即两个关键字之间无��M��词汇存在�Q�才能被搜烦到。设�|�该��g��后，只有当两个关键字之间无关词的数目��于�{�于坡度值是�Q�才能被搜烦到。（文章末尾�l�出了具体例子）

4�Q��用通配�W�搜索：WildcardQuery
使用�Ҏ(gu��)��c�M��?�Q�，只不�q�字�D늚�关键字允�怋��?�Q�代表一个字�W�）�?�Q�代表多个字�W�）

另外�Q�还有以下不同的搜烦�Ҏ(gu��)��Q?/p>
“与或”搜烦BooleanQuery�?/strong>使用前缀搜烦PerfixQuery�?/strong>使用短语�~�搜烦PhrasePrefixQuery�?/strong>模糊查询搜烦FuzzyQuery�{��?/strong>

/*
* 多关键字搜烦的例�?/span>*/
package testlucene;
import org.apache.lucene.analysis.standard.*;
import org.apache.lucene.document.*;
import org.apache.lucene.index.*;
import org.apache.lucene.search.*;
public class PhraseQueryTest {
public static void main(String[] args)throws Exception{
  Document doc1 = new Document();
  doc1.add(new Field("content","david mary smith robert",Field.Store.YES,Field.Index.TOKENIZED));
  doc1.add(new Field("title","doc1",Field.Store.YES,Field.Index.TOKENIZED));
  Document doc2 = new Document();
  doc2.add(new Field("content","david smith mary robert",Field.Store.YES,Field.Index.TOKENIZED));
  doc2.add(new Field("title","doc2",Field.Store.YES,Field.Index.TOKENIZED));
  Document doc3 = new Document();
  doc3.add(new Field("content","david smith robert mary",Field.Store.YES,Field.Index.TOKENIZED));
  doc3.add(new Field("title","doc3",Field.Store.YES,Field.Index.TOKENIZED));

  IndexWriter writer = new IndexWriter("c:\\index",new StandardAnalyzer(),true);
  //writer.setUseCompoundFile(true); //讄��为�؜合烦引格�?/span>
  writer.addDocument(doc1);
  writer.addDocument(doc2);
  writer.addDocument(doc3);
  writer.close();


  IndexSearcher searcher = new IndexSearcher("c:\\index");
  Term word1 = new Term("content","david");
  Term word2 = new Term("content","mary");
  Term word3 = new Term("content","smith");
  Term word4 = new Term("content","robert");
  PhraseQuery query = new PhraseQuery();
  query.add(word1);
  query.add(word2);
  query.add(word3);
  query.setSlop(Integer.MAX_VALUE);
  Hits hits = searcher.search(query);
  Print.printResult(hits,"david and mary");
}
}

淘声依旧 2008-10-29 09:58 发表评论

[转]lucene学习�W�记�?

淘声依旧 — Wed, 29 Oct 2008 01:54:00 GMT

Lucene实现�Ҏ(gu��)��询结果的排序�Q?/p>
Sort sort = new Sort(new SortField("isbn", false)); //单个字段

Sort sort = new Sort(new SortField[]{new SortField("isbn", false), new SortField("pbl_dt", true)}); //多个字段

其中,SortField的构造函��C��W�二个参数能够确定是升序�q�是降序�?true�Q�降序； false�Q�升�?

提醒�Q�烦引中tokenized的字�D�|��不能被排序的�Q�否则会抛异常�?/p>

package com.lucene.search;

import java.io.File;
import java.io.IOException;

import org.apache.lucene.index.Term;
import org.apache.lucene.search.Hits;
import org.apache.lucene.search.IndexSearcher;
import org.apache.lucene.search.Sort;
import org.apache.lucene.search.SortField;
import org.apache.lucene.search.TermQuery;
import org.apache.lucene.store.Directory;
import org.apache.lucene.store.FSDirectory;

public class Searcher {

    public static void main(String[] args) throws Exception {
        File indexDir = new File("C:\\target\\index\\book");
        String q = "�?/span>";
        if (!indexDir.exists() || !indexDir.isDirectory()) {
            throw new IOException();
        }
        search(indexDir, q);
    }

    public static void search(File indexDir, String q) throws Exception {

        Directory fsDir = FSDirectory.getDirectory(indexDir);
        IndexSearcher searcher = new IndexSearcher(fsDir);

        //Sort sort = new Sort(new SortField("isbn", false));
        Sort sort = new Sort(new SortField[]{new SortField("isbn", false), new SortField("pbl_dt", true)});
        Term term = new Term("content", q.toLowerCase());
        TermQuery termQuery = new TermQuery(term);
        Hits hits = searcher.search(termQuery, sort);
        System.out.println("共有" + searcher.maxDoc() + "条烦引，命中" + hits.length() + "�?/span>");
        for (int i = 0; i < hits.length(); i++) {
            int DocId = hits.id(i);
            String DocName  = hits.doc(i).get("name");
            String DocIsbn  = hits.doc(i).get("isbn");
            String DocPblDt = hits.doc(i).get("pbl_dt");
            System.out.println(DocId + ":" + DocName + "  ISBN:" + DocIsbn + "  PBLDT:" + DocPblDt);
        }
    }
}

淘声依旧 2008-10-29 09:54 发表评论

淘声依旧 — Wed, 29 Oct 2008 01:43:00 GMT
1, 几种span的querySpanTermQuery�Q�检索效果完全同TermQuery�Q�但内部会记录一些位�|�信息，供SpanQuery的其它API使用�Q�是其它属于SpanQuery的Query的基��?
SpanFirstQuery�Q�查找方式�ؓ从Field的内容�v始位�|�开始，在一个固定的宽度内查找所指定的词条�?
SpanNearQuery�Q�功能类似PharaseQuery。SpanNearQuery查找所匚w��的不一定是短语�Q�还有可能是另一个SpanQuery的查询结果作为整体考虑�Q�进行嵌套查询�?
SpanOrQuery�Q�把所有SpanQuery查询�l�果�l�合��h��Q�作为检索结果�?
SpanNotQuery�Q�从�W�一个SpanQuery查询�l�果中，��L��W�二个SpanQuery查询�l�果�Q�作为检索结果�?

2, 多条件烦引关�p?

BooleanClause用于表示布尔查询子句关系的类�Q�包括：BooleanClause.Occur.MUST�Q�BooleanClause.Occur.MUST_NOT�Q�BooleanClause.Occur.SHOULD�? 有以�?�U�组合：
1�Q�MUST和MUST�Q�取得连个查询子句的交集�?
2�Q�MUST和MUST_NOT�Q�表�C�查询结果中不能包含MUST_NOT所对应得查询子句的��索结果�?
3�Q�MUST_NOT和MUST_NOT�Q�无意义�Q�检索无�l�果�?
4�Q�SHOULD与MUST、SHOULD与MUST_NOT�Q�SHOULD与MUST�q�用�Ӟ��无意义，�l�果为MUST子句的检索结果。与MUST_NOT�q�用�Ӟ��功能同MUST�?
5�Q�SHOULD与SHOULD�Q�表�C?#8220;�?#8221;关系�Q�最�l�检索结果�ؓ所有检索子句的�q��?

淘声依旧 2008-10-29 09:43 发表评论

[转]lucene学习�W�记�?各种query

淘声依旧 — Wed, 29 Oct 2008 01:42:00 GMT
1, 有时对于一个Document来说�Q�有一些Field会被频繁地操作，而另一些Field则不会。这时可以将频繁操作的Field和其他Field分开�? 放，而在搜烦时同时检索这两部分Field而提取出一个完整的Document�?�q�要求两个烦引包含的Document的数量必��ȝ��同�?
在创建烦引的时候，可以同时创徏多个IndexWriter�Q�将一个Document�Ҏ(gu��)��需要拆分成多个包含部分Field的Document�Q��ƈ��这些Document分别��d��C��同的索引�?
而在搜烦�Ӟ��则必��d��助ParallelReader�c�L��整合�?
Directory dir1=FSDirectory.getDirectory(new File(INDEX_DIR1),false);
Directory dir2=FSDirectory.getDirectory(new File(INDEX_DIR2),false);
ParallelReader preader=new ParallelReader();
preader.add(IndexReader.open(dir1));
preader.add(IndexReader.open(dir2));
IndexSearcher searcher=new IndexSearcher(preader);
之后的操作和一般的搜烦相同�?

2, Query的子�c? 下面的几个搜索在各种不同要求的场�?都会用到. 需要大家仔�l�研�?

Query query1 = new TermQuery(new Term(FieldValue, "name1")); // 词语搜烦
Query query2 = new WildcardQuery(new Term(FieldName, "name*")); // 通配�W?
Query query3 = new PrefixQuery(new Term(FieldName, "name1")); // 字段搜烦 Field:Keyword�Q�自动在�l�尾��d�� *
Query query4 = new RangeQuery(new Term(FieldNumber, NumberTools.LongToString(11L)), new Term(FieldNumber, NumberTools.LongToString(13L)), true); // 范围搜烦
Query query5 = new FilteredQuery(query, filter); // 带过滤条件的搜烦
Query query6 =new MatchAllDocsQuery(... // 用来匚w��所有文�?
Query query7 = new FuzzyQuery (...模糊搜烦
Query query8 = new RegexQuery (.. 正则搜烦
Query query9 = new SpanRegexQuery(...)�?同上, 正则表达式的查询�Q?
Query query9 = new SpanQuery 的子�c�d��套其他SpanQuery 增加�?rewrite�Ҏ(gu��)��
Query query10 =new DisjunctionMaxQuery () ..�c�，提供了针�Ҏ(gu��)��个短语的最大score。这一点对多字�D늚�搜烦非常有用
Query query11 = new ConstantScoreQuery �c�d��包装了一�?filter produces a score
equal to the query boost for every matching document.

BooleanQuery query12= new BooleanQuery();
booleanQuery.add(termQuery 1, BooleanClause.Occur.SHOULD);
booleanQuery.add(termQuery 2, BooleanClause.Occur.SHOULD);
//�q�个是�ؓ了联合多个查询而做的Query�c? BooleanQuery增加了最��的匚w��短语。见�Q�BooleanQuery.setMinimumNumberShouldMatch().

PhraseQuery
你可能对中日关系比较感兴��，��x��?#8216;�?#8217;�?#8216;�?#8217;挨得比较�q�（5个字的距��d��Q�的文章�Q�超�q�这个距��ȝ��不予考虑�Q�你可以�Q?

PhraseQuery query 13= new PhraseQuery();
query.setSlop(5);
query.add(new Term("content ", “�?#8221;));
query.add(new Term(“content”, “�?#8221;));

PhraseQuery对于短语的顺序是不管�?�q�点在查询时除了提高命中率外,也会�Ҏ(gu��)��能产生很大的媄�? 利用SpanNearQuery可以对短语的��序�q�行控制,提高性能

BooleanQuery query12= new SpanNearQuery 可以对短语的��序�q�行控制,提高性能

3, 索引文本文�g
如果你想把纯文本文�g索引��h��Q�而不惌��己将它们��d��字符串创建field�Q�你可以用下面的代码创徏field�Q?

Field field = new Field("content", new FileReader(file));

�q�里的file��是该文本文件。该构造函数实际上是读��L��件内容，�q�对其进行烦引，但不存储

4, 如何删除索引
lucene提供了两�U�从索引中删除document的方法，一�U�是

void deleteDocument(int docNum)

�q�种�Ҏ(gu��)��是根据document在烦引中的编��h��删除�Q�每个document加进索引后都会有个唯一�~�号�Q�所以根据编号删除是一�U�精��删除，但是�q�个�~�号是烦引的内部�l�构�Q�一般我们不会知道某个文件的�~�号到底是几�Q�所以用处不大。另一�U�是

void deleteDocuments(Term term)

�q�种�Ҏ(gu��)��实际上是首先�Ҏ(gu��)��参数term执行一个搜索操作，然后把搜索到的结果批量删除了。我们可以通过�q�个�Ҏ(gu��)��提供一个严格的查询条�g�Q�达到删除指定document的目的�?
下面�l�出一个例子：

Directory dir = FSDirectory.getDirectory(PATH, false);
IndexReader reader = IndexReader.open(dir);
Term term = new Term(field, key);
reader.deleteDocuments(term);
reader.close();

5, 如何更新索引
lucene�q�没有提供专门的索引更新�Ҏ(gu��)��Q�我们需要先��相应的document删除�Q�然后再��新的document加入索引。例如：

Directory dir = FSDirectory.getDirectory(PATH, false);
IndexReader reader = IndexReader.open(dir);
Term term = new Term(“title”, “lucene introduction”);
reader.deleteDocuments(term);
reader.close();

IndexWriter writer = new IndexWriter(dir, new StandardAnalyzer(), true);
Document doc = new Document();
doc.add(new Field("title", "lucene introduction", Field.Store.YES, Field.Index.TOKENIZED));
doc.add(new Field("content", "lucene is funny", Field.Store.YES, Field.Index.TOKENIZED));
writer.addDocument(doc);
writer.optimize();
writer.close();

但是�?.9RC1中说�?
新增�c�： org.apache.lucene.index.IndexModifier �Q�它合�ƈ�?IndexWriter �? IndexReader�Q�好处是我们可以增加和删除文档的时候不同担�?synchronisation/locking 的问题了�?

6, filer�c?使用 Filter �Ҏ(gu��)��索结果进行过滤，可以获得更小范围内更�_��的结果�?有�h�? 注意它执行的是预处理�Q�而不是对查询�l�果�q�行�q��o�Q�所以��用filter的代��h��很大的，它可能会使一�ơ查询耗时提高一癑ր?

ISOLatin1AccentFilter ,�?ISO Latin 1 字符集中的unaccented�c�d��W�替�?accented �c�d��W?
DateFilter 日期�q��o�?
RangeFileter ,�?DateFilter 更加通用�Q�实�?
LengthFilter �c? 已经�?contrib 攑ֈ��?core 代码里。从 stream 中去掉太长和太短的单�? StopFilter �c? 增加了对处理stop words 的忽略大��写处理

7,本条是一个��用过滤的说明:

�q��o

使用 Filter �Ҏ(gu��)��索结果进行过滤，可以获得更小范围内更�_��的结果�?

举个例子�Q�我们搜索上架时间在 2005-10-1 �?2005-10-30 之间的商品�?
对于日期旉��Q�我们需要�{换一下才能添加到索引库，同时�q�必��L��索引字段�?
// index
document.Add(FieldDate, DateField.DateToString(date), Field.Store.YES, Field.Index.UN_TOKENIZED);

//...

// search
Filter filter = new DateFilter(FieldDate, DateTime.Parse("2005-10-1"), DateTime.Parse("2005-10-30"));
Hits hits = searcher.Search(query, filter);

除了日期旉��Q�还可以使用整数。比如搜索�h(hu��n)格在 100 ~ 200 之间的商品�?
Lucene.Net NumberTools 对于数字�q�行了补位处理，如果需要��用��Q�Ҏ(gu��)��可以自己参考源码进行�?
// index
document.Add(new Field(FieldNumber, NumberTools.LongToString((long)price), Field.Store.YES, Field.Index.UN_TOKENIZED));

//...

// search
Filter filter = new RangeFilter(FieldNumber, NumberTools.LongToString(100L), NumberTools.LongToString(200L), true, true);
Hits hits = searcher.Search(query, filter);

使用 Query 作�ؓ�q��o条�g�?
QueryFilter filter = new QueryFilter(QueryParser.Parse("name2", FieldValue, analyzer));

我们�q�可以��?FilteredQuery �q�行多条件过滤�?

Filter filter = new DateFilter(FieldDate, DateTime.Parse("2005-10-10"), DateTime.Parse("2005-10-15"));
Filter filter2 = new RangeFilter(FieldNumber, NumberTools.LongToString(11L), NumberTools.LongToString(13L), true, true);

Query query = QueryParser.Parse("name*", FieldName, analyzer);
query = new FilteredQuery(query, filter);
query = new FilteredQuery(query, filter2);

IndexSearcher searcher = new IndexSearcher(reader);
Hits hits = searcher.Search(query);

8, Sort
有时你想要一个排好序的结果集�Q�就像SQL语句�?#8220;order by”�Q�lucene能做刎ͼ�通过Sort�?
Sort sort = new Sort(“time”); //相当于SQL�?#8220;order by time”
Sort sort = new Sort(“time”, true); // 相当于SQL�?#8220;order by time desc”
下面是一个完整的例子�Q?

Directory dir = FSDirectory.getDirectory(PATH, false);
IndexSearcher is = new IndexSearcher(dir);
QueryParser parser = new QueryParser("content", new StandardAnalyzer());
Query query = parser.parse("title:lucene content:lucene";
RangeFilter filter = new RangeFilter("time", "20060101", "20060230", true, true);
Sort sort = new Sort(“time”);
Hits hits = is.search(query, filter, sort);
for (int i = 0; i < hits.length(); i++)
{
Document doc = hits.doc(i);
System.out.println(doc.get("title");
}
is.close();

9, 性能优化
一直到�q�里�Q�我们还是在讨论怎么样��lucene跑�v来，完成指定��d��。利用前面说的也��实能完成大部分功能。但是测试表明lucene的性能�q�不是很好，在大数据量大�q�发的条件下甚至会有半分钟返回的情况。另外大数据量的数据初始化徏立烦引也是一个十分耗时的过�E�。那么如何提高lucene的性能呢？下面从优化创建烦引性能和优化搜索性能两方面介�l��?

9.1 优化创徏索引性能
�q�方面的优化途径比较有限�Q�IndexWriter提供了一些接口可以控制徏立烦引的操作�Q�另外我们可以先��烦引写入RAMDirectory�Q�再扚w��? 入FSDirectory�Q�不��怎样�Q�目的都是尽量少的文件IO�Q�因为创建烦引的最大瓶颈在于磁盘I(y��)O。另外选择一个较好的分析器也能提高一些性能�?

9.1.1 通过讄��IndexWriter的参��C��化烦引徏�?
setMaxBufferedDocs(int maxBufferedDocs)
控制写入一个新的segment前内存中保存的document的数目，讄��较大的数目可以加快徏索引速度�Q�默认�ؓ10�?
setMaxMergeDocs(int maxMergeDocs)
控制一个segment中可以保存的最大document数目�Q��D��?y��u)��有利于�q�加索引的速度�Q�默认Integer.MAX_VALUE�Q�无需修改�?
setMergeFactor(int mergeFactor)
控制多个segment合�ƈ的频率，��D��大时建立索引速度较快�Q�默认是10�Q�可以在建立索引时设�|��ؓ100�?

9.1.2 通过RAMDirectory�~�写提高性能
我们可以先把索引写入RAMDirectory�Q�达��C��定数量时再批量写�q�FSDirectory�Q�减��磁盘I(y��)O�ơ数�?

FSDirectory fsDir = FSDirectory.getDirectory("/data/index", true);
RAMDirectory ramDir = new RAMDirectory();
IndexWriter fsWriter = new IndexWriter(fsDir, new StandardAnalyzer(), true);
IndexWriter ramWriter = new IndexWriter(ramDir, new StandardAnalyzer(), true);
while (there are documents to index)
{
... create Document ...
ramWriter.addDocument(doc);
if (condition for flushing memory to disk has been met)
{
fsWriter.addIndexes(new Directory[] { ramDir });
ramWriter.close();
ramWriter = new IndexWriter(ramDir, new StandardAnalyzer(), true);
}
}

9.1.3 选择较好的分析器
�q�个优化主要是对��盘�I�间的优化，可以��烦引文件减��将�q�一半，相同��试数据下由600M减少�?80M。但是对旉��q�没有什么帮助，甚至会需要更长时 ��_��因�ؓ较好的分析器需要匹配词库，会消耗更多cpu�Q�测试数据用StandardAnalyzer耗时133分钟�Q�用MMAnalyzer耗时150�? 钟�?

9.2 优化搜烦性能
虽然建立索引的操作非常耗时�Q�但是那毕竟只在最初创建时才需要，�q�x��只是��量的维护操作，更何况这些可以放��C��个后台进�E�处理，�q�不影响用户搜烦。我们创建烦引的目的��是�l�用��h��索，所以搜索的性能才是我们最兛_��的。下面就来探讨一下如何提高搜索性能�?

9.2.1 ��烦引放入内�?
�q�是一个最直观的想法，因�ؓ内存比磁盘快很多。Lucene提供了RAMDirectory可以在内存中容纳索引�Q?

Directory fsDir = FSDirectory.getDirectory(“/data/index/”, false);
Directory ramDir = new RAMDirectory(fsDir);
Searcher searcher = new IndexSearcher(ramDir);

但是实践证明RAMDirectory和FSDirectory速度差不多，当数据量很小时两者都非常快，当数据量较大�Ӟ��索引文�g400M�Q�RAMDirectory甚至比FSDirectory�q�要慢一点，�q�确实让人出乎意料�?
而且lucene的搜索非常耗内存，即�ɞ�?00M的烦引文件蝲入内存，在运行一�D�|��间后都会out of memory�Q�所以个��入内存的作用�q�不大�?

9.2.2 优化旉��范围限制
既然载入内存�q�不能提高效率，一定有其它瓉��Q�经�q�测试发现最大的瓉��居然是时间范围限�Ӟ��那么我们可以怎样使时间范围限制的代�h(hu��n)最��呢�Q?
当需要搜索指定时间范围内的结果时�Q�可以：
1、用RangeQuery�Q�设�|�范��_��但是RangeQuery的实现实际上是将旉��范围内的旉��点展开�Q�组成一个个BooleanClause加入�? BooleanQuery中查询，因此旉��范围不可能设�|�太大，�l�测试，范围��过一个月��׃��抛BooleanQuery.TooManyClauses�Q�可以通过讄�� BooleanQuery.setMaxClauseCount(int maxClauseCount)扩大�Q�但是扩大也是有限的�Q��ƈ且随着maxClauseCount扩大�Q�占用内存也扩大
2、用RangeFilter代替RangeQuery�Q�经��试速度不会比RangeQuery慢，但是仍然有性能瓉��Q�查询的90%以上旉��耗费�? RangeFilter�Q�研�I�其源码发现RangeFilter实际上是首先遍历所有烦引，生成一个BitSet�Q�标记每个document�Q�在旉��范围内的标记为true�Q�不在的标记为false�Q�然后将�l�果传递给Searcher查找�Q�这是十分耗时的�?
3、进一步提高性能�Q�这个又有两个思�\�Q?
a、缓存Filter�l�果。既然RangeFilter的执行是在搜索之前，那么它的输入都是一定的�Q�就是IndexReader�Q��? IndexReader是由Directory军_��的，所以可以认为RangeFilter的结果是��p��围的上下限决定的�Q�也��是由具体的 RangeFilter对象军_��Q�所以我们只要以RangeFilter对象为键�Q�将filter�l�果BitSet�~�存��h��卛_��。lucene API已经提供了一个CachingWrapperFilter�c�d��装了Filter及其�l�果�Q�所以具体实施�v来我们可以cache CachingWrapperFilter对象�Q�需要注意的是，不要被CachingWrapperFilter的名字及其说明误 ��|��CachingWrapperFilter看�v来是有缓存功能，但的�~�存是针对同一个filter的，也就是在你用同一个filter�q��o不同 IndexReader�Ӟ��它可以帮你缓存不同IndexReader的结果，而我们的需求恰恰相反，我们是用不同filter�q��o同一�? IndexReader�Q�所以只能把它作��Z��个封装类�?
b、降低时间精度。研�I�Filter的工作原理可以看出，它每�ơ工作都是遍历整个烦引的�Q�所以时间粒度越大，�Ҏ(gu��)��快�Q�搜索时间越短，在不影响功能的情况下�Q�时间精度越低越好，有时甚至牺牲一点精度也值得�Q�当然最好的情况是根本不作时间限制�?
下面针对上面的两个思�\演示一下优化结果（都采�?00�U�程随机关键词随��x��间范��_��Q?
�W�一�l�，旉��_�ֺ�为秒�Q?
方式直接用RangeFilter 使用cache 不用filter
�q�_��每个�U�程耗时 10s 1s 300ms

�W�二�l�，旉��_�ֺ�为天
方式直接用RangeFilter 使用cache 不用filter
�q�_��每个�U�程耗时 900ms 360ms 300ms

�׃��上数据可以得出结论：
1�?��量降低旉��_�ֺ��Q�将�_�ֺ��q��换成天带来的性能提高甚至比��用cache�q�好�Q�最好不使用filter�?
2�?在不能降低时间精度的情况下，使用cache能带�?0倍左右的性能提高�?

9.2.3 使用更好的分析器
�q�个跟创建烦引优化道理差不多�Q�烦引文件小了搜索自然会加快。当然这个提高也是有限的。较好的分析器相对于最差的分析器对性能的提升在20%以下�?

10 一些经�?

10.1关键词区分大��写
or AND TO�{�关键词是区分大��写的，lucene只认大写的，��写的当做普通单词�?/strong>

10.2 ��d��互斥�?
同一时刻只能有一个对索引的写操作�Q�在写的同时可以�q�行搜烦

10.3 文�g�?
在写索引的过�E�中��退出将在tmp目录留下一个lock文�g�Q��以后的写操作无法�q�行�Q�可以将其手工删�?

10.4 旉��格式
lucene只支持一�U�时间格式yyMMddHHmmss�Q�所以你传一个yy-MM-dd HH:mm:ss的时间给lucene它是不会当作旉��来处理的

10.5 讄��boost
有些时候在搜烦时某个字�D늚�权重需要大一些，例如你可能认为标题中出现关键词的文章比正文中出现关键词的文章更有价��|��你可以把标题的boost讄��的更大，那么搜烦�l�果会优先显�C�标题中出现关键词的文章�Q�没有��用排序的前题下）。��用方法：
Field. setBoost(float boost);默认值是1.0�Q�也��是说要增加权重的需要设�|�得�?大�?

上面�q�篇关于性能的讲解是很深�? 请学�?

淘声依旧 2008-10-29 09:42 发表评论

[转]lucene学习�W�记�? 1.9版本升��的问�?

淘声依旧 — Wed, 29 Oct 2008 01:41:00 GMT
Lucene 1.9 改进�Ҏ(gu��)��列�?.9 RC1
注：lucene2.0发布版本�q�不�?00%的和1.4.3版兼宏V��也��是说在你用2.0版本的Lucene开发包替换原来�?.4.3版本�Ӟ��应该让你的应用程序首先和1.9的兼宏V�?
使用前提�Q?
1. �~�译和��用Lucene需�?Java1.4 或以上版本�?
Lucene 1.9 在运行时的变化：
1. 模糊搜烦 FuzzyQuery 不再抛出 TooManyClauses 异常。当 FuzzyQuery 扩展多于 BooleanQuery.maxClauseCount �?�Q�只有最相关的term会被重新写入query,因此避免了异常的抛出�? (Christoph)
2. 把系�l�属�?"org.apache.lucene.lockdir" 改�ؓ "org.apache.lucene.lockDir"�?Bernhard)

1.9 RC1
注：lucene2.0发布版本�q�不�?00%的和1.4.3版兼宏V��也��是说在你用2.0版本的Lucene开发包替换原来�?.4.3版本�Ӟ��应该让你的应用程序首先和1.9的兼宏V�?
使用前提�Q?
1. �~�译和��用Lucene需�?Java1.4 或以上版本�?
Lucene 1.9 在运行时的变化：
1. 模糊搜烦 FuzzyQuery 不再抛出 TooManyClauses 异常。当 FuzzyQuery 扩展多于 BooleanQuery.maxClauseCount �?�Q�只有最相关的term会被重新写入query,因此避免了异常的抛出�? (Christoph)
2. 把系�l�属�?"org.apache.lucene.lockdir" 改�ؓ "org.apache.lucene.lockDir"�?Bernhard)
3. RangeQueries �?FuzzyQueries 默认被�{换成��写�?(as it has been the case for PrefixQueries and WildcardQueries before).使用 setLowercaseExpandedTerms(false) 来禁止大��写自动转换的行为；同样也媄�?PrefixQueries �? WildcardQueries�?Daniel Naber)
4. 在��?MultiSearcher 的时候文档频率也可以正确计算�Q�全局性的计算各个 subsearchers �?indices 中。以前计��的时候只�?locally 的，每个 index 的计��是分开的，�q�样引发的一个问题是�Q�在多个indices中rank 是不相等的�?
(Chuck Williams, Wolf Siberski via Otis, bug #31841)
5. 在打开 IndexWriter 使用 create=true 参数�Q�Lucene 现在只是删除index目录中属于Lucene自己的文件�? 判断文�g名后�~�的方�?)。原来是删除整个目录中的所有文件�?Daniel Naber and Bernhard Messer, bug #34695)
6. IndexReader 的版�?�Q�可以通过 getCurrentVersion() �?getVersion() �q�回。以前如果是新的indexes 那么�q�回的是0 。现在则用系�l�的毫秒数来初始化�?(Bernhard Messer via Daniel Naber)
7. 一些默认的初始化��g��再允讔R��过 system properties 来设�|�。相反在 IndexWriter 中新增了相关�?set/get �Ҏ(gu��)��来设�|�相兛_��性。主要包括以下属性：
�?IndexWriter �?getter/setter �Ҏ(gu��)��?
org.apache.lucene.writeLockTimeout, org.apache.lucene.commitLockTimeout,
org.apache.lucene.minMergeDocs, org.apache.lucene.maxMergeDocs,
org.apache.lucene.maxFieldLength, org.apache.lucene.termIndexInterval,
org.apache.lucene.mergeFactor,
�q�有 BooleanQuery �?getter/setter �Ҏ(gu��)��:
org.apache.lucene.maxClauseCount
�q�有 FSDirectory �?getter/setter �Ҏ(gu��)��Q?
disableLuceneLocks
(Daniel Naber)
8. 修改�?FieldCacheImpl �Ҏ(gu��)��使用用户提供�?IntParser �?FloatParser,来替代��?Integer �?Float 的相��x��法�?
(Yonik Seeley via Otis Gospodnetic)
9. 高��搜烦�q�回�?TopDocs �?TopFieldDocs 不再规范scores�?
(Luc Vanlerberghe via Yonik Seeley, LUCENE-469)
1.9 的新�Ҏ(gu��)��：
1. 增加了对压羃字段存储的支持�?patch #31149)
(Bernhard Messer via Christoph)
2. 增加了对压羃字段存储的支持�?patch #29370)
(Bernhard Messer via Christoph)
3. �?term vectors 中增加了位置和偏�U�M��息�?Grant Ingersoll & Christoph)
4. 增加了一个新�?DateTools 。允许用��h��式化日期��C��U�更可读的格式，以便于更好的适应索引。DateTools 不像 DateFields �c�，它允许日期指定到1970�q�以前，但必��M��用指定的日期格式。这��P��在RangeQuerys中��用就更加有效率了�? (Daniel Naber)
5. QueryParser 现在可以正确的和Analyzers 一起工作了�Q�即可以在一个位�|�返回多�?Token �?比如�Q�查询： “+fast + car”如果 Analyzer 在同一位置�q�回 car �?automobile �Q�那么上面的查询��被解析成：”+fast +(car automobile)”�?(Pierrick Brihaye, Daniel Naber)
6. 允许unbuffered的目录实现。（e.g.,using mmap�Q��?
InputStream 被新�c?IndexInput 替换�Q?BufferedIndexInput �?OutputStream 则被 IndexOutput �?BufferedIndexOutput�?InputStream �?OutputStream 已经被废弃了。FSDirectory 现在是一个子�c�M��?cutting)
7. 增加了原�?Directory �?TermDocs 的实玎ͼ�可以工作�?GCJ 下。GCJ的版本需�?3.4.0 以上。可以��?ant gcj 来运行例子程序�?cutting)
8. 增加�?MmapDirectory �c�，它��?nio to mmap 输入文�g。现在MmapDirectory 比FSDirectory 要慢些。但他对每个查询term 使用更少的内存�?cutting & Paul Elschot)
9. 增加 javadocs-internal �?build.xml – bug #30360
10. 增加�?RangeFileter ,�?DateFilter 更加通用�Q�实用�?
(Chris M Hostetter via Erik)
11. 增加�?NumberTools �Q�一个用来烦引数字字�D늚�工具�c�R�? (adapted from code contributed by Matt Quail; committed by Erik)
12. 增加�?public static IndexReader.main(String[] args) �Ҏ(gu��)��?
IndexReader 现在可以直接在命令行方式下��用，用来列出或者从现存的烦引中抽取单独的文件出来�?
(adapted from code contributed by Garrett Rooney; committed by Bernhard)
13. 增加 IndexWriter.setTermIndexInterval() �Ҏ(gu��)��? (Doug Cutting)
14. 增加 LucenePackage ,�q�些静态的 get() �Ҏ(gu��)��q�回 java.util.Package。调用者可以用它来获得 Lucene jar 中的版本信息�?
(Doug Cutting via Otis)
15. 增加 Hits.iterator() �Ҏ(gu��)��和相应的 HitIterator �?Hit 对象。他提供了对 Hits对象标准�?java.util.Iterator 叠代操作�?
每个iterator's next() �Ҏ(gu��)��q�回一�?Hit 对象�? (Jeremy Rayner via Erik)
16. 增加 ParallelReader�Q�这个一�U�IndexReader 他合�q�多个单独的索引��C��个单独的虚拟索引上�?Doug Cutting)
17. 增加�?FieldCache �?IntParser �Q?FloatParser 接口, �q�样��M��格式的字�D�可以被以int 和float的�Ş式缓存�?
(Doug Cutting)
18. 新增�c�： org.apache.lucene.index.IndexModifier �Q�它合�ƈ�?IndexWriter �? IndexReader�Q�好处是我们可以增加和删除文档的时候不同担�?synchronisation/locking 的问题了�?(Daniel Naber)
19. Lucene 现在可以被用在一个没有签名的applet中了�Q�Lucene’s ��d��pȝ��属性不会抛�?SecurityException 异常�?
(Jon Schuster via Daniel Naber, bug #34359)
20. 增加了新�c?MatchAllDocsQuery 用来匚w��所有文档�?
(John Wang via Daniel Naber, bug #34946)
21. 当烦引太多的字段�Ӟ��Z��消减索引大小和内存消耗，提供了忽略规范化字段的功能�?
�? Field.setOmitNorms() (Yonik Seeley, LUCENE-448)
22. 增加�?contrib/highlighter �?NullFragmenter , �q�对全文本加亮很有用�?
(Erik Hatcher)
23. 增加了正则表辑ּ�的查询： RegexQuery �?SpanRegexQuery�?
(Erik Hatcher)
24. 增加 ConstantScoreQuery �c�，它包装了一�?filter produces a score
equal to the query boost for every matching document.
(Yonik Seeley, LUCENE-383)
25. 增加�?ConstantScoreRangeQuery �c�，为某个区间的每个文档提供一个不变的 score。这个类比普通的 RangeQuery �cȝ��好处是它�q�不展开�?BooleanQuery �Q�因此也不存在区间最大term上限�?(Yonik Seeley, LUCENE-383)
26. 为BooleanQuery增加了最��的匚w��短语。见�Q�BooleanQuery.setMinimumNumberShouldMatch().
(Paul Elschot, Chris Hostetter via Yonik Seeley, LUCENE-395)
27. 增加�?DisjunctionMaxQuery �c�，提供了针�Ҏ(gu��)��个短语的最大score。这一点对多字�D늚�搜烦非常有用�?
(Luc Vanlerberghe via Yonik Seeley, LUCENE-323)
28. 新增�c�：ISOLatin1AccentFilter ,�?ISO Latin 1 字符集中的unaccented�c�d��W�替�?accented �c�d��W��? (Sven Duzont via Erik Hatcher)
29. 新增�c�：KeywordAnalyzer�?Tokenizes" 整个��作��Z��个单独的token。这个类对于邮政�~�码�Q�序列号�Q�和产品名称�{�比较有用�?
(Erik Hatcher)
30. �?LengthFilter �c�M�� contrib 攑ֈ��?core 代码里。从 stream 中去掉太长和太短的单词�? (David Spencer via Otis and Daniel)
31. 增加�?getPositionIncrementGap �Ҏ(gu��)��?Analyzer 中。这��L��戯��定义�?analyzer 可以在相同字�D�名的实例之间增加间�?gaps�Q�用来防�?phrase �?span 查询��出边界。默认的 gap �?0 �?(Erik Hatcher, with advice from Yonik)
32. StopFilter 增加了对处理stop words 的忽略大��写处理�? (Grant Ingersoll via Yonik, LUCENE-248)
33. 增加�?TopDocCollector �?TopFieldDocCollector。用来简化实现hit 集合针对 top-scoring �?top-sorting hits的处理�?
API 的改变：
1. 几个�Ҏ(gu��)��和字�D�已�l�被废弃。在API 文档中包含了��替换的内宏V��在�q�些��中，�q�些不徏议��用的�Ҏ(gu��)��和字�D�将会在Lucene2.0中被删除�?
(Daniel Naber)
2. Russian �?German �?analyzers 被移��C�� contrib/analyzers �?
同样 WordlistLoader �c�M��被放��C�� org.apache.lucene.analysis.WordlistLoader �? (Daniel Naber)
3. API 包含抛出 IOException 异常的声明，但是实际上不会抛出�?These declarations have been removed. If
your code tries to catch these exceptions you might need to remove
those catch clauses to avoid compile errors.(Daniel Naber)
4. 为BooleanClause �cȝ��enum 标准参数增加序列化的参数�c�R�? (Christoph)
5. �?SpanQuery 的子�c�d��套其他SpanQuery 增加�?rewrite�Ҏ(gu��)��?
Lucene 的源代码��理器也从cvs 换到了svn�Q? http://svn.apache.org/repos/asf/lucene/java/trunk
参考资料：http://blog.csdn.net/accesine960/archive/2006/02/28/612622.aspx
原文地址�Q?a target="_blank">http://svn.apache.org/viewcvs.cgi/*checkout*/lucene/java/branches/lucene_1_9/CHANGES.txt?rev=379190

淘声依旧 2008-10-29 09:41 发表评论

淘声依旧 — Wed, 29 Oct 2008 01:16:00 GMT
�q�个东西�?006�q�初,我就开始在��目中��?我对它也有了一些了�? 但因��Z��要开发还是小兵们在做. 所以仅仅了解了一些皮�? 下面我将以知识点的�Ş�? 列出�? 以笔记的形式�q�蝲. 也方便大家一起学�? 每一个点, 我都会写一个知识点.

1, 2005�q�的时�? 听说了lucene. 是一个开源的搜烦引擎开发包. 而不是一个搜索引�?请切�?
2, 如果开始学习它, ��需要至��知�?它所包含的包. 目前lucene已经��C��2.2版本. 当然你需要时��d��注他的最新版�? 目前�? lucene-core-2.2.0.jar . 下蝲可以到apache的网站上下蝲. �q�一个就够了.不用下别�?
3, 下面问题会接�t�而至, 我挨着�?你挨着看即�?
分词. �W�一个要涉及的问�? 分词��是��一句话中的关键词汇分离出来, 然后才可以徏立烦�? 例如中华人民共和�?--> 中华, 中华人民华�h,人民, 共和�?�{? lucene�~�省带了一个标准分词的�c? StandardAnalyzer �q�个按字来分�? 从网上发��C��很多�E�序员写的开源的分词的类. 当然都是�l�承了lucene的org.apache.lucene.analysis.Analyze�c? 以实现更好更快的分词效果. 可以搜烦获取更多, 一般分词的�c?都提供了可检��分词效果的�Ҏ(gu��)��. 输入一个长�? 然后执行,看看分词效果和执行时�?

4, ThesaurusAnalyzer是一个哥们开发的,�|�上有源码可以下�? 从这个源码里面对分词可以有更深入的了�? 包括那些是词�?那些不是词汇. 都在文本文�g里面以行分割开�? 由此可以知道: 分词是需要词库的. 因�ؓ词库可以不断的扩�? .但每�ơ构造分词对象时,是徏立在当前词库基础上的. 如果词库动态增加了新的词汇, 需要重新构建分词对�? 当然, 也可以读取数据库.

5, 上面的分�? 也仅仅是分词! �|�上有�h提出的问题是: 索引�?加入�?东北大学". "北大" . 要搜�?北大 , 昄��我们没有扑ֈ�东北大学的意�? 但最后还是找��C��. 因�ؓ东北大学四个字里面有北大两个�? 分词时这个词被确认是个词, ��加入了索引. �q�种情况, 涉及到汉语语义的问题 .暂时不好解决. 所以不�?

选择较好的分析器
�q�个优化主要是对��盘�I�间的优化，可以��烦引文件减��将�q�一半，相同��试数据下由600M减少�?80M。但是对旉��q�没有什么帮助，甚至会需要更长时 ��_��因�ؓ较好的分析器需要匹配词库，会消耗更多cpu�Q�测试数据用StandardAnalyzer耗时133分钟�Q�用MMAnalyzer耗时150�? 钟�?

6, 分词的缺�? ��׃��乎同义词. ��Z��减少用户搜烦的次�? 增加搜烦效果. 如果用户�?"北京饭店" 能不能把" 首都饭店"也列出来�? �q�个分词器无能�ؓ�? 我也考虑到这个问�? 在北京托��四公司的TRS的搜索��品文档中人家也考虑��C��q�个问题. ��׃��乎如果搜�?锐器, �pȝ��会自动把匕首,��刀�{�词汇一�q�加入搜索结�? 所以这个问�?,��只能是在分词之�?我们再加一�?同义词返回模�? �q�个思�\很不�? 也比较简�? 很容易实�? 关键是词库的建立. �q�个��p��到这�?

7, 说到�q�里,你可能想要做个例子来实践一�? 做个例子很容�? �|�上很多. 我只做简单的叙述: lucene是用目录或者内存来存储数据�? 可以讑֮�. 但是实践证明RAMDirectory和FSDirectory速度差不多，当数据量很小时两者都非常快，当数据量较大�Ӟ��索引文�g 400M�Q�RAMDirectory甚至比FSDirectory�q�要慢一点，�q�确实让人出乎意料�?
而且lucene的搜索非常耗内存，即�ɞ�?00M的烦引文件蝲入内存，在运行一�D�|��间后都会out of memory�Q�所以个��入内存的作用�q�不大�?
我们用目�?
如下:
//构徏一�?IndexWriter 用来写如索引
File indexDir = new File(
"E:""javasource""LuceneTest""index");

IndexWriter indexWriter = new IndexWriter(indexDir,
new ThesaurusAnalyzer(), false);
Document doc = Document(new Article("name"+i, "北京老张"));
indexWriter.addDocument(doc);
indexWrite.close();

�׃��可以看出, lucene��在�q�个目录下进行操�? 上面代码中的你不要抄袭当例子, 因�ؓ�q�有一个Article�c�d��Document�Ҏ(gu��)��.里面也有一些东�? 现在仅仅先理解上面的意思即�? 操作�?你可能不知道他会在目录里�q�什�?

8, 目录下的东西 . 如果��试成功, 目录下有三个文�g.
segments.gen segments_a08, �q�有一个类�?_uw.cfs名字的东�? 当然,不一定都一�? 但肯定是�q�三�? 如果出现了很多文�?不要着�? 看下面的 9 .

9, 如果lucene的烦引目录下出现了很多文�? 肯定是有问题�? 几个斚w��.首先lucene在执行写操作�? 会先在目录下写如一个write.lock的文仉��定这个目�?以避免别的烦引再操作�q�个路径. 否则那样肯定会�ؕ. 锁定之后, 开始写索引, 写烦引时lucene��Z��几个或者几十个临时片段文�g, 都似乎又短又��q��字符.cfs的文�? 当烦引徏立完毕后,没有执行 indexWriter.optimize();�Ҏ(gu��)��, 他就不会合�ƈ那些�׃��八糟的文�? 所�?索引建完�? 一定要执行上面的优化方�? 保持目录下保�?个文件即�? 也就是很多��时文件会合�ƈ��C��个文件中�? 切不可大意删�? 但当数据很多�? 另行考虑�{�略.

10, lucene在写入烦引时, 用在索引目录下徏write.lock文�g来标识锁�? 而只有在执行close()�Ҏ(gu��)��? 才会删除�q�个锁文�? 只要�q�个文�g存在, 其他的写索引的程序都会报�?
caught a class org.apache.lucene.store.LockObtainFailedException
with message: Lock obtain timed out: SimpleFSLock@E:"javasource"LuceneTest"index"write.lock

所�?需要注�? 一定要注意关闭indexWrite. 包括异常�?用finally关闭.否则会导致下一�ơ写索引��p�|.

11, 扚w��增加索引, 如果要成批的用��@环加入烦�?该怎么办呢. 首先��h��? IndexWriter indexWriter = new IndexWriter(indexDir,
new ThesaurusAnalyzer(), false); 最后一个参��Cؓfalse表示持箋想烦引增加数�? 如果为true, 则每�ơ会删除全部, 重新开�?

12, 在批量增加烦引时, �E�序可以一直执�?
indexWriter.addDocument(doc); 但不能一直执行优�?indexWriter.optimize(); 因�ؓ优化�Ҏ(gu��)��比较耗时, 特别是当索引很大�? 更要注意. 因�ؓ优化, 也仅仅似乎优化会消耗很多时间和cpu. 所以这个时�?多几个文件也没关�p? �|�上有个人问了这��L��问题, 我摘录如�? 用等号分割开我的内容:
引自:
http://www.javaeye.com/topic/107818?page=3
================================================
我不知道是不是理解错了增量烦引的概念
我搜索的�|�页不会重复,不是�Ҏ(gu��)��有的�|�页都不停的�?而是我搜索特定的�|�站.�q�里面不会出现重复现�?每次爬到的网��肯定是index里没有的

问一个问�?
如果�?0个网��需要徏立index
�?
IndexWriter iw=new IndexWriter(...);
for(int i=0;i<10;i++){
iw.addDocuemnt(doc);
}
iw.close();

�q�是
for(int i=0;i<10;i++){
IndexWriter iw=new IndexWriter(...);
iw.addDocuemnt(doc);
iw.close();
}

�q�有�Q�如果index量有10G�Q�做一�ơoptimize需要多长时��_��
��多长旉��Optimize一�ơ？
对一个刚刚做�q�Optimize的index目录做Optimize�Q�会不会很快��q��束，�q�是也需要很长时��_��
optimize�l�束后是不是只剩�?个文�Ӟ��如果有其他文�Ӟ��是不是意味着有问题呢�Q�（没有Reader或者Searcher在��用这个index的时候）

�q�回��端最后更�? 2007-08-10 11:02 (0) (0) 正在投票�?..

amigobot �{��: 初��会员

文章: 28
�U�分: 14

旉��: 2007-08-12 14:15 引用收藏

--------------------------------------------------------------------------------

没有必要6分钟一�ơ�?每次optimize都会重新做烦引，光拷�?0G文�g��得多少分钟�Q�如果不是频�J�删除的话，一天，甚至一�C�拜一��都可以�?选择�pȝ��负蝲��的时候就行�?

�q�回��端最后更�? 2007-08-12 14:15 (0) (0) 正在投票�?..

licco1 �{��: 初��会员

文章: 22
�U�分: 0

旉��: 2007-09-06 09:43 引用收藏

--------------------------------------------------------------------------------

1:当search动作太频�J?或者访问的人很�?在optimize时会出现�q�个message
java.io.IOException: Cannot delete E:"index"_nir.f2;
注意��查下是不是每�ơ查询完都把indexReader�l�close了。你可以��试下，频繁的开search�Q�如果还有这个异常，估计��是没把 indexReader�l�close�Q�千万不要以为close the indexSearcher ��ok了，要注意新建indexSearcher时传的参数是什么，是Direcitory,�q�是indexReader�Q�还是字�W�串文�g路径�Q�这影响�? 否close indexReader�Q?

�q�回��端最后更�? 2007-09-06 09:43 (0) (0) 正在投票�?..

fool_leave �{��: 初��会员

性别:
文章: 21
�U�分: 0
来自: 上�v

旉��: 2007-09-07 09:44 引用收藏

--------------------------------------------------------------------------------

新徏indexReader时传入的是index file path�Q�而且在search完毕后都在finally里面做了close动作�?

BTW�Q�我把optimize动作��L��后，也就是说无论它运行多久都不让他optimze�Q�结果index很正常，文�g数量不会增加很多�Q�search也okay�?

问题是��M��能老这样呀�Q�一直不optimize也不行呀。我做一�ơoptimize�Q�就要n分钟�Q�index文�g太大�Q�没办法�?

而且我的index动作是针对不同的�|�页�Q�比�?a target="_blank">http://xxx.xxx.xxx/1.html被index后，以后遇到�q�个��面��׃��会再做index动作。换句话��_��每次index的内定w��是新的，不会覆盖以前的东�ѝ��这��L��需求是不是不用optimize呀�?

�q�回��端最后更�? 2007-09-07 09:44 (0) (0) 正在投票�?..

licco1 �{��: 初��会员

文章: 22
�U�分: 0

旉��: 2007-09-07 10:09 引用收藏

--------------------------------------------------------------------------------

fool_leave�Q�你用的lucene版本是多��？如果�?.2的话�Q�可以用indexwriter�Q�以前用2.0�Q�我用indexReader执行删除操作也出现过�c�M��的情况（怀疑是indexreader只将被删除的documents讄��了下删除的标志，在close的时候没真正执行删除动作�Q? 也许是我��执行了一个步骤，=会去看看reader的删除操作）。如果因为文件太大导致优�?optimze�Q�它的作用是重新整理�D�，把document 的id重新讄��Q�这个对搜烦效率很有帮助�Q�和document里term的内�Ҏ(gu��)��关系)的时间很长，那就得重新考虑下你的架构了(10g太大�?。这个得 ��h��下imjl.

�q�回��端最后更�? 2007-09-07 10:12 (0) (0) 正在投票�?..

dwangel �{��:

文章: 500
�U�分: 650
圈子: TODOtree-ruby

旉��: 2007-09-07 12:38 引用收藏

--------------------------------------------------------------------------------

��讄��旉��d��Q�凌�?点启动indexWriter�q�行optimise�?
启动前前台页面切换到昄��l�护的状态，然后�{�待所有的reader,searcher关闭�Q�然后进行optimise。（当然只有一个writer在跑�Q?

In environments with frequent updates, optimize is best done during low volume times, if at all.
摘自lucene的文�?
http://lucene.zones.apache.org:8080/hudson/job/Lucene-Nightly/javadoc/org/apache/lucene/index/IndexWriter.html#optimize()

It is best not to re-open readers while optimize is running.
�q�句话我不是很明白，我觉得应该是说不要在optimize�q�行时打开新的reader。但是用的re-open�Q�难道是�?
不要在optimize�Ӟ��重置reader。的状态？

�q�回��端最后更�? 2007-09-07 12:48 (0) (0) 正在投票�?..

licco1 �{��: 初��会员

文章: 22
�U�分: 0

旉��: 2007-09-07 17:29 引用收藏

--------------------------------------------------------------------------------

因�ؓif some but not all readers re-open while the optimize is underway, this will cause > 2X temporary space to be consumed as those new readers will then hold open the partially optimized segments at that time.所以It is best not to re-open readers while optimize is running.在进行优化的时候最好不要新开readers(2.2里好像没有reopen�q�个�Ҏ(gu��)��吧，2.3里估计会�?�Q�因为新的readers�? 时会打开部分优化�q�的�D�，索引耗损的��时空间会大于两倍烦引大��?��译错了��g��的一定要指出来哦)�?

我觉得在做优化时�Q�不会对searcher有媄响，不必关闭搜烦功能�?

�q�回��端最后更�? 2007-09-07 17:31 (0) (0) 正在投票�?..

fool_leave �{��: 初��会员

性别:
文章: 21
�U�分: 0
来自: 上�v

旉��: 2007-09-10 09:56 引用收藏

--------------------------------------------------------------------------------

thanks
无论是不是reopen,optimize都会耗用更多的space来存储��时文�?但这些都是��时文�?在动作结束后会被释放�?所以如果硬盘空间��够，�q�些多余的耗用应该不是大问题�?

但我的index目录��d��?G�Q�我把旧的document删除了）。不�q�每�ơoptimize一栯��p��很长旉��。我不知道应该如何重新设�|�document的id.我的lucene version�?.0的�?

lucene的optimize的结果除了将index的文件数变成3个，�q�有什么好处呢�Q�到现在我看来只有在delete索引节点后有必要通过 optimize真正的把�q�些节点删除�Q�其他的优势��g��非常不明显。（因�ؓ我每�ơ写入index的烦引内定w��是新的，不会有重复或�q�加现象�Q�。我现在��d�� 把optimize从程序里��L��了，�q�行到现在已�l?个月了，每分钟都有新内容加进去，但index目录依然很正常，文�g�?4个，从文件的修改旉��上来看也很正常。search动作也很正常�?

如果一�ơoptimize需要花�?分钟以上的时��_��而这个操作又是不可中断的�Q�一旦在optimize�q�程中终止了�E�序�Q�就会出现l(f��)ucene自��n无法恢复问题。这样对于程序要求太高了。对于服务器��理也要求太高了�?

=========================================
上面的内�Ҏ(gu��)��些多, 不过也对大家有益. 他说最后他把执行优化的代码��L��?�q�行很好. 对于大数据量的来�? �q�是个经�? 除非采用冗余的机�? 而不能对正在使用的数据进行优化操�? 会造成用户讉K��d��.

�׃��面可见的, 我就不说�?
13, 索引�q�程中的��L��时刻、�Q意进�E�都能对索引文�g�q�行优化�Q�而且�q�样做也不会损坏索引文�g或��其不能被搜烦�Q�但是在索引�q�程中对索引�q�行优化的做法�ƈ不值得提倡。优化操作的最��x��机是在烦引过�E�结束之后，且当你确认在此后的一�D�|��间内不会对烦引文件进行更改的时候。在索引�q�程中进行优化只会��优化操作耗费�? 多的旉��?请大家�݅取这个思想)

14, �q�是优化, 些�h�? 我用lucene做了一个Search Engine
�E�序�q�行也很正常�Q�但如果�q�箋�q�行几个月，有时会出现磁盘空间不��的情况 .
通过iw.addDocument(doc)写入index
当list里的东西全部被写入完毕后�Q�通过optimze来优化烦�?
可这个东西运行不是很�E�_��Q�有的时候很正常�Q�运行几个月都okay�Q�有�?个月��出现问题了。会在index的目录里出现很多文�g。这些文件似乎是应该�? optimize掉的�?一个烦引只能有一个indexreader, 在optimize的时候可以有多个indexsearcher在工作�?
你得��保
-->optimize��实调用�?
-->optimize的时候，得有双倍的��盘�I�间. 可见优化的代�?

15 ,面的lucene都是在一个目录里面的, 大家也都看到�? 也就是如果这个文件一直很大怎么�? 首先��到的第一个问题是��是文�g大小限制. 首先面��的是一个大目录问题.

16, lucene的性能��试:
下面�l�出一些测试数据，如果你觉得可以接受，那么可以选择�?
��试一�Q?50万记录，300M左右文本�Q�生成烦�?80M左右�Q?00�U�程下��^均处理时�?00ms�?
��试二：37000记录�Q�烦引数据库中的两个varchar字段�Q�烦引文�?.6M�Q?00�U�程下��^均处理时�?.5ms�?

17 . 分布搜烦

我们可以使用 MultiReader �?MultiSearcher 搜烦多个索引库�?

MultiReader reader = new MultiReader(new IndexReader[] { IndexReader.Open(@"c:"index"), IndexReader.Open(@"""server"index") });
IndexSearcher searcher = new IndexSearcher(reader);
Hits hits = searcher.Search(query);

�?

IndexSearcher searcher1 = new IndexSearcher(reader1);
IndexSearcher searcher2 = new IndexSearcher(reader2);
MultiSearcher searcher = new MultiSearcher(new Searchable[] { searcher1, searcher2 });
Hits hits = searcher.Search(query);

�q�可以��?ParallelMultiSearcher �q�行多线�E��ƈ行搜索�?

18. 合�ƈ索引�?

��?directory1 合�ƈ�?directory2 中�?
Directory directory1 = FSDirectory.GetDirectory("index1", false);
Directory directory2 = FSDirectory.GetDirectory("index2", false);

IndexWriter writer = new IndexWriter(directory2, analyzer, false);
writer.AddIndexes(new Directory[] { directory });
Console.WriteLine(writer.DocCount());
writer.Close();

19. 昄��搜烦语法字符�?

我们�l�合了很多种搜烦条�g�Q�或许想看看与其对等的搜索语法串是什么样的�?
BooleanQuery query = new BooleanQuery();
query.Add(query1, true, false);
query.Add(query2, true, false);
//...

Console.WriteLine("Syntax: {0}", query.ToString());

输出�Q?
Syntax: +(name:name* value:name*) +number:[0000000000000000b TO 0000000000000000d]

呵呵�Q�就�q�么��单�?

20. 操作索引�?

删除 (软删除，仅添加了删除标记。调�?IndexWriter.Optimize() 后真正删除�?
IndexReader reader = IndexReader.Open(directory);

// 删除指定序号(DocId)�?Document�?
reader.Delete(123);

// 删除包含指定 Term �?Document�?
reader.Delete(new Term(FieldValue, "Hello"));

// 恢复软删除�?
reader.UndeleteAll();

reader.Close();

增量更新 (只需��?create 参数设�ؓ false�Q�即可往现有索引库添加新数据�?
Directory directory = FSDirectory.GetDirectory("index", false);
IndexWriter writer = new IndexWriter(directory, analyzer, false);
writer.AddDocument(doc1);
writer.AddDocument(doc2);
writer.Optimize();
writer.Close();

21. 优化

扚w��?FSDirectory 增加索引�Ӟ��增大合�ƈ因子(mergeFactor )和最��文档合�q�数(minMergeDocs)有助于提高性能�Q�减��烦引时间�?

IndexWriter writer = new IndexWriter(directory, analyzer, true);

writer.maxFieldLength = 1000; // 字段最大长�?
writer.mergeFactor = 1000;
writer.minMergeDocs = 1000;

for (int i = 0; i < 10000; i++)
{
// Add Documentes...
}

writer.Optimize();
writer.Close();

相关参数说明

转自《深�?Lucene 索引机制�?

利用 Lucene�Q�在创徏索引的工�E�中你可以充分利用机器的��g资源来提高烦引的效率。当你需要烦引大量的文�g�Ӟ��你会注意到烦引过�E�的瓉��是在往��盘上写�? 引文件的�q�程中。�ؓ了解册��个问�? Lucene 在内存中持有一块缓冲区。但我们如何控制 Lucene 的缓冲区呢？�q�运的是�Q�Lucene 的类 IndexWriter 提供了三个参数用来调整缓冲区的大��以及往��盘上写索引文�g的频率�?

22�Q�合�q�因�?(mergeFactor)

�q�个参数军_��了在 Lucene 的一个烦引块中可以存攑֤��文档以及把��盘上的索引块合�q�成一个大的烦引块的频率。比如，如果合�ƈ因子的值是 10�Q�那么当内存中的文档数达�?10 的时候所有的文档都必��d��到磁盘上的一个新的烦引块中。�ƈ且，如果��盘上的索引块的隔数辑ֈ� 10 的话�Q�这 10 个烦引块会被合�ƈ成一个新的烦引块。这个参数的默认值是 10�Q�如果需要烦引的文档数非常多的话�q�个值将是非�怸�合适的。对批处理的索引来讲�Q��ؓ�q�个参数赋一个比较大的��g��得到比较好的索引效果�?

23�Q�最��合�q�文档数 (minMergeDocs)

�q�个参数也会影响索引的性能。它军_��了内存中的文档数臛_��辑ֈ�多少才能��它们写回磁盘。这个参数的默认值是10�Q�如果你有��够的内存�Q�那么将�q�个值尽量设的比较大一些将会显著的提高索引性能�?

24�Q�最大合�q�文档数 (maxMergeDocs)

�q�个参数军_��了一个烦引块中的最大的文档数。它的默认值是 Integer.MAX_VALUE�Q�将�q�个参数讄��为比较大的值可以提高烦引效率和��索速度�Q�由于该参数的默认值是整型的最大��|��所以我们一般不需要改动这个参数�?

25 , �Ҏ(gu��)��官方文档:从中可以分析出，如果在optimize索引的时候，也同时��用Searcher。烦引空间的使用情况如下�Q?
1. 原始索引
2. 由IndexWriter使用的烦引，用于optimize
3. 由IndexSearcher使用的烦引，用于搜烦�?

所以要三倍的正常�I�间.

��Z��么需要优化？
��管未经优化的烦引在大多数应用程序中都能够很好地�q�行工作�Q�但在那些处理大扚w��索引的应用程序中�Q��用优化过的烦引会�l�应用程序带来更多的好处。特别是在搜索操作需要长旉��打开多个索引文�g的情况下�Q�更能体现出索引被优化后的优势，因�ؓ使用优化�q�的索引可以减少需要打开的文件描�q�符的个�?

优化所需的磁盘空�?
值得指出的是�Q�Lucene对一个烦引的优化操作是通过把已存在的段合�ƈ成一个全新的�D�|��完成的，�q�些已存在段的内�Ҏ(gu��)��l�会在新的段中表�C�出来。因而在�q? 行优化时�Q��用的��盘�I�间会有明显的增加。在新段创徏完成�Ӟ��Lucene删除�q�移除这些旧�D�c��因此，在旧的段�q�没有被删除之前�Q�烦引占用的��盘�I�间会变成原来的两倍，因�ؓ此时新段和旧�D�都会存储在索引中。在优化完成后，所占用的磁盘空间会降回��C��化前的状态。请��C��Q�烦引优化的对象可以是多文�g索引或复合烦引�?

26 , 索引文�g有大��限制吗�Q?��译)

某些 32 位操作系�l�限制每个文件不能大�?2GB�?

解决�Ҏ(gu��)��Q?
1. 使用 IndexWriter.setMaxMergeDocs() 减小 MaxMergeDocs 数倹{�?
2. 使用多个索引库。��用复合烦�?

27, IndexWriter.SetUseCompoundFile(true) 有什么用�Q?

在创建烦引库�Ӟ��会合�q�多�?Segments 文�g��C��?.cfs 中。此方式有助于减��烦引文件数量，减少同时打开的文件数量。原因：
某些操作�pȝ��会限制同时打开的文件数量�?

解决�Ҏ(gu��)��Q?
1. 使用 IndexWriter's setUseCompoundFile(true) 创徏复合文�g�Q�减��烦引文件数量�?
2. 不要��?IndexWriter's mergeFactor 的��D��|�过大。尽��这能加快烦引速度�Q�但会增加同时打开的文件数量�?
3. 如果在搜索时发生该错误，那么你最好调�?IndexWriter.Optimize() 优化你的索引库�?
4. ��认你仅创徏了一�?IndexSearcher 实例�Q��ƈ且在所有的搜烦�U�程中共用�?原文�Q?Make sure you only open one IndexSearcher, and share it among all of the threads that are doing searches -- this is safe, and it will minimize the number of files that are open concurently. " 晕~~~�Q�究竟要怎么做？ )

28, ��Z��么搜索不到结果？(��译)

可能原因�Q?
. 搜烦字段没有被烦引�?
. 索引库中的字�D�|��有分词存储，无法和搜索词语进行局部匹配�?
. 搜烦字段不存在�?
. 搜烦字段名错误，注意字段名称区分大小写。徏议对字段名进行常量定义�?
. 要搜索的词语是忽略词(StopWords)�?
. 索引(IndexWriter)和搜�?IndexSearcher)所使用�?Analyzer 不同�?
. 你所使用�?Analyzer 区分大小写。比如它使用�?LowerCaseFilter�Q�而你输入的查询词和目标大��写不同�?
. 你烦引的文档(Document)太大。Lucene 为避免造成内存不��(OutOfMemory)�Q�缺省仅索引�?0000个词�?Term)。可以��?IndexWriter.setMaxFieldLength() 调整�?
. ��认在搜索前�Q�目标文档已�l�被��d��到烦引库�?
. 如果你��用了 QueryParser�Q�它可能�q�没有按照你所设想的去分析 BooleanQuerySyntax�?

如果�q�不行，那么�Q?

. 使用 Query.ToString() 查看�I�竟搜烦了些什么�?
. 使用 Luke 看看你的索引库究竟有什么�?

29, 上面的luke是查看烦引库�? 我下载了一个版�? 居然��L��C�我�l�他的烦引�\径不�?无奈. .

30 ,

QueryParser 是线�E�安全的吗？

不是�?

31, 说说分布式数据存�? 支持lucene的分布式搜烦��是 hadoop. �q�个也是apache下的属于lucene的开源项�? 但目前的我看只支持linux的分布机�? �|�上很多�q�个斚w��? 据说开发hadoop的�h已经��M��yahoo. 让hadoop支撑雅虎的分布式搜烦. 所以按说功能强�?2006�q�的一月䆾Nutch和Lucene的缔造者Doug Cutting加入了Yahoo公司�Q�从那时��P��Yahoo��开始进行Hadoop的部�|�与研究. 但网上有��, �q�个分布式效率不�?

参数如下:

�l�测试，Hadoop�q�不是万用灵丹，很取决于文�g的大��和数量�Q�处理的复杂度以及群集机器的数量�Q�相�q�的带宽�Q�当以上四者�ƈ不大�Ӟ��hadoop优势�q�不明显�?
比如�Q�不用hadoop用java写的��单grep函数处理100M的log文�g只要4�U�，用了hadoop local的方式运行是14�U�，用了hadoop单机集群的方式是30�U�，用双机集��?0M�|�口的话更慢�Q�慢��C��好意思说出来的地步�?

�? 怎么评�h(hu��n)上面的哥们测试结果呢. 但愿他说的不�? 因�ؓ如果�q�样, yahoo不就��M��..

32, MaxDoc() �?DocCount()、NumDocs() 有什么不同？

MaxDocs() 表示索引库中最大的 Document ID ��P��׃��中间的某�?Document 可能被删除，因此不能使用 MaxDocs() 来表�C?Document 数量。IndexWriter.DocCount()、IndexReader.NumDocs()�? IndexSearcher.Reader.NumDocs() 都表�C�烦引库�?Document 数量�?

33, ��Z��么同时进行搜索和更新会引�?FileNotFoundException 异常�Q?��译)

可能原因�Q?
1. 某个搜烦或更新对象禁用了锁�?
2. 搜烦和更��C��用了不同�?lockDir�?
3. 索引库被存放�?NFS (or Samba) 文�g�pȝ��上�?

��管搜烦是只��L��作，�?IndexSeacher ��Z��获取索引文�g列表�Q�也必须打开旉��定烦引库。如果锁没有正确讄��Q�那么它?y��u)��取回一个错误的文�g列表(此时 IndexWriter 可能正在��d��或优化烦�?�Q�从而导致该异常发生�?

34, write.lock 有什么用�Q�哪些类会用到它�Q?��译)

write.lock 用来协调索引库的�q�发修改处理�?
�?IndexWriter 打开索引库，或�?IndexReader 删除文档旉��创��锁�?

35. commit.lock 文�g有什么用�Q�哪些类会用到它�Q?��译)

commit.lock 在调整烦引库 segments 文�g内容时��用�?IndexReader �?IndexWriter 都会使用到它�?

36, 如何更新已经索引的文档？ (��译)

你只能先删除�Q�然后添加更新后的文档�?

使用 IndexWriter.addIndexes(IndexReader[]) �?IndexWriter.addIndexes(Directory[]) 合�ƈ索引库有什么不同？ (��译)

使用 Directory[] 参数所需的文件句柄和内存较小�Q�烦引文件仅需打开一�ơ，而��?IndexReader[] 参数则需要打开所有的索引库�?

淘声依旧 2008-10-29 09:16 发表评论

《Lucene in action》中推荐的Lucene分页方式

淘声依旧 — Tue, 28 Oct 2008 06:36:00 GMT

private List processHits(Hits hits,int startIndex,int endIndex)throws Exception{
  if(endIndex>=hits.length())
   endIndex=hits.length()-1;
  List docs=new ArrayList();
  for(int i=startIndex;i<=endIndex;i++){
   Document doc=hits.doc(i);
   Map docMap=new HashMap();
   docMap.put("id",doc.getField("id").stringValue());
   docMap.put("name",doc.getField("name").stringValue());
   docMap.put("price",doc.getField("price").stringValue());
   docs.add(docMap);
  }
  return docs;
}

淘声依旧 2008-10-28 14:36 发表评论

国产永久av在线,韩日一区二区,校园春色亚洲色图

[转]lucene学习�W�记�?-- 关于高亮昄���和显�C�部分原始文件的原则

[转]lucene学习�W�记十一 -- 建烦引优�?复杂排序HitCollector,匚w�����法

[转]lucene学习�W�记�?- 关于�l�果分页

[转]lucene学习�W�记�?分词

[转]lucene学习�W�记�? 几个问题

[转]lucene学习�W�记六——Lucene的搜�?IndexSearcher)

[转]lucene学习�W�记�?

[转]lucene学习�W�记�?各种query

[转]lucene学习�W�记�? 1.9版本升��的问�?

《Lucene in action》中推荐的Lucene分页方式

[转]lucene学习�W�记�?-- 关于高亮昄��和显�C�部分原始文件的原则

[转]lucene学习�W�记十一 -- 建烦引优�?复杂排序HitCollector,匚w��法