]]>
]]>
]]>
]]>
前言Q?数据库工E师众所周知的一个事实是Q当Ҏ据库里的文本字段q行like索的时候，M数据索引都是不v作用的，q样也就Dpȝ会承担额外的开销和负载压力，对于庞大的数据记录，对其中的文本字段q行关键字匹配，p定会存在非常严重的效率障和性能障碍。因此，Z文本的全文烦引技术也逐渐兴v?
全文索引的技术原理ƈ不复杂，Ҏ落性的文本内容q行逐词分解Qƈ针对词出现频率，出现位置q行标记Q按照词本n的编码顺序存储ؓ索引文g。这P在针对关键词q行索的时候，׃会遍历所有的文本数据记录Q而是Ҏ索引文gq行有序查找Q这里面一个显见的事实是，通过有序索引查找关键词，对于量的数据记录而言Q也只需要很次数的指针跌{Q（数量为X的烦引记录，查询特定记录的指针蟩转次数最多ؓLog2(x)。）卛_完成搜烦Q而无d整遍历整个数据表或文仉?
但是全文索引技术的实现却ƈ不简单，针对中文的尤其如此，英文文本中，I格是天然的分词标记Q而中文段落却无法通过q样单的途径分词Q因此基于常用语词典和一些语a识别规则的分词技术成ZU非帔R的技术门槛，q好Q很多商业公司提供了非常成熟的商业品，使我{可以坐享其成，快速搭建全文搜索的q_?
ORACLE INTERMEDIA介绍
ORACLE Intermedia是ORACLE公司官方发布的用来管理多媒体数据的数据库理模块Q通过它可以进行有效的视频Q音频，囄{文件的l一存储Q调用和相关处理Q同时其中也包括一个Oracle Intermdedia Text功能模块Q能够对多种格式文档q行分词索引处理Q也提供了用自然语法或高查询Ҏq行跨文本查询的途径Q可以查询word, PDF,RTF{格式的文g和数据?
Oracle Intermedia 的烦引效率和查询效率Q据一些公开数据上看要远高于Microsoft的Index ServerQ而且本nhq_无关Ҏ，另外作ؓ数据库品，可以很好的和数据库应用进行整合，q一点也是纯_的文g索引pȝ所无法实现的。当Ӟ作ؓ通用的数据库产品QOracle不可能针对全文烦引做到最大限度的优化Q因此对于高q发大容量的搜烦引擎应用QOracle的方案可能就无法满Q这一点也是必L前声明的?
全文索引实现步骤
步骤1Q查看Oracle Intermedia是否正确安装。Oracle Intermdeia是Oracle的一个附带模块，安装q程中选择卛_?
步骤2Q设|词法解析器
oracleҎ不同语言Q有不同的词法解析器Q以下说明我们可能用到的三个
basic_lexerQ针对英语环境，以空gؓ分词标记Q同时能分L一些“噪音”单词，?“if? “is”等?
chinese_vgram_lexerQ专用的汉语分析器，按字为单元分析中文，法单，可以一|打中文用词，但是效率差强人意?
chinese_lexerQ可以识别大部分常用短语和词汇，不会产生大量冗余数据Q有很好的实用性，但是语言支持只能为UTF-8~码Q不支持zhs16gbk字符集?
以ctxsys用户登陆pȝQ执行：
begin ctx_ddl.create_preference('my_lexer','chinese_vgram_lexer'); end;
q里假设我们的语法解析器命名为my_lexerQ这个名UC可以Ҏ实际应用变化?
步骤3Q徏立烦引字D?
我的试用例保存在systemI间Q表名ؓmy_docsQ字D名为docQ字D늱型ؓblobQ存储标准word doc文g?
仍旧保持ctxsys帐户登陆Q执行如下操?
create index system.myindex on system.my_docs(doc) indextype is ctxsys.context parameters(‘lexer?’my_lexer? ;
步骤4Q同步操作（syncQ及优化操作
以system 登陆Q同步操作执?
exec ctx_ddl.sync_index('myindex');
创徏同步定时d代码如下
VARIABLE jobno number;
BEGIN
DBMS_JOB.SUBMIT(:jobno,'ctx_ddl.sync_index(''myindex'');',
SYSDATE, 'SYSDATE + (1/24/4)');
commit;
END;
/
以system登陆Q优化烦引操作执?
exec ctx_ddl.optimize_index('myindex','FULL');
创徏优化定时d代码如下
VARIABLE jobno number;
BEGIN
DBMS_JOB.SUBMIT(:jobno,'ctx_ddl.optimize_index(''myindex'',''FULL'');',
SYSDATE, 'SYSDATE + 1');
commit;
END;
/
步骤5Q测?
select id from my_docs where contains(doc,'关键?)>0
ȝQ?
该学习笔记内容大部分可以通过搜烦引擎扑ֈQƈ非本人原创内容，本文全部l个人在windowsq_下，在oracle 9i下测试完成，留档记录Qؓ日后的项目和产品开发做技术准备?
]]>
全文索引—CONTAINS语法
全文索引——CONTAINS 语法
我们通常?WHERE 子句中?CONTAINS Q就象这PSELECT * FROM table_name WHERE CONTAINS(fullText_column,'search contents')?
我们通过例子来学习，假设有表 studentsQ其中的 address 是全文本索的列?br />1. 查询住址在北京的学生
SELECT student_id,student_name
FROM students
WHERE CONTAINS( address, 'beijing' )
remark: beijing是一个单词，要用单引hh?br />
2. 查询住址在河北省的学?br />SELECT student_id,student_name
FROM students
WHERE CONTAINS( address, '"HEIBEI province"' )
remark: HEBEI province是一个词l，在单引号里还要用双引hh?br />
3. 查询住址在河北省或北京的学生
SELECT student_id,student_name
FROM students
WHERE CONTAINS( address, '"HEIBEI province" OR beijing' )
remark: 可以指定逻辑操作W?包括 AND QAND NOTQOR )?br />
4. 查询?'南京? 字样的地址
SELECT student_id,student_name
FROM students
WHERE CONTAINS( address, 'nanjing NEAR road' )
remark: 上面的查询将q回包含 'nanjing road'Q?nanjing east road'Q?nanjing west road' {字L地址?br /> A NEAR BQ就表示条gQ?A 靠近 B?br />
5. 查询?'? 开头的地址
SELECT student_id,student_name
FROM students
WHERE CONTAINS( address, '"hu*"' )
remark: 上面的查询将q回包含 'hubei'Q?hunan' {字L地址?br /> C?*Q不?%?br />
6. cM加权的查?br />SELECT student_id,student_name
FROM students
WHERE CONTAINS( address, 'ISABOUT (city weight (.8), county wright (.4))' )
remark: ISABOUT 是这U查询的关键字，weight 指定了一个介?0~1之间的数Q类似系?我的理解)。表CZ同条件有不同的侧重?br />
7. 单词的多态查?br />SELECT student_id,student_name
FROM students
WHERE CONTAINS( address, 'FORMSOF (INFLECTIONAL,street)' )
remark: 查询返回包?'street'Q?streets'{字L地址?br /> 对于动词返回它的不同的时态，如：dryQ将q回 dryQdriedQdrying {等?img src ="http://www.aygfsteel.com/machilansing/aggbug/64048.html" width = "1" height = "1" />
]]>
Lucene不是一个完整的全文索引应用Q而是是一个用Java写的全文索引引擎工具包，它可以方便的嵌入到各U应用中实现针对应用的全文烦?索功能?/p>
Lucene的作者：Lucene的A献?a >Doug Cutting是一位资深全文烦?索专Ӟ曄是V-Twin搜烦引擎(Apple的Copland操作pȝ的成׃一)的主要开发者，后在Excite担Q高pȝ架构设计师，目前从事于一些INTERNET底层架构的研I。他贡献出的Lucene的目标是为各U中型应用E序加入全文索功能?/p>
Lucene的发展历E：早先发布在作者自qwww.lucene.comQ后来发布在SourceForgeQ?001q年底成为APACHE基金会jakarta的一个子目Q?a >http://jakarta.apache.org/lucene/
已经有很多Java目都用了Lucene作ؓ其后台的全文索引引擎Q比较著名的有：
- J iveQWEB论坛pȝQ?
- EyebrowsQ邮件列表HTML归档/览/查询pȝQ本文的主要参考文档?a >TheLucene search engine: Powerful, flexible, and free”作者就是EyeBrowspȝ的主要开发者之一Q而EyeBrows已经成ؓ目前APACHE目的主要邮件列表归档系l?
- Cocoon:ZXML的web发布框架Q全文检索部分用了Lucene
-
Eclipse:ZJava的开攑ּ发^収ͼ帮助部分的全文烦引用了Lucene
对于中文用户来说Q最兛_的问题是其是否支持中文的全文索。但通过后面对于Lucene的结构的介绍Q你会了解到׃Lucene良好架构设计Q对中文的支持只需对其语言词法分析接口q行扩展p实现对中文检索的支持?/p>
Lucene的API接口设计的比较通用Q输入输出结构都很像数据库的?=>记录==>字段Q所以很多传l的应用的文件、数据库{都可以比较方便的映到Lucene的存储结?接口中。M上看Q可以先?b>Lucene当成一个支持全文烦引的数据库系l?/b>?/p>
比较一下Lucene和数据库Q?/p>
| Lucene | 数据?/td> |
索引数据源：doc(field1,field2...) doc(field1,field2...) |
索引数据源：record(field1,field2...) record(field1..) |
| DocumentQ一个需要进行烦引的“单元?br />一个Document由多个字D늻?/td> | RecordQ记录，包含多个字段 |
| FieldQ字D?/td> | FieldQ字D?/td> |
| HitsQ查询结果集Q由匚w的Documentl成 | RecordSetQ查询结果集Q由多个Recordl成 |
全文??like "%keyword%"
通常比较厚的书籍后面常常附关键词索引表（比如Q北京：12, 34，上vQ?,77……）Q它能够帮助读者比较快地找到相兛_容的늠。而数据库索引能够大大提高查询的速度原理也是一P惛_一下通过书后面的索引查找的速度要比一一地d定w多少倍……而烦引之所以效率高Q另外一个原因是它是排好序的?b>对于索系l来说核心是一个排序问?/b>?/p>
׃数据库烦引不是ؓ全文索引设计的，因此Q?b>使用like "%keyword%"Ӟ数据库烦引是不v作用?/b>Q在使用like查询Ӟ搜烦q程又变成类g一页M的遍历过E了Q所以对于含有模p查询的数据库服务来_LIKEҎ能的危x极大的。如果是需要对多个关键词进行模p匹配：like"%keyword1%" and like "%keyword2%" ...其效率也可惌知了?/p>
所以徏立一个高效检索系l的关键是徏立一个类gU技索引一L反向索引机制Q将数据源（比如多篇文章Q排序顺序存储的同时Q有另外一个排好序的关键词列表Q用于存储关键词==>文章映射关系Q利用这L映射关系索引Q[关键?=>出现关键词的文章~号Q出现次敎ͼ甚至包括位置Qv始偏U量Q结束偏U量Q，出现频率]Q检索过E就是把模糊查询变成多个可以利用索引的精查询的逻辑l合的过E?/b>。从而大大提高了多关键词查询的效率，所以，全文索问题归l到最后是一个排序问题?/p>
由此可以看出模糊查询相对数据库的_查询是一个非怸定的问题，q也是大部分数据库对全文索支持有限的原因。Lucene最核心的特征是通过Ҏ的烦引结构实C传统数据库不擅长的全文烦引机Ӟq提供了扩展接口Q以方便针对不同应用的定制?/p>
可以通过一下表格对比一下数据库的模p查询：
Lucene全文索引引擎
数据?/td>
索引
数据源中的数据都通过全文索引一一建立反向索引
对于LIKE查询来说Q数据传l的索引是根本用不上的。数据需要逐个便利记录q行GREP式的模糊匚wQ比有烦引的搜烦速度要有多个数量U的下降?/td>
匚w效果
通过词元(term)q行匚wQ通过语言分析接口的实玎ͼ可以实现对中文等非英语的支持?/td>
使用Qlike "%net%" 会把netherlands也匹配出来，
多个关键词的模糊匚wQ用like "%com%net%"Q就不能匚w词序颠倒的xxx.net..xxx.com
匚w?/td>
有匹配度法Q将匚wE度Q相似度Q比较高的结果排在前面?/td>
没有匚wE度的控Ӟ比如有记录中net出现5词和出现1ơ的Q结果是一L?/td>
l果输出
通过特别的算法，最匚w度最高的?00条结果输出，l果集是~冲式的批量读取的?/td>
q回所有的l果集，在匹配条目非常多的时候（比如上万条）需要大量的内存存放q些临时l果集?/td>
可定制?/td>
通过不同的语a分析接口实现Q可以方便的定制出符合应用需要的索引规则Q包括对中文的支持）
没有接口或接口复杂，无法定制
l论
高负载的模糊查询应用Q需要负责的模糊查询的规则，索引的资料量比较?/td>
使用率低Q模p匹配规则简单或者需要模p查询的资料量少
全文索和数据库应用最大的不同在于Q让
最相关?/span>
?00条结果满?8%以上用户的需?br />
Lucene的创C处：
大部分的搜烦Q数据库Q引擎都是用B树结构来l护索引Q烦引的更新会导致大量的IO操作QLucene在实CQ对此稍微有所改进Q不是维护一个烦引文Ӟ而是在扩展烦引的时候不断创建新的烦引文Ӟ然后定期的把q些新的烦引文件合q到原先的大索引中（针对不同的更新策略，Ҏ的大可以调_Q这样在不媄响检索的效率的前提下Q提高了索引的效率?/p>
Lucene和其他一些全文检索系l?应用的比较：
| Lucene | 其他开源全文检索系l?/td> | |
| 增量索引和批量烦?/td> | 可以q行增量的烦?Append)Q可以对于大量数据进行批量烦引，q且接口设计用于优化扚w索引和小扚w的增量烦引?/td> | 很多pȝ只支持批量的索引Q有时数据源有一点增加也需要重建烦引?/td> |
| 数据?/td> | Lucene没有定义具体的数据源Q而是一个文档的l构Q因此可以非常灵zȝ适应各种应用Q只要前端有合适的转换器把数据源{换成相应l构Q， | 很多pȝ只针对网，~Z其他格式文档的灵zL?/td> |
| 索引内容抓取 | Lucene的文档是由多个字D늻成的Q甚臛_以控刉些字D需要进行烦引，那些字段不需要烦引，q一步烦引的字段也分为需要分词和不需要分词的cdQ?br /> 需要进行分词的索引Q比如：标题Q文章内容字D?br /> 不需要进行分词的索引Q比如：作?日期字段 | ~Z通用性，往往文档整个烦引了 |
| 语言分析 | 通过语言分析器的不同扩展实现Q?br />可以qo掉不需要的词：an the of {， 西文语法分析Q将jumps jumped jumper都归l成jumpq行索引/?br />非英文支持：对亚z语aQ阿拉伯语言的烦引支?/td> | ~Z通用接口实现 |
| 查询分析 | 通过查询分析接口的实玎ͼ可以定制自己的查询语法规则： 比如Q?多个关键词之间的 + - and or关系{?/td> | |
| q发讉K | 能够支持多用L使用 |
对于中文来说Q全文烦引首先还要解决一个语a分析的问题，对于英文来说Q语句中单词之间是天焉过I格分开的，但亚z语a的中日韩文语句中的字是一个字挨一个，所有，首先要把语句中按“词”进行烦引的话，q个词如何切分出来就是一个很大的问题?/p>
首先Q肯定不能用单个字符?si-gram)为烦引单元，否则查“上”时Q不能让含有“v上”也匚w?/p>
但一句话Q“北京天安门”，计算机如何按照中文的语言习惯q行切分呢？
“北?天安门?q是“北 ?天安门”？让计机能够按照语言习惯q行切分Q往往需要机器有一个比较丰富的词库才能够比较准的识别句中的单词?/p>
另外一个解决的办法是采用自动切分算法：单词按?元语?bigram)方式切分出来Q比如：
"北京天安? ==> "北京 京天 天安 安门"?/p>
q样Q在查询的时候，无论是查?北京" q是查询"天安?Q将查询词组按同L规则q行切分Q?北京"Q?天安安门"Q多个关键词之间按与"and"的关pȝ合，同样能够正确地映到相应的烦引中。这U方式对于其他亚z语aQ韩文，日文都是通用的?/p>
Z自动切分的最大优Ҏ没有词表l护成本Q实现简单，~点是烦引效率低Q但对于中小型应用来_Z2元语法的切分q是够用的。基?元切分后的烦引一般大和源文件差不多Q而对于英文，索引文g一般只有原文g?0%-40%不同Q?/p>
|
|
自动切分 | 词表切分 |
| 实现 | 实现非常?/td> | 实现复杂 |
| 查询 | 增加了查询分析的复杂E度Q?/td> | 适于实现比较复杂的查询语法规?/td> |
| 存储效率 | 索引冗余大，索引几乎和原文一样大 | 索引效率高，为原文大的30Q左?/td> |
| l护成本 | 无词表维护成?/td> | 词表l护成本非常高：中日韩等语言需要分别维护?br />q需要包括词频统计等内容 |
| 适用领域 | 嵌入式系l：q行环境资源有限 分布式系l：无词表同步问?br />多语a环境Q无词表l护成本 |
Ҏ询和存储效率要求高的专业搜烦引擎 |
目前比较大的搜烦引擎的语a分析法一般是Z以上2个机制的l合。关于中文的语言分析法Q大家可以在Google查关键词"wordsegment search"能找到更多相关的资料?/p>
下蝲Q?a >http://jakarta.apache.org/lucene/
注意QLucene中的一些比较复杂的词法分析是用JavaCC生成的（JavaCCQJavaCompilerCompilerQ纯Java的词法分析生成器Q，所以如果从源代码编译或需要修改其中的QueryParser、定制自q词法分析器，q需要从https://javacc.dev.java.net/下蝲javacc?/p>
lucene的组成结构：对于外部应用来说索引模块(index)和检索模?search)是主要的外部应用入口
| org.apache.Lucene.search/ | 搜烦入口 |
| org.apache.Lucene.index/ | 索引入口 |
| org.apache.Lucene.analysis/ | 语言分析?/td> |
| org.apache.Lucene.queryParser/ | 查询分析?/td> |
| 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还可以选择不同的烦?存储字段规则Q列表如下：| Ҏ | 切词 | 索引 | 存储 | 用?/th> |
|---|---|---|---|---|
| Field.Text(String name, String value) | Yes | Yes | Yes | 切分词烦引ƈ存储Q比如：标题Q内容字D?/td> |
| Field.Text(String name, Reader value) | Yes | Yes | No | 切分词烦引不存储Q比如：META信息Q?br />不用于返回显C，但需要进行检索内?/td> |
| Field.Keyword(String name, String value) | No | Yes | Yes | 不切分烦引ƈ存储Q比如：日期字段 |
| Field.UnIndexed(String name, String value) | No | No | Yes | 不烦引，只存储，比如Q文件\?/td> |
| Field.UnStored(String name, String value) | Yes | Yes | No | 只全文烦引，不存?/td> |
public class IndexFiles {
//使用ҎQ? IndexFiles [索引输出目录] [索引的文件列表] ...
public static void main(String[] args) throws Exception {
String indexPath = args[0];
IndexWriter writer;
//用指定的语言分析器构造一个新的写索引器（W?个参数表C是否ؓq加索引Q?br /> writer = new IndexWriter(indexPath, new SimpleAnalyzer(), false);
for (int i=1; i<args.length; i++) {
System.out.println("Indexing file " + args[i]);
InputStream is = new FileInputStream(args[i]);
//构造包?个字DField的Document对象
//一个是路径path字段Q不索引Q只存储
//一个是内容body字段Q进行全文烦引，q存?br /> Document doc = new Document();
doc.add(Field.UnIndexed("path", args[i]));
doc.add(Field.Text("body", (Reader) new InputStreamReader(is)));
//文档写入烦?br /> writer.addDocument(doc);
is.close();
};
//关闭写烦引器
writer.close();
}
}
索引q程中可以看刎ͼ
- 语言分析器提供了抽象的接口，因此语言分析(Analyser)是可以定制的Q虽然lucene~省提供?个比较通用的分析器SimpleAnalyser和StandardAnalyserQ这2个分析器~省都不支持中文Q所以要加入对中文语a的切分规则，需要修改这2个分析器?
- Luceneq没有规定数据源的格式，而只提供了一个通用的结构（Document对象Q来接受索引的输入，因此输入的数据源可以是：数据库，WORD文档QPDF文档QHTML文档……只要能够设计相应的解析转换器将数据源构造成成Docuement对象卛_q行索引?
- 对于大批量的数据索引Q还可以通过调整IndexerWrite的文件合q率属性（mergeFactorQ来提高扚w索引的效率?
索过E和l果昄Q?/p>
搜烦l果q回的是Hits对象Q可以通过它再讉KDocument==>Field中的内容?/p>
假设Ҏbody字段q行全文索，可以查询结果的path字段和相应查询的匚w?score)打印出来Q?/p>
public class Search {
public static void main(String[] args) throws Exception {
String indexPath = args[0], queryString = args[1];
//指向索引目录的搜索器
Searcher searcher = new IndexSearcher(indexPath);
//查询解析器：使用和烦引同L语言分析?br /> Query query = QueryParser.parse(queryString, "body",
new SimpleAnalyzer());
//搜烦l果使用Hits存储
Hits hits = searcher.search(query);
//通过hits可以讉K到相应字D늚数据和查询的匚w?br /> for (int i=0; i<hits.length(); i++) {
System.out.println(hits.doc(i).get("path") + "; Score: " +
hits.score(i));
};
}
}在整个检索过E中Q语a分析器，查询分析器，甚至搜烦器（SearcherQ都是提供了抽象的接口，可以Ҏ需要进行定制?
化的查询分析?/b>
个h感觉lucene成ؓJAKARTA目后，d了太多的旉用于调试日趋复杂QueryParserQ而其中大部分是大多数用户q不很熟悉的Q目前LUCENE支持的语法：
Query ::= ( Clause )*
Clause ::= ["+", "-"] [<TERM> ":"] ( <TERM> | "(" Query ")")
中间的逻辑包括Qand or + - &&||{符P而且q有"短语查询"和针对西文的前缀/模糊查询{，个h感觉对于一般应用来_q些功能有一些华而不实，其实能够实现目前cM于Google的查询语句分析功能其实对于大多数用户来说已经够了。所以，Lucene早期版本的QueryParser仍是比较好的选择?/p>
d修改删除指定记录QDocumentQ?/b>
Lucene提供了烦引的扩展机制Q因此烦引的动态扩展应该是没有问题的，而指定记录的修改也似乎只能通过记录的删除，然后重新加入实现。如何删除指定的记录呢？删除的方法也很简单，只是需要在索引时根据数据源中的记录ID专门另徏索引Q然后利用IndexReader.delete(Termterm)Ҏ通过q个记录ID删除相应的Document?/p>
Ҏ某个字段值的排序功能
lucene~省是按照自q相关度算法（scoreQ进行结果排序的Q但能够Ҏ其他字段q行l果排序是一个在LUCENE的开发邮件列表中l常提到的问题，很多原先Z数据库应用都需要除了基于匹配度QscoreQ以外的排序功能。而从全文索的原理我们可以了解刎ͼM不基于烦引的搜烦q程效率都会D效率非常的低Q如果基于其他字D늚排序需要在搜烦q程中访问存储字D，速度回大大降低，因此非常是不可取的?/p>
但这里也有一个折中的解决ҎQ在搜烦q程中能够媄响排序结果的只有索引中已l存储的docID和scoreq?个参敎ͼ所以，Zscore以外的排序，其实可以通过数据源预先排好序，然后ҎdocIDq行排序来实现。这样就避免了在LUCENE搜烦l果外对l果再次q行排序和在搜烦q程中访问不在烦引中的某个字D倹{?/p>
q里需要修改的是IndexSearcher中的HitCollectorq程Q?/p>
...
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) {
/* 原先QLucenedocID和相应的匚w度score例入l果命中列表中：
* hq.put(new ScoreDoc(doc, score)); // update hit queue
* 如果用doc ?1/doc 代替 scoreQ就实现了根据docID排或逆排
* 假设数据源烦引时已经按照某个字段排好了序Q而结果根据docID排序也就实现?br /> * 针对某个字段的排序，甚至可以实现更复杂的score和docID的拟合?br /> */
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());
更通用的输入输出接?/b>
虽然lucene没有定义一个确定的输入文档格式Q但来多的h惛_使用一个标准的中间格式作ؓLucene的数据导入接口，然后其他数据Q比如PDF只需要通过解析器{换成标准的中间格式就可以q行数据索引了。这个中间格式主要以XMLZQ类似实现已l不?Q?个：
数据? WORD PDF HTML DB other
\ | | | /
XML中间格式
|
Lucene INDEX
目前q没有针对MSWord文档的解析器Q因为Word文档和基于ASCII的RTF文档不同Q需要用COM对象机制解析。这个是我在Google上查的相兌料：http://www.intrinsyc.com/products/enterprise_applications.asp
另外一个办法就是把Word文档转换成textQ?a >http://www.winfield.demon.nl/index.html
索引q程优化
索引一般分2U情况，一U是批量的索引扩展Q一U是大批量的索引重徏。在索引q程中，q不是每ơ新的DOC加入q去索引都重新进行一ơ烦引文件的写入操作Q文件I/O是一仉常消耗资源的事情Q?/p>
Lucene先在内存中进行烦引操作，q根据一定的扚wq行文g的写入。这个批ơ的间隔大Q文件的写入ơ数少Q但占用内存会很多。反之占用内存少Q但文gIO操作频繁Q烦引速度会很慢。在IndexWriter中有一个MERGE_FACTOR参数可以帮助你在构造烦引器后根据应用环境的情况充分利用内存减少文g的操作。根据我的用经验：~省Indexer是每20条记录烦引后写入一ơ，每将MERGE_FACTOR增加50倍，索引速度可以提高1倍左叟?br />
搜烦q程优化
lucene支持内存索引Q这L搜烦比基于文件的I/O有数量的速度提升?br />http://www.onjava.com/lpt/a/3273
而尽可能减少IndexSearcher的创建和Ҏ索结果的前台的缓存也是必要的?br />
Lucene面向全文索的优化在于首次索引索后Qƈ不把所有的记录QDocumentQ具体内容读取出来，而v只将所有结果中匚w度最高的?00条结果（TopDocsQ的ID攑ֈl果集缓存中q返回，q里可以比较一下数据库索：如果是一?0,000条的数据库检索结果集Q数据库是一定要把所有记录内定w取得以后再开始返回给应用l果集的。所以即使检索匹配L很多QLucene的结果集占用的内存空间也不会很多。对于一般的模糊索应用是用不到这么多的结果的Q头100条已l可以满?0%以上的检索需求?br />
如果首批~存l果数用完后q要d更后面的l果时Searcher会再ơ检索ƈ生成一个上ơ的搜烦~存数大1倍的~存Qƈ再重新向后抓取。所以如果构造一个SearcherL1Q?20条结果，Searcher其实是进行了2ơ搜索过E：?00条取完后Q缓存结果用完，Searcher重新索再构造一?00条的l果~存Q依此类推，400条缓存，800条缓存。由于每ơSearcher对象消失后，q些~存也访问那不到了，你有可能惛_l果记录~存下来Q缓存数量保证?00以下以充分利用首ơ的l果~存Q不让Lucene费多次索，而且可以分q行l果~存?br />
Lucene的另外一个特Ҏ在收集结果的q程中将匚w度低的结果自动过滤掉了。这也是和数据库应用需要将搜烦的结果全部返回不同之处?/p>
我的一些尝?/a>Q?/p> Luene的确是一个面对对象设计的典范 q些优点都是非常值得在以后的开发中学习借鉴的。作Z个通用工具包，Lunece的确l予了需要将全文索功能嵌入到应用中的开发者很多的便利?/p> 此外Q通过对Lucene的学习和使用Q我也更深刻地理解了Z么很多数据库优化设计中要求，比如Q?/p> 参考资料： Apache: Lucene Project The Lucene search engine: Powerful, flexible, and free Lucene Tutorial Notes on distributed searching with Lucene 中文语言的切分词 搜烦引擎工具介绍 Lucene作者Cutting的几论文和专利 Lucene?NET实现QdotLucene Lucene作者Cutting的另外一个项目：ZJava的搜索引擎Nutch 关于Z词表和N-Gram的切分词比较
http://jakarta.apache.org/lucene/
Lucene开?用户邮g列表归档
Lucene-dev@jakarta.apache.org
Lucene-user@jakarta.apache.org
http://www.javaworld.com/javaworld/jw-09-2000/jw-0915-Lucene_p.html
http://www.darksleep.com/puff/lucene/lucene.html
http://home.clara.net/markharwood/lucene/
http://www.google.com/search?sourceid=navclient&hl=zh-CN&q=chinese+word+segment
http://searchtools.com/
http://lucene.sourceforge.net/publications.html
http://sourceforge.net/projects/dotlucene/
http://www.nutch.org/ http://sourceforge.net/projects/nutch/
http://china.nikkeibp.co.jp/cgi-bin/china/news/int/int200302100112.html
2005-01-08 Cutting在Pisa大学做的关于Lucene的讲座：非常详细的Lucene架构解说
]]>