Lucene.Net 2.3.1开发介绍 —— 三、索引(三)

原文:Lucene.Net 2.3.1开发介绍 —— 三、索引(三)

3、Field配置所产生的效果

索引数据,简单的代码,只要两个方法就搞定了,而在索引过程中用到的一些类里最简单,作用也不小的就是Field,接下来看看Field的各项设置都会有什么样的效果。

代码 3.1

Code
 1/**//// <summary>
 2/// 索引数据
 3/// </summary>
 4private void Index()
 5{
 6    Analyzer analyzer = new StandardAnalyzer();
 7    IndexWriter writer = new IndexWriter("IndexDirectory", analyzer, true);
 8    AddDocument(writer, "我的祖国", "英语单词");
 9    AddDocument(writer, "祖国万岁", "英语语法");
10    AddDocument(writer, "祖国", "英语单元");
11    AddDocument(writer, "人民", "单词测试");
12    writer.Optimize();
13    writer.Close();
14}
15/**//// <summary>
16/// 为索引准备数据
17/// </summary>
18/// <param name="writer">索引实例</param>
19/// <param name="content">需要索引的数据</param>
20void AddDocument(IndexWriter writer, string title, string content)
21{
22    Document document = new Document();
23    document.Add(new Field("title", title, Field.Store.Yes, Field.Index.TOKENIZED));
24    document.Add(new Field("content", content, Field.Store.YES, Field.Index.TOKENIZED));
25    writer.AddDocument(document);
26}

代码3.1就是准备好的索引过程。运行,然后呢?这里要说到一个工具,luke(lukeall)这是一个java平台下的Lucene索引管理工具。抽空,我实现了一个简单的dotNet版本的,详细请查看 NLuke版本更新信息 。接下来的索引,会用这个软件对索引进行分析。

现在就可以开始调整AddDocument方法中Field实例化时的参数了,看看调整后会对索引造成什么样的影响。这里以title对应的Field为例。

3.1 Field.Stroe选项

这个选项有3个值,下面来分析下效果。

3.1.1 Field.Stroe.Yes

刚好,默认的就是这个。用这选项建完索引,然后用NLuke查看,发现,title这个字段有,而且有8个Term。切换到文档区域,发现文档的title有内容。这个选项表示的就是存储,所以,这些是正常状态。

3.1.2 Field.Stroe.No

title也有8个Term,但是文档中没有字段了。也就是说现在可以用这个字段来搜索,但是搜索结果Hits中,不能用Document实例的Get方法来取得字段的内容了。那就是字段内容没有被存储。

3.1.3 Field.Store.COMPRESS

设置为COMPRESS,报错了,错误信息“Compression support not configured”,是个配置错误。这个错误在SupportClass,CheckCompressionSupport方法被抛出。这里读取了一个配置文件,然后根据配置文件指定的类名来创建实例。这个类必须实现接口 SupportClass.CompressionSupport.ICompressionAdapter。在Lucene.Net中内置了一个“SharpZipLibAdapter”,但是需要有编译符号SHARP_ZIP_LIB才能编译进去。为了看看效果,所以给项目添加SHARP_ZIP_LIB符号,然后增加app.config配置文件,在appseting中添加Lucene.Net.CompressionLib.class键,值是SharpZipLibAdapter。然后下载 ICSharpCode.SharpZipLib.dll,这个dll才是真正实现压缩算法的。下载地址: http://sourceforge.net/project/downloading.php?groupname=sharpdevelop&filename=SharpZipLib_0855_Bin.zip&use_mirror=nchc

把ICSharpCode.SharpZipLib.dll引入项目,就可以使用COMPRESS这个选项了。效果与Yes是一样的。

3.1.4 效果对比

对于Field.Stroe.Yes,产生字节大小是:627字节

Field.Stroe.COMPRESS是:661字节

Field.Stroe.No是:579字节

使用Field.Stroe.COMPRESS反而是占用空间最大,这不符合原先的设想。那是因为我们索引的文本太小,你可以试试看增加索引的内容,再对比小效果。

3.2 Field.Index选项

现在把Field.Stroe设置为Field.Stroe.Yes,接着来看看Field.Index的效果。

3.2.1 Field.Index.TOKENIZED

这个选项是用来控制分词的,TOKENIZED表明需要分词。运行后title有8个Term,没有问题。

3.2.2 Field.Index.UN_TOKENIZED

运行后只有4个Term,而且Term是原先写入的内容,和存储的完整内容没有区别。

3.2.3 Field.Index.NO

和预想的一样,title的Term一个也没有了。

3.2.4 Field.Index.NO_NORMS

效果似乎和Field.Index.UN_TOKENIZED一样,但是它把词条的附加信息全去掉了。比如,它将不再记录词的正太分布数据一类的东西。这样可以减少占用的空间。而且这个用法也有一个条件,就是只要开启,就要全部开启,否则会失效。比如索引了四条数据没使用NO_NORMS,而接下来的两条使用了NO_NORMS,那么前面四条的数据效果,那么接下来的两条数据实际上并没有产生NO_NORMS的效果。

3.2.5 效果分析

1,2,4三种情况虽然不同,但是都可以搜索,而第三种情况,也就是设置为NO,则不可以搜索。第一种情况,可以分词搜索,并且可以排序。而2,4则不能分词搜索,第四种情况不可以排序(不可以排序指,不能按照词出现的频率进行排序)。

从上面也可以看出,假设Field.Store设置为NO,而Field.Index也设置为NO,那就和没添加是一样的了。Field.Store是给你取完整数据用的,而Field.Index则是给搜索用的。在极端的情况下,可以设置Field.Store为NO,而Field.Index可以搜索,等取数据的时候再从数据源(比如数据库),它们中间有个关联法则,那样可以有效的减轻Lucene的工作压力。

3.3 Field.TermVector

Field.TermVector选项,现在工具还没实现这个功能,不过可以自己编码来实现。

代码 3.3.5.1

Code
 1[Test]
 2public void TermVectorTest()
 3{
 4    IndexReader reader = IndexReader.Open("IndexDirectory");
 5    int numDoc = reader.NumDocs();
 6    for (int i = 0; i < numDoc; i++)
 7    {
 8        Console.WriteLine("Doc:#" + i + "----------------------------");
 9        Document doc = reader.Document(i);
10        Field field = doc.GetField("title");
11        Console.WriteLine("是否被索引:" + field.IsIndexed());
12        Console.WriteLine("是否被存储:" + field.IsStored());
13        Console.WriteLine("是否存储开始位置:" + field.IsStorePositionWithTermVector());
14        Console.WriteLine("是否存储结束位置:" + field.IsStoreOffsetWithTermVector());
15        Console.WriteLine("是否保存了向量:" + field.IsTermVectorStored());
16        Console.WriteLine("是否分词:" + field.IsTokenized());
17        Console.WriteLine("--------------------------------------------");
18    }
19    reader.Close();
20}

设置Field.TermVector后,可以用代码3.3.5.1检查效果。你可以自己去试试。

时间: 2024-12-23 07:24:12

Lucene.Net 2.3.1开发介绍 —— 三、索引(三)的相关文章

Lucene.Net 2.3.1开发介绍 —— 三、索引(五)

原文:Lucene.Net 2.3.1开发介绍 -- 三.索引(五) 话接上篇,继续来说权重对排序的影响.从上面的4个测试,只能说是有个直观的理解了.“哦,是!调整权重是能影响排序了,但是好像没办法来分析到底怎么调啊!”.似乎是这样,现在需要把问题放大,加大索引的内容.到博客园新闻区,用zzk找了4篇内容包含“测试”的文章.代码变成 2.1.5 代码2.1.5  1using System;  2using System.Collections.Generic;  3using Lucene.N

Lucene.Net 2.3.1开发介绍 —— 三、索引(四)

原文:Lucene.Net 2.3.1开发介绍 -- 三.索引(四) 4.索引对搜索排序的影响 搜索的时候,同一个搜索关键字和同一份索引,决定了一个结果,不但决定了结果的集合,也确定了结果的顺序.那个这个结果是怎么得出来的?这个顺序又是怎么排的呢?这两个问题不是本节讨论的重点,但是这两个问题却关系到本节要讨论的,索引对结果的影响问题.在不使用字段排序的情况下,Lucene.Net默认是按文档的得分来排序的,这个公式看着很复杂,感觉像是大学时高数书上的那些个公式,其实说清楚了也简单. 关于文档排序

Lucene.Net 2.3.1开发介绍 —— 三、索引(七)

原文:Lucene.Net 2.3.1开发介绍 -- 三.索引(七) 5.IndexWriter 索引这部分最后讲的是IndexWriter.如果说前面提到的都是数据的结构,那么IndexWriter就是业务的封装.无论述Document,Field还是看不见的Segment,Term都是对数据存储逻辑的抽象,IndexWriter包装了操作的过程. 当然,这里不会讨论IndexWriter的每个细节,这里主要介绍IndexWriter的常用法和实际使用中遇到的部署问题. 5.1 IndexWr

Lucene.Net 2.3.1开发介绍 —— 四、搜索(三)

原文:Lucene.Net 2.3.1开发介绍 -- 四.搜索(三) Lucene有表达式就有运算符,而运算符使用起来确实很方便,但另外一个问题来了. 代码 4.3.4.1 Analyzer analyzer = new StandardAnalyzer(); QueryParser parser = new QueryParser("title", analyzer); Query query = parser.Parse(@":"); Console.Write

Lucene.Net 2.3.1开发介绍 —— 三、索引(六)

原文:Lucene.Net 2.3.1开发介绍 -- 三.索引(六) 2.2 Field的Boost 如果说Document的Boost是一条线,那么Field的Boost则是一个点.怎么理解这个点呢?设置Document的Boost会影响所有字段.在搜索的过程中,一般至少会搜索两个Field,比如同时搜索标题和内容.而Document的Boost将同时影响标题和内容的搜索得分,但是设置Field的Boost则不会有那么大的影响,Field的Boost只会影响一个点.那这个点有什么用呢? 现在来

Lucene.Net 2.3.1开发介绍 —— 三、索引(二)

原文:Lucene.Net 2.3.1开发介绍 -- 三.索引(二) 2.索引中用到的核心类 在Lucene.Net索引开发中,用到的类不多,这些类是索引过程的核心类.其中Analyzer是索引建立的基础,Directory是索引建立中或者建立好存储的介质,Document和Field类是逻辑结构的核心,IndexWriter是操作的核心.其他类的使用都被隐藏掉了,这也是为什么Lucene.Net使用这么方便的原因. 2.1 Analyzer 前面已经对Analyzer进行了很详细的讲解,Ana

Lucene.Net 2.3.1开发介绍 —— 三、索引(一)

原文:Lucene.Net 2.3.1开发介绍 -- 三.索引(一) 在说索引之前,先说说索引是什么?为什么要索引?怎么索引? 先想想看,假如现在有一个文本,我们会怎么去搜索.比如,有一个string = "abcdefghijklmnopqrstuvwxyz",这都是26个字母.现在要看看里面是不是有a,用IndexOf就可以很方便实现.现在数据量大了,在数据库里已经有100多条数据了,当然,利用数据库提供的操作方法,也可以很方便的查找.而这里先抛开数据库,把这100多条记录放到N个

Lucene.Net 2.3.1开发介绍 —— 二、分词(三)

原文:Lucene.Net 2.3.1开发介绍 -- 二.分词(三) 1.3 分词器结构 1.3.1 分词器整体结构 从1.2节的分析,终于做到了管中窥豹,现在在Lucene.Net项目中添加一个类关系图,把TokenStream和他的儿孙们统统拉上去,就能比较好的把握他们之间的关系. 图 1.3.1.1 如图1.3.1.1 就是他们的类关系图.看出如果要做一个分词器,最短的路,就是继承第二代,成为第三代.然后再写一个Analyzer的子类,专门用来做新分词器的适配器就好了.转换器.  呵呵,写

Lucene.Net 2.3.1开发介绍 —— 四、搜索(一)

原文:Lucene.Net 2.3.1开发介绍 -- 四.搜索(一) 既然是内容筛选,或者说是搜索引擎,有索引,必然要有搜索.搜索虽然与索引有关,那也只是与索引后的文件有关,和索引的程序是无关的,因此,搜索和索引一般是分开部署.简单地说,就是一个应用程序(桌面程序)来索引,一个WEB程序来实现搜索.当然,为了测试的时候简单,这里还是使用NUnit的方式运行.搜索讲完后,将会简单介绍单机搜索引擎如何部署. 4.1 搜索与什么有关 搜索与什么有关呢?即使没有看过前面的文章,那么现在来随便猜一猜. 首