[Lucene IN ACTION中文版].扫描版[PDF]
推荐阅读：
基本信息中文名:LuceneINACTION中文版作者:(美)(高斯帕那Gospodnetic)(O.)(美)(哈特赫Hatcher)(E.)译者:谭鸿等图书分类:软件资源格式:PDF版本:扫描版出版社:电子工业出版社书号:2发行时间:日地区:大陆语言:简体中文图书简介暂无图书简介……图书目录推荐序译者序前言1前言2致谢关于此书第1部分Lucene的核心第1章初识Lucene1.1信息组织和访问的发展历程1.2理解Lucene1.2.1Lucene是什么1.2.2Lucene能做什么1.2.3Lucene的历史1.2.4使用Lucene的组织1.2.5Lucene移植：Perl、Python、C++、NET及Ruby版本1.3索引和搜索1.3.1什么是索引,为什么如此重要?1.3.2什么是搜索1.4Lucene实践：一个应用实例1.4.1创建一个索引1.4.2搜索一个索引1.5理解索引过程的核心类1.5.1IndexWriter1.5.2Direcory1.5.3Analyzer1.5.4Document1.5.5Field1.6理解搜索过程的核心类1.6.1IndexSearcher1.6.2Term1.6.3Query1.6.4TermQuery1.6.5Hits1.7可选择的同类产品1.7.1信息检索工具库1.7.2索引与搜索应用程序1.7.3在线资源1.8小结第2章索引第3章为应用程序添加搜索功能第4章分析第5章高级搜索技术第6章扩展搜索第2部分Lucene的应用第7章对常用格式的文档进行解析第8章Lucene的相关工具及其扩展第9章Lucene的移植第10章案例分析附录A安装Lucene附录BLucene索引文件格式附录C资源……<
【文明转载，互利你我；原文网址：/ZiLiao/198178，本文版权归90下载所有。】
更多推荐：Lucene in Action（第二版）全面讲述lucene3.0 - 没有最好的，只有最合适的 - ITeye技术网站
博客分类：
此版为图灵的MEAP版本，感兴趣的赶紧下哦……
源代码文件太大，不传了，给个地址：
，最新上传《Lucene in action》英文版正式版
July, 2010 | 532 pages
source code：/hatcher3/LIAsourcecode.zip
下载次数: 3627
下载次数: 2560
下载次数: 2929
下载次数: 5506
浏览 14757
请问楼主，你有中文版吗不好意思，没有呢
谢谢啊 很需要啊！遗憾英文看的有点头疼
但是源代码在你给的地址在哪里啊
怎么联系你。 希望一起探讨lucene3.0
/hatcher3/LIAsourcecode.zip
源码中 SRC 是lucene2.9的吧？
是的， 2.9和3.0差异不大吧
浏览: 42993 次
来自: 北京
感谢楼主分享，不知道楼主知不知道现在有没有最新的版本的教程
return cache.getFromCac ...2600人阅读
Lucene（4）
一. Index之前要做什么
1. 将要index的内容转化为文本
你要处理的文件可能是PDF, word, html, OK通通转化成文本, lucene只能处理文本
2.分析文本
在index之前, 必须对文本做一系列的分析, 对文本的token化, 就是分词. 然后滤掉一些没有区分度的词, 如stop word
这个地方涉及语言相关性. 不同语言的处理会不同. 英文还要处理大小写, 派生词.
这一步对于index非常重要, 所以在lucene中选取和开发合适的analysizor是关键的一步.
3. 写入index
这步就是真正的去做index了,lucene采用的是inverted index, 即倒索引, 现在几乎所有主流的search engine都用的这种索引.
inverted index其实就是问'这个词在哪些文章中出现?', 其实一般书后面附的索引就是倒索引, 会标出关键词在哪些章节中出现.
反之, 一般的index是问'这个文章里有哪些词'.
二. lucene 怎样index文件
1. 创建一个index writer
IndexWriter writer = new IndexWriter(dir, getAnalyzer(), true);
2. 创建文件对象
Document doc = new Document();
doc.add(Field.Keyword(&id&, keywords[i]));
doc.add(Field.UnIndexed(&country&, unindexed[i]));
doc.add(Field.UnStored(&contents&, unstored[i]));
doc.add(Field.Text(&city&, text[i]));
3. 写入文档
writer.addDocument(doc);
writer.optimize();
writer.close();
就这么简单.......
这里面有几点要讲一下,
1. index 储存目录的类型
有两种FSDirectory, RAMDirectory, 由名字可以看出分别是文件系统目录和内存目录
内存目录有两个作用, 最主要是快, 用于实时要求高的索引. 其次是用于测试, 单元测试, 测试完了不会留下任何垃圾文件
书上说&the performance difference between RAMDirectory and FSDirectory is less visible when Lucene is used on operating systems that cache files in memory.&
2. Document 和 Field
对于要index的文档, 首先要生成抽象的document对象, 然后把需要index的内容加到各个fields中去.
Document就是fields的集合, 而fields用来放文档本身和文档的元数据.
field由名字和值组成.
Lucene1.4主要提供下列四种不同类型的Field:
Keyword:不分析, index, 存
UnIndexed:不分析, 不index, 存, 这个用于需要随搜索结果显示的, 本身不算搜索关键词
UnStored:分析, index, 不存, 用于大段文字, 正文
Text:分析, index, 不存(reader)存(string),
在Lucene2.0中是通过三个内部类Field.Index,Field.Store,Field.termVector(项向量)的组合来区分Field的具体类型.具体如下:
PRESS:压缩保存,用于长文本或二进制数据
Field.Store.YES:保存
Field.Store.NO:不保存
Field.Index.NO:不建立索引
Field.Index.TOKENIZED:分词,建索引
Field.Index.UN_TOKENIZED:不分词,建索引
Field.Index.NO_NORMS:不分词,建索引.但是Field的值不像通常那样被保存，而是只取一个byte，这样节约存储空间
Field.TermVector.NO:不保存term vectors
Field.TermVector.YES:保存term vectors
Field.TermVector.WITH_POSITIONS:保存term vectors.(保存值和token位置信息)
Field.TermVector.WITH_OFFSETS:保存term vectors.(保存值和Token的offset)
:保存term vectors.(保存值和token位置信息和Token的offset)
而Field的构造函数也用到了这三个内部类:
Field(String, byte[],Field.Store)
Field(String, Reader)
Field(String, Reader, Field.TermVector)
Field(String, String, Field.Store, Field.Index)
Field(String, String, Field.Store, Field.Index, Field.TermVector)
其中Field(String, Reader)和Field(String, Reader, Field.TermVector)默认为Field.Index.TOKENIZED和Field.Store.NO的.
而对于新老类型可以建立如下对应:
Store.YES,Index.UN_TOKENIZED;
UnIndexed &==&
Store.YES,Index.NO;
Store.NO,Index.TOKENIZED;
Text(String, Reader) &==&
Store.NO,Index.TOKENIZED;
Text(String,String)
Store.YES,Index.TOKENIZED.
这段摘自(/z/blog/item/bf948be4aedbcbf.html)
最新的lucene 3.0的field是这样的:
Field options for indexing
Index.ANALYZED
& use the analyzer to break the Field&s value into a stream of separate tokens and make each token searchable.
Index.NOT_ANALYZED
& do index the field, but do not analyze the String. Instead, treat the Field&s entire value as a single token and make that token searchable.
Index.ANALYZED_NO_NORMS
& an advanced variant of Index.ANALYZED which does not store norms information in the index.
Index.NOT_ANALYZED_NO_NORMS
& just like , but also do not store Norms.
& don&t make this field&s value available for searching at all.
Field options for storing fields
& store the value. When the value is stored, the original String in its entirety is recorded in the index and may be retrieved by an IndexReader.
& do not store the value. This is often used along with Index.ANALYZED to index a large text field that doesn&t need to be retrieved in its original form.
Field options for term vectors
TermVector.YES
& record the unique terms that occurred, and their counts, in each document, but do not store any positions or offsets information.
TermVector.WITH_POSITIONS
& record the unique terms and their counts, and also the positions of each occurrence of every term, but no offsets.
TermVector.WITH_OFFSETS
& record the unique terms and their counts, with the offsets (start & end character position) of each occurrence of every term, but no positions.
TermVector.WITH_POSITIONS_OFFSETS
& store unique terms and their counts, along with positions and offsets.
TermVector.NO
& do not store any term vector information.
If Index.NO is specified for a field, then you must also specify TermVector.NO.
具一些例子来说明这些怎么用
Index&&&&&&&&&&&&&&&&&& Store& TermVector&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Example usage
NOT_ANALYZED&&&& YES&&&&&&&& NO&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Identifiers (file names, primary keys),
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& Telephone and Social Security
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& numbers, URLs, personal names, Dates
ANALYZED&&&&&&&&&&&&& YES & & WITH_POSITIONS_OFFSETS&&& Document title, document abstract
ANALYZED&&&&&&&&&&&&& NO&&&&& WITH_POSITIONS_OFFSETS&&& Document body
NO&&&&&&&&&&&&&&&&&&&&&&&& YES&&&&&&& NO&&&&&&&&&&&&& & & & & & & & & & & & & & Document type, database primary key
NOT_ANALYZED&&&& NO&&&&&&&& NO&&&&&&&&&&&&& & & & & & & & & & & & & && Hidden keywords
When Lucene builds the inverted index, by default it stores all necessary information to implement the Vector Space model. This model requires the count of every term that occurred in the document, as well as the positions of each occurrence (needed for phrase searches).
You can tell Lucene to skip indexing the term frequency and positions by calling:
Field.setOmitTermFreqAndPositions(true)
三. index的一些小技巧
设置document和field的重要性, 默认为1
通过setBoost(1.5)可以更改这个值
既然可以对document和field设置boost值, 那么这些boost值是存在什么地方的了(lucene3.0)?
在index的时候, 对于每个document,每个field都有个floating point的boost值,浮点不便于存储, 占空间, 所以就把这些浮点型的boost值, encoding(quantized)成一个byte的norms来存储.在search的时候, 把这些norms都load到内存里面, 用到的时候再decoding成浮点来计算.
这样有个问题, 就是norms会占用大量的ram, 每个document和field都要一个byte, 对于庞大的index, 这将占用大量的内存.
你可以用这个操作关掉这个boost功能, 如果你觉得这个boost对你的系统并不重要:
Field.setOmitNorms(true)
当然你可以在选择Field index option的时候选ANALYZED_NO_NORMS
2. index dates
可以直接用date类型, 有两个缺点, lucene在index date类型时, 要先转为string, 它会转到直到微秒位,
而一般不用那么精确, 存在performance问题. date类型不能处理1970以前的日期
所以你可以自己把date转成YYYYMMDD形式的string来存
3. index number
index数字也是要先把它转化为string, 对于正文里的数字首先要选合适的analyzer, 如 WhitespaceAnalyzer and StandardAnalyzer
你如果选SimpleAnalyzer and StopAnalyzer, 数字会被滤掉.
而对于存在keyword中的数字, 如果要进行range queries, 必须要对其补0
因为7, 21,71的字典顺序是21,7,71.所以必须补0, 007,021,071, 就可以保证正确的顺序.
4. 对于要排序的field, 要索引但不分词, 即用keyword
四. 提高index 的效率
index的瓶颈主要在写磁盘上, 怎么利用buffer有效的减少磁盘读写的次数是优化的关键.
1. 调节参数
mergeFactor
org.apache.lucene.mergeFactor
控制index的大小和频率,两个作用
maxMergeDocs
org.apache.lucene.maxMergeDocs
Integer.MAX_VALUE
限制一个段中的document数目
minMergeDocs
org.apache.lucene.minMergeDocs
缓存在内存中的document数目，超过他以后会写入到磁盘
maxFieldLength
一个Field中最大Term数目，超过部分忽略，不会index到field中，所以自然也就搜索不到
通常加大mergeFactor, minMergeDocs会大大提高index效率, 但很耗内存, 会导致内存耗尽.
java -server -Xms128m -Xmx256m
同样通过增加JVM的start和maxim的heap时也能提高index效率.
注意操作系统的打开文件数目的上限
在linux, 用ulimit -n来查和修改
lucene一次最多打开这么多文件: (1 + mergeFactor) * FilesPerSegment
感觉不多, 一般不会超
2. In-memory indexing: RAMDirectory
Everything that FSDirectory does on disk, RAMDirectory performs in memory, and is thus much faster.
渐渐增加mergeFactor or minMergeDocs的值, FSDirectory-based indexing starts to approach the speed of the RAMDirectorybased one.
3. Batch indexing by using RAMDirectory as a buffer
优化index的思路, 用参数调节太麻烦效果不好. 而且不好控制, 那么就用这个方法吧
1 Create an FSDirectory-based index.
2 Create a RAMDirectory-based index.
3 Add Documents to the RAMDirectory-based index.
4 Every so often, flush everything buffered in RAMDirectory into FSDirectory.
5 Go to step 3. (Who says GOTO is dead?)
4.Parallelizing indexing by working with multiple indexes
并行的index, 这个策略比较灵活, 可以多个线程并行index到各自RAMDirectory, 然后:
当RAMDirectory达到临界值时, 把index存入统一的index目录.
当RAMDirectory达到临界值时, 把index存入各自的index目录(磁盘),& 有一个进程负责合并所有index到主index
甚至这里的线程可以扩展为computer, 这样可以形成indexing cluster.
五. Index Optimizing
Optimize操作就是把所有的index segments 合并成一个, 合并过程中会占用2倍的磁盘空间, 且有大量的磁盘IO操作.
所以要合理的使用optimize操作, 过于频繁也会带来性能问题.
It&s important to emphasize that optimizing an index only affects the speed of searches against that index, and doesn&t affect the speed of indexing.
因为如果很多segment文件, search需要打开过多的文件, 而浪费时间.
不推荐在indexing的同时, 进行optimize, 最好时index完了以后开始optimize.
六.Concurrency, thread-safety, and locking issues
1. Lucene&s concurrency rules are simple but should be strictly followed:
■ Any number of read-only operations may be executed concurrently.
■ Any number of read-only operations may be executed while an index is being modified.
■ Only a single index-modifying operation may execute at a time.
简单的说可以并行读, 只能串行的写.
2. Thread-safety
IndexWriter or IndexReader are thread-safe. Therefore, a single instance of either class can be shared among multiple threads, and all calls to its index-modifying methods will be properly synchronized so that index modifications are executed
one after the other.
随每个类是线程安全的, 但是注意IndexWriter or IndexReader不能同时去改index
Lucene must ensure that indexmodifying operations of these two classes don&t overlap.
An index-modifying IndexReader operation can&t be executed while an index-modifying IndexWriter operation is in progress
3. Index locking
The write.lock file is used to keep processes from concurrently attempting to modify an index.
The commit.lock is used whenever segments are being read or merged.
七. Debugging indexing
IndexWriter writer = new IndexWriter(dir, new SimpleAnalyzer(),true);
Stream = System.
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：234917次
积分：2058
积分：2058
排名：第15932名
原创：40篇
评论：18条
(1)(5)(3)(1)(2)(5)(3)(1)(4)(2)(2)(1)(1)(1)(4)(1)(1)(2)&&&&&&&&&日，Lucene 4.0正式发布了（），这个版本因为诸多的新特性和大胆的架构调整一直备受期待。无论是索引结构，索引算法以及整体架构的包容性都发生了翻天覆地的变化。正如大家一直所说的&，而4.0的发布则让Lucene向搜索框架的方向迈出了一大步。 下面我们来逐一解读Lucene 4.0的新特性吧。
Lucene 4.0 的关键词：
& & & &架构解耦，索引结构可定制化，索引结构透明化，向搜索框架方向发展。
Lucene 4.0 正式版亮点功能：
& & &一、通过解码器Codec 机制 Lucene 索引格式与Lucene架构解耦，变成了Plugin方式实现，包括：Terms , Postings lists ,Stored 字段,Term Vectors 等都可以以自定义的格式予以支持。
& & & & 正如Mysql支持多种存储引擎一样，现在Lucene也可以了。
& & &二、排序相关的算法与向量空间模型解耦(即Lucene中经典的经典的(TF/IDF)模型)。同时提供：最佳匹配 Okapi BM 25，随机分歧 (Divergence from Randomness&)，语言模型和基于信息量的模型。 不同的算法模型可以组合串联起来使用，这等于完全解放了Lucene的生产力！。
& & &三、新的DocValues类型可以为每个文档提供存储额外的类型数据。类似：PayLoad, 可以在用这个特性自定义排序打分参数。
& & &四、IndexWriter 写入索引到硬盘支持完全并发，之前IndexWriter在应用层能多线程调用，但在写入硬盘的时候还是逐个线程顺序写入的。这对于经常要重建索引的场景，减少了等待索引的时间。
& & &具体图形化的演示，请参考我之前的一片文章：&
& & &五、每个Document的标准化因子 norms 不再局限于一个字节。自定义排序的实现可以使用任何DocValues类型的排序因子。
& & &六、索引结构更加透明化，增加了索引统计机制，利用这些统计信息，Lucene索引内容不再是一个黑匣子了。
& & & & & & 包括： 提供针对term或者Field的token数量，针对某个filed的Posting数量，包含某个field的positing的文档数量。当然有了这些索引统计的数据后，就可以自定义的改进评分机制了。
& & &也就是说以下方法将会成为你的新朋友：
& & &TermsEnum.docFreq()，TermsEnum.totalTermFreq()，Fields.getUniqueTermCount()，Fields.getUniqueFieldCount()
& & & 七、索引term不再局限于UTF-16的字符格式，Lucene 4.0中 term 可以是任何二进制数值(java中的byte数组)。默认情况下文本类term是UTF-8字节方式存储。
& & &八、在搜索时使用Filter效率有大幅提升
& & & 九、针对索引merge线程添加了IO限速机制，减少搜索线程与合并索引线程引起的IO争用现象。
& & & 十、由于架构的解耦，增加了一系列可插拔和可替换的模块，包括：&
& & & &A: 添加编码器codec：针对类 Hadoop DFS 的文件系统提供。
& & & &B: 内存编码器codec：把所有的term和posting放到一个内存中的FST（有限状态机），针对内存型应用提升了搜索速度。
& & & &C: 脉冲编码器codec:主要利用了&Zipf 定律，根据term的频率，把频率达到制定阈值的term以inline的方式存储。
& & & & & & & & & &了解c++ inline 函数的同学，应该知道inline对于提升函数调用速度的威力吧。
& & & &D: 明文编码器codec: Lucene的索引结构为了提升效率，从来都是一个黑匣子。现在这个黑匣子可以以明文的方式存储了。
& & & & & & & & & &很显然这个编码器主要是调试、演示用的。估计很多需要写论文的同学们很乐意使用这个功能。
& & & &E: Bloom编码器codec: 国内很多人把Bloom翻译为布隆，我还是喜欢直接用英文的Bloom。
& & & & & & & & & & 关于什么是Bloom 参考我之前的一片文章：
& & & &F：直接编码器 codec : 由这个名字可以看到，这个编码器是为提升效率用的，主要针对高内存需求类的场景定制的。
& & & G: 块解码器 codec: &使用了一个新的索引结构和压缩模式schema。
& & & 十一、Term 偏移量可以选择与Postings list存储在一起。
& & & 十二、新增AutomatonQuery ，用来返回所有Term匹配有限状态机文章列表
& & & 十三、FuzzyQuery 查询速度提升了100-200倍。
& & & 十四、新增拼写检查器DirectSpellChecker，新的拼写检查器不需要单独的索引，能够直接使用主索引。
& & & 十五、 运行中的内存数据结构优化，包括：term 目录，FiledCache 等。
& & & 以：500万wekipedia数据为例 3.x 索引时需要600M内存，4.x 索引时需要 200M内存。
& & &十六、所有的搜索逻辑现在针对每个segment上工作。IndexReaer 也被完全重构，变成了：Atomic 和 Composite Reader。
& & & & 这个变化比较大，我们知道Lucene在生成索引的时候会先生成小的Segment然后逐渐合并成大的Segment。Lucene的所有结构和组件都是以多个Segment为导向进行设计架构的。为搜索多个Segment需要MultiReader，而多Reader的会导致在搜索TermEnum 或者 Postings 的时候搜索效率的下降。因此新的Reader去掉了MultiReader，以Atomic和Composite Reader 代替。
& & &十七、Lucene 4.0 提供了模块化的API。 以模块化的方式提供了&非结构化信息管理分析器&和&空间信息搜索模块。
相关参考：
阅读(...) 评论()