开发自己的搜索引擎Lucene2.0+Heritrix..doc

开发自己的搜索引擎Lucene2.0+Heritrix 发布日期 – 08/04/2010 DOCUMENT ID: HZ_ RD_MAG_DOC_CONCEPT_0.1 PROJECT: RELEASE: 0.1 FEATURE: Concept Doc SUBSYSTEM: Scenarios DISTRIBUTE TO: MAG team 1.概述 使用lucense进行搜索、排序、过滤和分页，Lucene的分析器，对word,excel,pdf格式文档的处理，Compass搜索引擎框，Lucene分布式和Google Search Api,爬虫Heritrix HTMLParser,DWR内容，最后一个垂直商用企业搜索引擎实例。 Lucene版本历史 2.3.0 2008年1月 更新为2.3.0 　　2.4.0 2008年10月 更新为2.4.0 　　2.4.1 2009年 5月 更新为 2.4.1 　　2.9.0 2009年9月25号 更新为2.9.0 　　2.9.1 2009年11月6号 更新为2.9.1 　　3.0.0 2009年11月25号 更新为3.0.0 　　3.0.1 2010年2月26号 更新为3.0.1 　　3.0.2 2010年6月18号 更新为3.0.2 　　3.0.3 2010年12月3号 更新为3.0.3 　　3.3.0 2011年7月初 更新为3.3.0 　　3.4.0 2011年9月14日 更新为3.4.0 3.5.0 2011年11月26日 更新为3.5.0现在也许是试试Sphinx的时候了：相比Lucene速度更快，有中文分词的支持，而且内置了对简单的分布式检索的支持；由于数据库索引不是为全文索引设计的，因此，使用like %keyword%时，数据库索引是不起作用的，在使用like查询时，搜索过程又变成类似于一页页翻书的遍历过程了，所以对于含有模糊查询的数据库服务来说，LIKE对性能的危害是极大的。如果是需要对多个关键词进行模糊匹配：like%keyword1% and like %keyword2% ...其效率也就可想而知了。 所以建立一个高效检索系统的关键是建立一个类似于科技索引一样的反向索引机制，将数据源（比如多篇文章）排序顺序存储的同时，有另外一个排好序的关键词列表，用于存储关键词==文章映射关系，利用这样的映射关系索引：[关键词==出现关键词的文章编号，出现次数（甚至包括位置：起始偏移量，结束偏移量），出现频率]，检索过程就是把模糊查询变成多个可以利用索引的精确查询的逻辑组合的过程。从而大大提高了多关键词查询的效率，所以，全文检索问题归结到最后是一个排序问题。 由此可以看出模糊查询相对数据库的精确查询是一个非常不确定的问题，这也是大部分数据库对全文检索支持有限的原因。Lucene最核心的特征是通过特殊的索引结构实现了传统数据库不擅长的全文索引机制，并提供了扩展接口，以方便针对不同应用的定制。 Lucene的创新之处： 大部分的搜索（数据库）引擎都是用B树结构来维护索引，索引的更新会导致大量的IO操作，Lucene在实现中，对此稍微有所改进：不是维护一个索引文件，而是在扩展索引的时候不断创建新的索引文件，然后定期的把这些新的小索引文件合并到原先的大索引中（针对不同的更新策略，批次的大小可以调整），这样在不影响检索的效率的前提下，提高了索引的效率。 What Is Apache Lucene? The Apache Lucene? project develops open-source search software, including: Apache Lucene Core? (formerly named Lucene Java), our flagship sub-project, provides a Java-based indexing and search implementation, as well as spellchecking, hit highlighting and advanced analysis/tokenization capabilities. Apache Solr? is our high performance enterprise search server, with XML/HTTP and JSON/Python/Ruby APIs, hit highlighting, faceted search, caching, replic