<![CDATA[jaddy0302]]> http://www.xd-tech.com.cn/blog/ zh-cn PBlog2 v2.4 jaddy0302 http://www.xd-tech.com.cn/blog/images/logos.gif http://www.xd-tech.com.cn/blog/ jaddy0302 http://www.xd-tech.com.cn/blog/default.asp?id=84 <![CDATA[lucene.net系列三]]> jaddy0302@126.com(admin) Mon,10 Nov 2008 14:44:10 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=84 --- index 中本文将进一步讨论有关lucene.NET建立索引的问题:

主要包含以下主题:
1.索引的权重
2.利用IndexWriter 属性对建立索引进行高级管理
3.利用RAMDirectory充分发挥内存的优势
4.利用RAMDirectory并行建立索引
5.控制索引内容的长度
6.Optimize 优化的是什么?

源代码下载

本文将进一步讨论有关Lucene.net建立索引的问题:

索引的权重
根据文档的重要性的不同,显然对于某些文档你希望提高权重以便将来搜索的时候,更符合你想要的结果. 下面的代码演示了如何提高符合某些条件的文档的权重.

比如对公司内很多的邮件做了索引,你当然希望主要查看和公司有关的邮件,而不是员工的个人邮件.这点根据邮件的地址就可以做出判断比如包含@alphatom.com的就是公司邮件,而@gmail.com等等就是私人邮件.如何提高相应邮件的权重? 代码如下:

     public static  String COMPANY_DOMAIN = "alphatom.com";
     Document doc = new Document();
     String senderEmail = GetSenderEmail();
     String senderName = getSenderName();
     String subject = GetSubject();
     String body = GetBody();
     doc.Add(Field.Keyword("senderEmail”, senderEmail));
     doc.Add(Field.Text("senderName", senderName));
     doc.Add(Field.Text("subject", subject));
     doc.Add(Field.UnStored("body", body));

     if (GetSenderDomain().EndsWith(COMPANY_DOMAIN)) 

    //如果是公司邮件,提高权重,默认权重是1.0
           doc.SetBoost(1.5);                      
     else                         //如果是私人邮件,降低权重.
           doc.SetBoost(0.1);

     writer.AddDocument(doc);

不仅如此你还可以对Field也设置权重.比如你对邮件的主题更感兴趣.就可以提高它的权重.   

    Field senderNameField = Field.Text("senderName", senderName);

     Field subjectField = Field.Text("subject", subject);
     subjectField.SetBoost(1.2);
lucene搜索的时候会对符合条件的文档按匹配的程度打分,这点就和google的PageRank有点类似, 而SetBoost中的Boost就是其中的一个因素,当然还有其他的因素.这要放到搜索里再说.

利用IndexWriter 变量对建立索引进行高级管理
在建立索引的时候对性能影响最大的地方就是在将索引写入文件的时候, 所以在具体应用的时候就需要对此加以控制.

在建立索引的时候对性能影响最大的地方就是在将索引写入文件的时候所以在具体应用的时候就需要对此加以控制

IndexWriter属性  

默认值

描述

MergeFactory

10

控制segment合并的频率和大小

MaxMergeDocs

Int32.MaxValue

限制每个segment中包含的文档数

MinMergeDocs

10

当内存中的文档达到多少的时候再写入segment

 

Lucene默认情况是每加入10份文档就从内存往index文件写入并生成一个segement,然后每10个segment就合并成一个segment.通过MergeFactory这个变量就可以对此进行控制.

MaxMergeDocs用于控制一个segment文件中最多包含的Document数.比如限制为100的话,即使当前有10个segment也不会合并,因为合并后的segmnet将包含1000个文档,超过了限制.

MinMergeDocs用于确定一个当内存中文档达到多少的时候才写入文件,该项对segment的数量和大小不会有什么影响,它仅仅影响内存的使用,进一步影响写索引的效率.

为了生动的体现这些变量对性能的影响,用一个小程序对此做了说明.

这里有点不可思议.Lucene in Action书上的结果比我用dotLucene做的结果快了近千倍.这里给出书中用Lucene的数据,希望大家比较一下看看是不是我的问题.

Lucene in Action书中的数据:

% java lia.indexing.IndexTuningDemo 100000 10 9999999 10
Merge factor: 10
Max merge docs: 9999999
Min merge docs: 10
Time: 74136 ms
% java lia.indexing.IndexTuningDemo 100000 100 9999999 10
Merge factor: 100
Max merge docs: 9999999
Min merge docs: 10
Time: 68307 ms
我的数据: 336684128 ms
可以看出MinMergeDocs(主要用于控制内存)和MergeFactory(控制合并的次数和合并后的大小) 对建立索引有显著的影响.但是并不是MergeFactory越大越好,因为如果一个segment的文档数很多的话,在搜索的时候必然也会影响效率,所以这里MergeFactory的取值是一个需要平衡的问题.而MinMergeDocs主要受限于内存.

利用RAMDirectory充分发挥内存的优势

从上面来看充分利用内存的空间,减少读写文件(写入index)的次数是优化建立索引的重要方法.其实在Lucene中提供了更强大的方法来利用内存建立索引.使用RAMDirectory来替代FSDirectory. 这时所有的索引都将建立在内存当中,这种方法对于数据量小的搜索业务很有帮助,同时可以使用它来进行一些小的测试,避免在测试时频繁建立删除索引文件.

在实际应用中RAMDirectory和FSDirectory协作可以更好的利用内存来优化建立索引的时间.

具体方法如下:

1.建立一个使用FSDirectory的IndexWriter

2 .建立一个使用RAMDirectory的IndexWriter

3 把Document添加到RAMDirectory中

4 当达到某种条件将RAMDirectory 中的Document写入FSDirectory.

5 重复第三步

示意代码:
      private FSDirectory fsDir = FSDirectory.GetDirectory("index",true); 

       private RAMDirectory ramDir = new RAMDirectory();

       private IndexWriter fsWriter = IndexWriter(fsDir,new SimpleAnalyzer(), true);
       private IndexWriter ramWriter = new IndexWriter(ramDir,new SimpleAnalyzer(), true);
       while (there are documents to index)
      {
         ramWriter.addDocument(doc);
         if (condition for flushing memory to disk has been met)
         {
           fsWriter.AddIndexes(Directory[]{ramDir}) ;
           ramWriter.Close();          //why not support flush?
           ramWriter =new IndexWriter(ramDir,new SimpleAnalyzer(),true);
         }
     }

这里的条件完全由用户控制,而不是FSDirectory采用对Document计数的方式控制何时写入文件.相比之下有更大的自由性,更能提升性能.

利用RAMDirectory并行建立索引

RAMDirectory还提供了使用多线程来建立索引的可能性.下面这副图很好的说明了这一点.

 

 

甚至你可以在一个高速的网络里使用多台计算机来同时建立索引.就像下面这种图所示.

 

虽然有关并行同步的问题需要你自己进行处理,不过通过这种方式可以大大提高对大量数据建立索引的能力.

 

控制索引内容的长度.

在我的一篇速递介绍过Google Desktop Search只能搜索到文本中第5000个字的.也就是google在建立索引的时候只考虑前5000个字,在Lucene中同样也有这个配置功能.

Lucene对一份文本建立索引时默认的索引长度是10,000. 你可以通过IndexWriter 的MaxFieldLength属性对此加以修改.还是用一个例子说明问题. 

     [Test]
     public void FieldSize()      
     // AddDocuments 和 GetHitCount都是自定义的方法,详见源代码
     {
         AddDocuments(dir, 10);      
         //第一个参数是目录,第二个配置是索引的长度
         Assert.AreEqual(1, GetHitCount("contents", "bridges"))
         //原文档的contents为”Amsterdam has lots of bridges”
         //当索引长度为10个字时能找到bridge
         AddDocuments(dir, 1);
         Assert.AreEqual(0, GetHitCount("contents", "bridges"));
         //当索引长度限制为1个字时就无法发现第5个字bridges
     }

   对索引内容限长往往是处于效率和空间大小的考虑.能够对此进行配置是建立索引必备的一个功能.

Optimize 优化的是什么?

在以前的例子里,你可能已经多次见过writer.Optimize()这段代码.Optimize到底做了什么?

让你吃惊的是这里的优化对于建立索引不仅没有起到加速的作用,反而是延长了建立索引的时间.为什么?

因为这里的优化不是为建立索引做的,而是为搜索做的.之前我们提到Lucene默认每遇到10个Segment就合并一次,尽管如此在索引完成后仍然会留下几个segmnets,比如6,7.

而Optimize的过程就是要减少剩下的Segment的数量,尽量让它们处于一个文件中.

它的过程很简单,就是新建一个空的Segmnet,然后把原来的几个segmnet全合并到这一个segmnet中,在此过程中,你的硬盘空间会变大,因为同时存在两份一样大小的索引.不过在优化完成后,Lucene会自动将原来的多份Segments删除,只保留最后生成的一份包含原来所有索引的segment.

尽量减少segments的个数主要是为了增加查询的效率.假设你有一个Server,同时有很多的Client建立了各自不同的索引,如果此时搜索,那么必然要同时打开很多的索引文件,这样显然会受到很大的限制,对性能产生影响.

当然也不是随时做Optimize就好,如前所述做优化时要花费更多的时间和空间,而且在做优化的时候是不能进行查询的.所以索引建立的后期,并且索引的内容不会再发生太多的变化的时候做优化是一个比较好的时段.

]]> http://www.xd-tech.com.cn/blog/default.asp?id=83 <![CDATA[lucene.net系列二]]> jaddy0302@126.com(admin) Mon,10 Nov 2008 14:29:07 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=83 index 上一详细介绍了有关lucene.NET索引添加删除更新的详细内容.并给出了所有的TestCase供学习参考.

Lucene建立Index的过程:

1.       抽取文本.

   比如将PDF以及Word中的内容以纯文本的形式提取出来.Lucene所支持的类型主要为String,为了方便同时也支持Date 以及Reader.其实如果使用这两个类型lucene会自动进行类型转换.

2.       文本分析.

   Lucene将针对所给的文本进行一些最基本的分析,并从中去除一些不必要的信息,比如一些常用字a ,an, the 等等,如果搜索的时候不在乎字母的大小写, 又可以去掉一些不必要的信息.总而言之你可以把这个过程想象成一个文本的过滤器,所有的文本内容通过分析, 将过滤掉一些内容,剩下最有用的信息.

3.       写入index.

和google等常用的索引技术一样lucene在写index的时候都是采用的倒排索引技术(inverted index.) 简而言之,就是通过某种方法(类似hash表?)将常见的”一篇文档中含有哪些词”这个问题转成”哪篇文档中有这些词”. 而各个搜索引擎的索引机制的不同主要在于如何为这张倒排表添加更准确的描述.比如google有名的PageRank因素.Lucene当然也有自己的技术,希望在以后的文章中能为大家加以介绍.

在上一篇文章中,使用了最基本的建立索引的方法.在这里将对某些问题加以详细的讨论.

1. 添加Document至索引
上次添加的每份文档的信息是一样的,都是文档的filename和contents.

doc.Add(Field.Keyword("filename", file.FullName));
doc.Add(Field.Text("contents", new StreamReader(file.FullName)));

在Lucene中对每个文档的描述是可以不同的,比如,两份文档都是描述一个人,其中一个添加的是name, age 另一个添加的是id, sex ,这种不规则的文档描述在Lucene中是允许的.
还有一点Lucene支持对Field进行Append , 如下:

string baseWord = "fast";
string synonyms[] = String {"quick", "rapid", "speedy"};
Document doc = new Document();
doc.Add(Field.Text("word", baseWord));
for (int i = 0; i < synonyms.length; i++)
    doc.Add(Field.Text("word", synonyms[i]));

这点纯粹是为了方便用户的使用.在内部Lucene自动做了转化,效果和将它们拼接好再存是一样.

2. 删除索引中的文档

    这一点Lucene所采取的方式比较怪,它使用IndexReader来对要删除的项进行标记,然后在Reader Close的时候一起删除.
这里简要介绍几个方法.

[TestFixture]
public class DocumentDeleteTest : BaseIndexingTestCase   // BaseIndexingTestCase中的SetUp方法                                               //建立了索引其中加入了两个Document
{
    [Test]
    public void testDeleteBeforeIndexMerge()
    {
   
        IndexReader reader = IndexReader.Open(dir);  //当前索引中有两个Document

        Assert.AreEqual(2, reader.MaxDoc());   //文档从0开始计数,MaxDoc表示下一个文档的序号

        Assert.AreEqual(2, reader.NumDocs());  //NumDocs表示当前索引中文档的个数 
        reader.Delete(1);                   //对标号为1的文档标记为待删除,逻辑删除
        Assert.IsTrue(reader.IsDeleted(1));         //检测某个序号的文档是否被标记删除
        Assert.IsTrue(reader.HasDeletions());       //检测索引中是否有Document被标记删除
        Assert.AreEqual(2, reader.MaxDoc());        //当前下一个文档序号仍然为2
        Assert.AreEqual(1, reader.NumDocs());       //当前索引中文档数变成1
        reader.Close();                             //此时真正从物理上删除之前被标记的文档
        reader = IndexReader.Open(dir);
        Assert.AreEqual(2, reader.MaxDoc());        
        Assert.AreEqual(1, reader.NumDocs());
        reader.Close();
    }

    [Test]
    public void DeleteAfterIndexMerge()    //在索引重排之后
    {
        IndexReader reader = IndexReader.Open(dir);
        Assert.AreEqual(2, reader.MaxDoc());
        Assert.AreEqual(2, reader.NumDocs());
        reader.Delete(1);
        reader.Close();
        IndexWriter writer = new IndexWriter(dir, GetAnalyzer(), false);
        writer.Optimize();                 //索引重排
        writer.Close();
        reader = IndexReader.Open(dir);
        Assert.IsFalse(reader.IsDeleted(1));
        Assert.IsFalse(reader.HasDeletions());
        Assert.AreEqual(1, reader.MaxDoc());       //索引重排后,下一个文档序号变为1
        Assert.AreEqual(1, reader.NumDocs());
        reader.Close();
    }
}


当然你也可以不通过文档序号进行删除工作.采用下面的方法,可以从索引中删除包含特定的内容文档.

IndexReader reader = IndexReader.Open(dir);
reader.Delete(new Term("city", "Amsterdam"));
reader.Close();

你还可以通过reader.UndeleteAll()这个方法取消前面所做的标记,即在read.Close()调用之前取消所有的删除工作

3. 更新索引中的文档

   这个功能Lucene没有支持, 只有通过删除后在添加来实现. 看看代码,很好理解的.

[TestFixture]
public class DocumentUpdateTest : BaseIndexingTestCase
{
    [Test]
    public void Update()
    {
        Assert.AreEqual(1, GetHitCount("city", "Amsterdam"));
        IndexReader reader = IndexReader.Open(dir);
        reader.Delete(new Term("city", "Amsterdam"));
        reader.Close();
        Assert.AreEqual(0, GetHitCount("city", "Amsterdam"));
        IndexWriter writer = new IndexWriter(dir, GetAnalyzer(),false);
        Document doc = new Document();
        doc.Add(Field.Keyword("id", "1"));

 

        doc.Add(Field.UnIndexed("country", "Netherlands"));
        doc.Add(Field.UnStored("contents","Amsterdam has lots of bridges"));
        doc.Add(Field.Text("city", "Haag"));
        writer.AddDocument(doc);
        writer.Optimize();
        writer.Close();
        Assert.AreEqual(1, GetHitCount("city", "Haag"));
    }

 

    protected override Analyzer GetAnalyzer()
    {
        return new WhitespaceAnalyzer();  //注意此处如果用SimpleAnalyzer搜索会失败,因为建立索引的时候使用的SimpleAnalyse它会将所有字母变成小写.

    }

    private int GetHitCount(String fieldName, String searchString)
    {
        IndexSearcher searcher = new IndexSearcher(dir);
        Term t = new Term(fieldName, searchString);
        Query query = new TermQuery(t);
        Hits hits = searcher.Search(query);
        int hitCount = hits.Length();
        searcher.Close();
        return hitCount;
    }
}

    需要注意的是以上所有有关索引的操作,为了避免频繁的打开和关闭Writer和Reader.又由于添加和删除是不同的连接(Writer, Reader)做的.所以应该尽可能的将添加文档的操作放在一起批量执行,然后将删除文档的操作也放在一起批量执行.避免添加删除交替进行.

]]> http://www.xd-tech.com.cn/blog/default.asp?id=82 <![CDATA[lucene.net系列一]]> jaddy0302@126.com(admin) Mon,10 Nov 2008 14:17:23 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=82 本文介绍了什么是lucene,Lucene能做什么.

如何从一个文件夹下的所有txt文件中查找特定的词?

本文将围绕该个实例介绍了lucene.NET的索引的建立以及如何针对索引进行搜索.最后还将给出源代码供大家学习.

源代码下载

What’s Lucene

Lucene是一个信息检索的函数库(Library),利用它你可以为你的应用加上索引和搜索的功能.

Lucene的使用者不需要深入了解有关全文检索的知识,仅仅学会使用库中的一个类,你就为你的应用实现全文检索的功能.

不过千万别以为Lucene是一个象google那样的搜索引擎,Lucene甚至不是一个应用程序,它仅仅是一个工具,一个Library.你也可以把它理解为一个将索引,搜索功能封装的很好的一套简单易用的API.利用这套API你可以做很多有关搜索的事情,而且很方便.

What Can Lucene Do

Lucene可以对任何的数据做索引和搜索. Lucene不管数据源是什么格式,只要它能被转化为文字的形式,就可以被Lucene所分析利用.也就是说不管是MS word, HTML ,pdf还是其他什么形式的文件只要你可以从中抽取出文字形式的内容就可以被Lucene所用.你就可以用Lucene对它们进行索引以及搜索.

How To Use Lucene --- A Simple Example

示例介绍:

为作为输入参数的文件夹下的所有txt类型的文件做索引,做好的索引文件放入index文件夹.

然后在索引的基础上对文件进行全文搜索.

1.       建立索引

IndexWriter writer = new IndexWriter("index", new StandardAnalyzer(), true);

IndexDocs(writer, new System.IO.FileInfo(args[0]));              

writer.Optimize();

writer.Close();

IndexWriter是对索引进行写操作的一个类,利用它可以创建一个索引对象然后往其中添加文件.需要注意它并不是唯一可以修改索引的类.在索引建好后利用其他类还可以对其进行修改.

构造函数第一个参数是建立的索引所要放的文件夹的名字.第二个参数是一个分析对象,主要用于从文本中抽取那些需要建立索引的内容,把不需要参与建索引的文本内容去掉.比如去掉一些a the之类的常用词,还有决定是否大小写敏感.不同的选项通过指定不同的分析对象控制.第三个参数用于确定是否覆盖原有索引的.

第二步就是利用这个writer往索引中添加文件.具体后面再说.

第三步进行优化.

第四步关闭writer.

 

下面具体看看第二步:

   public static void IndexDirectory(IndexWriter writer, FileInfo file)

         {

              if (Directory.Exists(file.FullName))

              {

                   String[] files = Directory.GetFileSystemEntries(file.FullName);

                   // an IO error could occur

                   if (files != null)

                   {

                       for (int i = 0; i < files.Length; i++)

                       {

                            IndexDirectory(writer, new FileInfo(files[i]));  //这里是一个递归

                       }

                   }

              }

              else if (file.Extension == ".txt")

              {

                   IndexFile(file, writer);

              }

         }

 

         private static void IndexFile(FileInfo file, IndexWriter writer)

         {

              Console.Out.WriteLine("adding " + file);

              try

              {

                   Document doc = new Document();                   

                   doc.Add(Field.Keyword("filename", file.FullName));

                   doc.Add(Field.Text("contents", new StreamReader(file.FullName)));

                   writer.AddDocument(doc);

              }

             

              catch (FileNotFoundException fnfe)

              {

                  

              }

     }

主要就是两个函数一个用于处理文件夹(不是为文件夹建立索引),一个用于真正为文件建立索引.

因此主要集中看一下IndexFile这个方法.首先建立Document对象,然后为Document对象添加一些属性Field.你可以把Document对象看成是虚拟文件,将来将从此获取信息.而Field则看成是描述此虚拟文件的元数据(metadata).

其中Field包括四个类型:

 

Keywork

 

该类型的数据将不被分析,而会被索引并保存保存在索引中.

 

UnIndexed

 

该类型的数据不会被分析也不会被索引,但是会保存在索引.

 

UnStored

 

和UnIndexed刚好相反,被分析被索引,但是不被保存.

 

Text

 

和UnStrored类似.如果值的类型为string还会被保存.如果值的类型Reader就不会被保存和UnStored一样.

 

最后将每一个Document添加到索引当中.

需要注意的是索引不仅可以建立在文件系统上,也可以建立在内存中.

例如

IndexWriter writer = new IndexWriter("index", new StandardAnalyzer(), true);

在第一个参数不是指定文件夹的名字而是使用Directory对象,并使用它的子类RAMDirectory,就可以将索引建立在内存当中.

 

2.       对索引进行搜索

IndexSearcher indexSearcher= new IndexSearcher(indexDir);

Query query = QueryParser.Parse(queryString, "contents",new StandardAnalyzer());

Hits hits = indexSearcher.Search(query);

 第一步利用IndexSearcher打开索引文件用于后面搜索,其中的参数是索引文件的路径.

第二步使用QueryParser将可读性较好的查询语句(比如查询的词lucene ,以及一些高级方式lucene AND .net)转化为Lucene内部使用的查询对象.

第三步执行搜索.并将结果返回到hits集合.需要注意的是Lucene并不是一次将所有的结果放入hits中而是采取一次放一部分的方式.出于空间考虑.

]]> http://www.xd-tech.com.cn/blog/default.asp?id=81 <![CDATA[JAVA 强制数据类型转换]]> jaddy0302@126.com(admin) Mon,10 Nov 2008 14:10:33 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=81 　　 public static void main(String[] args){
　　
　　 short shortvar=0;
　　 int intvar=0;
　　 String stringvar;
　　 float floatvar=9.99f;
　　 double doublevar=99999999.99;
　　 char charvar='9';
　　 String intstring="10";
　　 String floatstring="10.1f";
　　 String longstring="99999999";
　　 String doubleString="99999999.9";
　　 String s1="0";
　　 String s2="abc";
　　 String s3="true";
　　
　　 //1.short-->int
　　 intvar=shortvar;
　　 System.out.println(intvar);

//2.int-->short
shortvar= (short) intvar ;
　　 System.out.println(shortvar);
　　
//3.int->String
　　 intvar=1;
　　 stringvar=String.valueOf (intvar);
　　 System.out.println(stringvar);
　　
　　 //4.float->String
　　 stringvar=String.valueOf (floatvar);
　　 System.out.println(stringvar);
　　
　　 //5. double->String
　　 stringvar=String.valueOf (doublevar);
　　 System.out.println(stringvar);
　　
　　 //6. char->String
　　 stringvar=String.valueOf (charvar);
　　 System.out.println(stringvar);
　　
　　 //7 String->int、float、long、double
　　 int i=Integer.parseInt (intstring);
　　 float f= Float.parseFloat (floatstring);
　　 long lo=Long. parseLong (longstring);
　　 double d=Double. parseDouble(doubleString);
　　 System.out.println(i+"\n"+f+"\n"+lo+"\n"+d);
　　
　　 //8 String->byte、short
　　 byte b=Byte.parseByte(s1);
　　 short sh=Short.parseShort(s1);
　　 System.out.println(b+"\n"+sh) ;
　　
　　 //9 String->char
　　 char a=s2.charAt(0);
　　 System.out.println(a);
　　
　　 //10 String-->boolean
　　 boolean flag=Boolean.getBoolean(s3);
　　 System.out.println(s3);
　　
　　
　　 }
　　}  
]]> http://www.xd-tech.com.cn/blog/default.asp?id=80 <![CDATA[Lucene 2.1研究：文件存储]]> jaddy0302@126.com(admin) Mon,10 Nov 2008 11:25:21 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=80
 

类型名称
 说明
 
Byte
 8 byte
 
UInt32
 32 byte四字节无符号整型，高位优先
 
UInt64
 64byte八字节无符号整型，高位优先
 
VInt
 可变长度整型。0-127单字节，128-16383两字节，类推
 
Chars
 UNICODE字符串
 
String
 写入格式为：VInt，Chars，字符串长度加字符串
 

 

二．           Lucene索引文件

1．  Segments

文件名称：segments_N，N为36进制数。

 

说明：在一个索引目录中，至少存在一个Segments文件，但可索引活动的只会有一个：N值最大的。其他的Segments文件可能为临时文件，一般情况是索引修改进程没有完成。

 

格式：Format，Version，NameCounter，SegCount，<SegName，SegSize，DelGen，HasSingleNormFile，NumField，NormGenNumField，IsCompoundFile>SegCount

Format，NameCounter，SegCount，SegCount，SegSize，NumField：UInt32

Version，DelGen，NormGen：UInt64

SegName：String

IsCompound，HasSingleNormFile：Byte

 

格式说明：Format = SegmentInfos.FORMAT_SINGLE_NORM_FILE = -2；Version当前时间与UTC时间的差值的毫秒数，每次对索引进行修改时会变化；SegName是所有索引生成文件的前缀；SegSize是当前Segment中包含的Document的数量；

 

示例：



FF FF FF FD：FOMAT = -2，UInt32

00 00 01 13 29 30 B6 33：Version = 1181807064627，UInt64

00 00 00 01：NameCount = 1，UInt32

00 00 00 01：SegmentCount = 1，UInt32

02：SegmentNamePrefixLength = 2，VInt

5F 30：SegmentName = “_0”，Chars

00 00 00 01：SegSize = 1，UInt32

FF FF FF FF FF FF FF FF：DelGen = -1，UInt64

01：HasSingleNormFile = 1，Byte

FF FF FF FF：NumField = -1，UInt32

FF：IsCompoundFile = -1，Byte

 

在2.1版本中还会生成segment.gen文件，主要保存了索引计数，格式为：Version（SegmentInfos.LOCKLESS = -2），Generation，Generation。

 

示例：



 

FF FF FF FE：Version = -2，UInt32

00 00 00 00 00 00 00 02：Generation = 2，UInt64

00 00 00 00 00 00 00 02：Generation = 2，UInt64

 

2．  Field Info

文件名称：SegmentName.fnm。

 

说明：保存了所有Field的名称。

 

格式：FieldCount，<FieldName，FieldBits>FieldCount

FieldCount：VInt

FieldName：String

FieldBits：Byte

 

格式说明：

 

示例：



 

01：FieldCount = 1，VInt

04：FieldNamePrefixLength = 4，VInt

49 6E 66 6F：FieldName = “Info”，Chars

01：Bits = 1，Byte

 

3．  Stored Field Index

文件名称：SegmentName.fdx

 

说明：保存了每个Document的Field Data的地址指针

 

格式：<FieldValuesPosition>SegSize

FieldValuesPosition：UInt64

 

格式说明：

 

示例：



 

00 00 00 00 00 00 00 00：FieldValuesPosition = 0，UInt64

 

4．  Stroed Field Data

文件名称：SegmentName.fdt

 

说明：保存了每个Document的需要存储的Field数据。

 

格式：<DocFieldData>SegSize

DocFieldData：FieldCount，<FieldNum，Bits，Value>FieldCount

FieldCount：VInt

FieldNum：Vint

Bits：Byte

Value：String | BinaryValue（取决于Bits）

BinaryValue：ValueSize，<Byte>^ValueSize

ValueSize：VInt

 

格式说明：

 

示例：



 

01：FieldCount = 1，VInt

00：FieldNum = 0，VInt

01：Bits = 1，Byte

17：FieldValuePrefixLength = 23，VInt

49 20 77 72 69 74 65 20 61 20 6C 65 74 74 65 72 20 6C 65 74 74 65 72：Value = “I write a letter letter”，Chars

 

5．  Term Info Index

文件名称：SegmentName.tii

 

说明：保存了所有Term Inofs（.its）文件的索引间隔条目。

 

格式：TIVersion，IndexTermCount，IndexInterval，SkipIntervala，MaxSkipLevels，TermIndices

TIVersion：UInt32

IndexTermCount：UInt64

IndexInterval：UInt32

SkipInterval：UInt32

TermIndeices：<TermInfo，IndexDelta>IndexTermCount

IndexDelta：VInt

 

格式说明：

 

示例：


 

FF FF FF FE：TIVersion = -2，UInt32

00 00 00 00 00 00 00 01：TermCount = 1，UInt64

00 00 00 08：IndexInterval = 128，UInt32

00 00 00 10：SkipInterval = 16，UInt32

00：MaxSkipLevels = 0，Byte

 

6．  Term Infos

文件名称：SegmentName.tis

 

说明：存储了所有Term的信息。

 

格式：TIVersion，IndexTermCount，IndexInterval，SkipIntervala，MaxSkipLevels，TIVersion：UInt32

IndexTermCount：UInt64

IndexInterval：UInt32

SkipInterval：UInt32

MaxSkipLevels：VInt

TermInfos：<Term，DocFreq，FreqDelta，ProxDelta，SkipDelta>TermCount

Term：<PriefixLength，Suffix，FieldNum>

 

格式说明：Term按照字典顺序排序；Term的内容是可以共享的。例如：上一个Term为“bone”，当前Term为“boy”，则当前的Temr的PrefixLength为2，Suffix为“y”。

 

示例：


 

FF FF FF FE：TIVersion = -2，UInt32

00 00 00 00 00 00 00 01：TermCount = 1，UInt64

00 00 00 08：IndexInterval = 128，UInt32

00 00 00 10：SkipInterval = 16，UInt32

00：MaxSkipLevels = 0，Byte

01：TermTextPrefixLength = 1，VInt

69：TermText = “i”，Chars

00：FieldNumber = 0，VInt

01：DocFreq = 1，VInt

00：FreqDelta = 0，VInt

00：ProxDelta = 0，VInt

00：SkipDelta = 0，Vint

 

以下Term类似

 

7：Frequencies File

文件名称：SegmentName.frq

 

说明：

 

格式：

 

格式说明：

 

示例：


 

8. Positions File

文件名称：SegmentName.prx

 

说明：保存了每个Term在Document中的位置集合。

 

格式：

 

格式说明：

 

示例：



 

9.TermVectors Iindex File

文件名称：SegmentName.tvx

 

说明：保存了在.tvd中的文档数据的指针。

 

格式：TVXVersion，<DocumentPosition>NumDocs

TVXVersion：UInt32

DcoumentPosition：UInt64

 

格式说明：

 

示例：



 

00 00 00 02：TVXVersion = 2，UInt32

00 00 00 00 00 00 00 04：DocumentPosition = 4，UInt64

 

 

10.Term Vectors Document

文件名称：SegmentName.tvd

 

说明：

 

格式：TVDVersion，<NumFields，FieldNums，FieldPositions>NumDocs

TVDVersion：UInt32

NumFields：VInt

FieldNums：<FieldNumDelta >NumFields

FieldPosition：VInt

 

格式说明：

 

示例：


 

00 00 00 02：TVDVersion = 2，UInt32

01：NumFields = 1，VInt

00：FieldNumDelta = 0，VInt

04：FieldPosition = 4，VInt

 

11.Term Vectors Field

文件名称：SegmentName.tvf

 

说明：

 

 

格式：TVFVersion，<NumTerms，Position/Offset，TermFreqs>NumFields

TVFVersion：UInt32

NumTerms：VInt

Position/Offset：Byte

TermFreqs：<TermText，TermFreq，Positions/Offsets>NumTerms

TermText：<PrefixLength，Suffix>

PrefixLength：VInt

Suffix：Chars

TermFreq：VInt

Position：<VInt>TermFreq

Offsets：<VInt，VInt>TermFreq

 

格式说明：

 

示例：



 

00 00 00 02：TVFVersion = 2，UInt32

03：NumTerms = 3，VInt

00：

00：

01：TermTextPrefixLength = 1，VInt

69：TermText = “i”，Chars

01：TermFreq = 1，VInt

00：Position/Offset = 0，VInt

06：TermTextPrefixLength = 6，VInt

6C 65 74 74 65 72：TextText = “letter”，VInt

02：TermFreq = 2，VInt

00：Position/Offset = 0，VInt

05：TermTextPrefixlength = 5，VInt

77 72 69 74 65：TermText = “write”，Chars

01：Position/Offset = 1，VInt

 

12.Compound File

文件名称：SegmentName.cfs

 

说明：当采用复合文件建立索引时，所有索引文件会保存在一个.cfs文件内。

 

格式：FileCount，<DataOffset，FileName>FielCount，FileDataFielCount

FielCount：VInt

DataOffset：UInt64

FileName：String

FielData：文件原始数据（raw file data）

 

格式说明：

 

示例：



 

0B：FileCount = 8，VInt

00 00 00 00 00 00 00 A6：DataOffset = 166，UInt64

06：FileNamePrefixLength = 6，VInt

5F 30 2E 66 6E 6D：FileName = “_0.fnm”，Chars

根据文件数据偏移量（DataOffset） 166，可以知道字段信息文件（Field Info）“_0.fnm”的数据存储起始位置在167处。其他文件类]]> http://www.xd-tech.com.cn/blog/default.asp?id=79 <![CDATA[初识 Lucene]]> jaddy0302@126.com(admin) Mon,10 Nov 2008 10:30:20 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=79 Lucene 简介

Lucene 是一个基于 Java 的全文信息检索工具包，它不是一个完整的搜索应用程序，而是为你的应用程序提供索引和搜索功能。Lucene 目前是 Apache Jakarta 家族中的一个开源项目。也是目前最为流行的基于 Java 开源全文检索工具包。

目前已经有很多应用程序的搜索功能是基于 Lucene 的，比如 Eclipse 的帮助系统的搜索功能。Lucene 能够为文本类型的数据建立索引，所以你只要能把你要索引的数据格式转化的文本的，Lucene 就能对你的文档进行索引和搜索。比如你要对一些 HTML 文档，PDF 文档进行索引的话你就首先需要把 HTML 文档和 PDF 文档转化成文本格式的，然后将转化后的内容交给 Lucene 进行索引，然后把创建好的索引文件保存到磁盘或者内存中，最后根据用户输入的查询条件在索引文件上进行查询。不指定要索引的文档的格式也使 Lucene 能够几乎适用于所有的搜索应用程序。

图 1 表示了搜索应用程序和 Lucene 之间的关系，也反映了利用 Lucene 构建搜索应用程序的流程：


图1. 搜索应用程序和 Lucene 之间的关系

索引和搜索

索引是现代搜索引擎的核心，建立索引的过程就是把源数据处理成非常方便查询的索引文件的过程。为什么索引这么重要呢，试想你现在要在大量的文档中搜索含有某个关键词的文档，那么如果不建立索引的话你就需要把这些文档顺序的读入内存，然后检查这个文章中是不是含有要查找的关键词，这样的话就会耗费非常多的时间，想想搜索引擎可是在毫秒级的时间内查找出要搜索的结果的。这就是由于建立了索引的原因，你可以把索引想象成这样一种数据结构，他能够使你快速的随机访问存储在索引中的关键词，进而找到该关键词所关联的文档。Lucene 采用的是一种称为反向索引（inverted index）的机制。反向索引就是说我们维护了一个词/短语表，对于这个表中的每个词/短语，都有一个链表描述了有哪些文档包含了这个词/短语。这样在用户输入查询条件的时候，就能非常快的得到搜索结果。我们将在本系列文章的第二部分详细介绍 Lucene 的索引机制，由于 Lucene 提供了简单易用的 API，所以即使读者刚开始对全文本进行索引的机制并不太了解，也可以非常容易的使用 Lucene 对你的文档实现索引。

对文档建立好索引后，就可以在这些索引上面进行搜索了。搜索引擎首先会对搜索的关键词进行解析，然后再在建立好的索引上面进行查找，最终返回和用户输入的关键词相关联的文档。

Lucene 软件包分析

Lucene 软件包的发布形式是一个 JAR 文件，下面我们分析一下这个 JAR 文件里面的主要的 JAVA 包，使读者对之有个初步的了解。

Package: org.apache.lucene.document

这个包提供了一些为封装要索引的文档所需要的类，比如 Document, Field。这样，每一个文档最终被封装成了一个 Document 对象。

Package: org.apache.lucene.analysis

这个包主要功能是对文档进行分词，因为文档在建立索引之前必须要进行分词，所以这个包的作用可以看成是为建立索引做准备工作。

Package: org.apache.lucene.index

这个包提供了一些类来协助创建索引以及对创建好的索引进行更新。这里面有两个基础的类：IndexWriter 和 IndexReader，其中 IndexWriter 是用来创建索引并添加文档到索引中的，IndexReader 是用来删除索引中的文档的。

Package: org.apache.lucene.search

这个包提供了对在建立好的索引上进行搜索所需要的类。比如 IndexSearcher 和 Hits, IndexSearcher 定义了在指定的索引上进行搜索的方法，Hits 用来保存搜索得到的结果。


一个简单的搜索应用程序

假设我们的电脑的目录中含有很多文本文档，我们需要查找哪些文档含有某个关键词。为了实现这种功能，我们首先利用 Lucene 对这个目录中的文档建立索引，然后在建立好的索引中搜索我们所要查找的文档。通过这个例子读者会对如何利用 Lucene 构建自己的搜索应用程序有个比较清楚的认识。


建立索引

为了对文档进行索引，Lucene 提供了五个基础的类，他们分别是 Document, Field, IndexWriter, Analyzer, Directory。下面我们分别介绍一下这五个类的用途：

Document

Document 是用来描述文档的，这里的文档可以指一个 HTML 页面，一封电子邮件，或者是一个文本文件。一个 Document 对象由多个 Field 对象组成的。可以把一个 Document 对象想象成数据库中的一个记录，而每个 Field 对象就是记录的一个字段。

Field

Field 对象是用来描述一个文档的某个属性的，比如一封电子邮件的标题和内容可以用两个 Field 对象分别描述。

Analyzer

在一个文档被索引之前，首先需要对文档内容进行分词处理，这部分工作就是由 Analyzer 来做的。Analyzer 类是一个抽象类，它有多个实现。针对不同的语言和应用需要选择适合的 Analyzer。Analyzer 把分词后的内容交给 IndexWriter 来建立索引。

IndexWriter

IndexWriter 是 Lucene 用来创建索引的一个核心的类，他的作用是把一个个的 Document 对象加到索引中来。

Directory

这个类代表了 Lucene 的索引的存储的位置，这是一个抽象类，它目前有两个实现，第一个是 FSDirectory，它表示一个存储在文件系统中的索引的位置。第二个是 RAMDirectory，它表示一个存储在内存当中的索引的位置。

熟悉了建立索引所需要的这些类后，我们就开始对某个目录下面的文本文件建立索引了，清单1给出了对某个目录下的文本文件建立索引的源代码。


清单 1. 对文本文件建立索引
package TestLucene;
import java.io.File;
import java.io.FileReader;
import java.io.Reader;
import java.util.Date;
import org.apache.lucene.analysis.Analyzer;
import org.apache.lucene.analysis.standard.StandardAnalyzer;
import org.apache.lucene.document.Document;
import org.apache.lucene.document.Field;
import org.apache.lucene.index.IndexWriter;
/**
 * This class demonstrate the process of creating index with Lucene 
 * for text files
 */
public class TxtFileIndexer {
    public static void main(String[] args) throws Exception{
        //indexDir is the directory that hosts Lucene's index files
        File   indexDir = new File("D:\\luceneIndex");
        //dataDir is the directory that hosts the text files that to be indexed
        File   dataDir  = new File("D:\\luceneData");
        Analyzer luceneAnalyzer = new StandardAnalyzer();
        File[] dataFiles  = dataDir.listFiles();
        IndexWriter indexWriter = new IndexWriter(indexDir,luceneAnalyzer,true);
        long startTime = new Date().getTime();
        for(int i = 0; i < dataFiles.length; i++){
            if(dataFiles[i].isFile() && dataFiles[i].getName().endsWith(".txt")){
                System.out.println("Indexing file " + dataFiles[i].getCanonicalPath());
                Document document = new Document();
                Reader txtReader = new FileReader(dataFiles[i]);
                document.add(Field.Text("path",dataFiles[i].getCanonicalPath()));
                document.add(Field.Text("contents",txtReader));
                indexWriter.addDocument(document);
            }
        }
        indexWriter.optimize();
        indexWriter.close();
        long endTime = new Date().getTime();
        
        System.out.println("It takes " + (endTime - startTime) 
                           + " milliseconds to create index for the files in directory "
                           + dataDir.getPath());        
    }
}
 


在清单1中，我们注意到类 IndexWriter 的构造函数需要三个参数，第一个参数指定了所创建的索引要存放的位置，他可以是一个 File 对象，也可以是一个 FSDirectory 对象或者 RAMDirectory 对象。第二个参数指定了 Analyzer 类的一个实现，也就是指定这个索引是用哪个分词器对文挡内容进行分词。第三个参数是一个布尔型的变量，如果为 true 的话就代表创建一个新的索引，为 false 的话就代表在原来索引的基础上进行操作。接着程序遍历了目录下面的所有文本文档，并为每一个文本文档创建了一个 Document 对象。然后把文本文档的两个属性：路径和内容加入到了两个 Field 对象中，接着在把这两个 Field 对象加入到 Document 对象中，最后把这个文档用 IndexWriter 类的 add 方法加入到索引中去。这样我们便完成了索引的创建。接下来我们进入在建立好的索引上进行搜索的部分。


搜索文档

利用Lucene进行搜索就像建立索引一样也是非常方便的。在上面一部分中，我们已经为一个目录下的文本文档建立好了索引，现在我们就要在这个索引上进行搜索以找到包含某个关键词或短语的文档。Lucene提供了几个基础的类来完成这个过程，它们分别是呢IndexSearcher, Term, Query, TermQuery, Hits. 下面我们分别介绍这几个类的功能。

Query

这是一个抽象类，他有多个实现，比如TermQuery, BooleanQuery, PrefixQuery. 这个类的目的是把用户输入的查询字符串封装成Lucene能够识别的Query。

Term

Term是搜索的基本单位，一个Term对象有两个String类型的域组成。生成一个Term对象可以有如下一条语句来完成：Term term = new Term(“fieldName”,”queryWord”); 其中第一个参数代表了要在文档的哪一个Field上进行查找，第二个参数代表了要查询的关键词。

TermQuery

TermQuery是抽象类Query的一个子类，它同时也是Lucene支持的最为基本的一个查询类。生成一个TermQuery对象由如下语句完成： TermQuery termQuery = new TermQuery(new Term(“fieldName”,”queryWord”)); 它的构造函数只接受一个参数，那就是一个Term对象。

IndexSearcher

IndexSearcher是用来在建立好的索引上进行搜索的。它只能以只读的方式打开一个索引，所以可以有多个IndexSearcher的实例在一个索引上进行操作。

Hits

Hits是用来保存搜索的结果的。

介绍完这些搜索所必须的类之后，我们就开始在之前所建立的索引上进行搜索了，清单2给出了完成搜索功能所需要的代码。


清单2 ：在建立好的索引上进行搜索
package TestLucene;
import java.io.File;
import org.apache.lucene.document.Document;
import org.apache.lucene.index.Term;
import org.apache.lucene.search.Hits;
import org.apache.lucene.search.IndexSearcher;
import org.apache.lucene.search.TermQuery;
import org.apache.lucene.store.FSDirectory;
/**
 * This class is used to demonstrate the 
 * process of searching on an existing 
 * Lucene index
 *
 */
public class TxtFileSearcher {
    public static void main(String[] args) throws Exception{
        String queryStr = "lucene";
        //This is the directory that hosts the Lucene index
        File indexDir = new File("D:\\luceneIndex");
        FSDirectory directory = FSDirectory.getDirectory(indexDir,false);
        IndexSearcher searcher = new IndexSearcher(directory);
        if(!indexDir.exists()){
            System.out.println("The Lucene index is not exist");
            return;
        }
        Term term = new Term("contents",queryStr.toLowerCase());
        TermQuery luceneQuery = new TermQuery(term);
        Hits hits = searcher.search(luceneQuery);
        for(int i = 0; i < hits.length(); i++){
            Document document = hits.doc(i);
            System.out.println("File: " + document.get("path"));
        }
    }
}
 


在清单2中，类IndexSearcher的构造函数接受一个类型为Directory的对象，Directory是一个抽象类，它目前有两个子类：FSDirctory和RAMDirectory. 我们的程序中传入了一个FSDirctory对象作为其参数，代表了一个存储在磁盘上的索引的位置。构造函数执行完成后，代表了这个IndexSearcher以只读的方式打开了一个索引。然后我们程序构造了一个Term对象，通过这个Term对象，我们指定了要在文档的内容中搜索包含关键词”lucene”的文档。接着利用这个Term对象构造出TermQuery对象并把这个TermQuery对象传入到IndexSearcher的search方法中进行查询，返回的结果保存在Hits对象中。最后我们用了一个循环语句把搜索到的文档的路径都打印了出来。好了，我们的搜索应用程序已经开发完毕，怎么样，利用Lucene开发搜索应用程序是不是很简单。



总结

本文首先介绍了 Lucene 的一些基本概念，然后开发了一个应用程序演示了利用 Lucene 建立索引并在该索引上进行搜索的过程。希望本文能够为学习 Lucene 的读者提供帮助。]]> http://www.xd-tech.com.cn/blog/default.asp?id=78 <![CDATA[中文全文检索的实现以及一些经验]]> jaddy0302@126.com(admin) Wed,05 Nov 2008 11:35:43 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=78 1 支持中文、英文字词的全文检索，待检索文本是古文言文。
2 全文检索表达式支持： AND,OR,NOT,NEAR,BEFORE 运算符，支持()。
3 速度要求：400M文本，要求在2-5秒内能够检索完毕。

尝试Lucene以及放弃原因：
在尝试Lucene和不同的中文Analyzer后，终告放弃。
原因如下：
由于待检索文本是古文，中文分词技术无法派上用场。在将分隔存储每个汉字后，发现从Lucene中检索到的文本远远少于关键字实际匹配的文本，这一问题对于较长的检索关键字尤其明显。
因为对于检索准确程度要求很高，故此放弃，但是Lucene出的这个问题的原因尚不清楚，希望能够有人提出解答。


自行实现中文全文检索原理以及方法：
1 构建过程，忽略标点符号，自行计算每个汉字在每个文本文件中的偏移量，并保存。
2 检索过程，定位每个汉字的偏移量，如果检索表达式中每个汉字的预期偏移量与实际偏移量吻合，则匹配成功。
3 采用 MappedByteBuffer 加快检索速度，采用二分查找加快偏移量匹配速度，3个左右的关键字复合检索能够在3-5秒内完成匹配（要求操作系统有足够大的缓存）。

全文检索代码示例(TestFullTextQuery.java)：
File storeDir = new File("C:\\temp\\fulltext\\index");
StoreSearcher searcher = new StoreSearcher(storeDir);
String str = "大?藏 & 阿难"; //同时出现 "大?藏" 和 "阿难"， ?代表任意字符
searcher.queryBegin(str, true);
while(true){
    StoreSearcherResult ssr = searcher.getNextQueryResult();
    if ( ssr == null ){
        break;
    }
    System.out.println("ID "+ssr.docId+":"+ssr.matchedCount);
}
searcher.queryEnd();
searcher.close();

运行结果
ID T01n0001.TXT:320
ID T01n0002.TXT:3
ID T01n0004.TXT:2
ID T01n0005.TXT:202
ID T01n0006.TXT:131
....

附：全文检索表达式举例

关键字中间可以出现?，表明匹配任意字符。

运算符名称：运算符字符
AND:&
or:,
BEFORE:*
NEAR:+
NOT:-

表达式举例：
(KEY1 <AND|OR|BEFORE|NEAR> KEY2) & (NOT KEY3)
KEY1 KEY2 (关键字之间无运算符假设为AND)



附：全文检索文件格式信息

DocInfoStore(文档信息)
--HEAD--
DocCount:Integer                    文档数目
--DOC HEAD(PER DOC)--
DocSeq:    Integer                        文档顺序号，内部使用
DocId:     Char[128]                    文档唯一ID，字符串格式
DocSepOfs: Integer                文档分隔符数组的Ofs
--DOC SEP OFS(PER DOC)--
DocOfs:    ArrayOfInteger        文档分隔数组


WordInfoStore(每个汉字信息)
--HEAD--
WordCount:Integer                    汉字数
--WORD IDX(Per Word)--
WordChar:Integer                    汉字的Unicode值
WordInfoOfs:Integer                汉字信息在文件中的偏移量
WordInfoSize:Integer            汉字信息大小
--WORD INFO(Per Word)--
DocCount:                                    汉字出现的文档数
DocSeq(Per Doc):                  每个文档的顺序号
WordInDocs:ArrayOfInteger 每个文档中出现的汉字的偏移数组，从小到大排列

源码下载地址:http://www.blogjava.net/Files/zhugf000/foreader2_ftsearch.zip]]> http://www.xd-tech.com.cn/blog/default.asp?id=77 <![CDATA[浅谈图片搜索引擎的实现]]> jaddy0302@126.com(admin) Wed,15 Oct 2008 17:34:20 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=77 http://minidx.com勉强还能算得上一点“领域”吧。呵呵，无所谓了，随便涂鸦吧……OODA SAN说他在研究图片搜索引擎，所以就和他探讨了一些图片搜索的实现的问题，这里也记录一下自己的思路，OODA是这方面的专家，而我只能算是“新手上路”，下面说的有什么不对的还望包涵指出，：）

简单的说，图片搜索是搜索引擎针对网络上的图片所提供的服务。包括Google, Yahoo!, Ask, MSN和AOL以及国内的Baidu这些大型搜索引擎都提供有图片搜索，还有号称图片搜索专用的picsearch，但它们并非真正地对文件中的图像进行搜索，而是对附加在图片中的文字（比如img标签的alt属性）以及文件名进行搜索，也就是通常意义上的关键字索引，所以实质上用的还是基于文本内容的检索，因此也只能搜索数量较少的文件，IBM 公司的研究人员也曾经开发一种名为Marvel的可以实现音像资料搜索的搜索引擎，它能够获取目前在互联网上很难获取的音像资料，只是没有关注过目前的进展。目前微软也正在研究可以通过头像来查找某人的信息这样的搜索引擎，微软将之成为Photo2Search，“a picture is worth a thousand words”，真正意义上的多媒体搜索引擎的实现，带给人们的影响，将可以与蒸汽机，电脑相媲美……


也许有人不明白图片搜索能给我们带来什么

当你看到了一种植物，但是不知道叫什么名字及其相关信息……

当你有一张某酒店的照片但是不知道这一酒店的信息……

当你看到某张照片上美丽的风光是你很向往的但是却偏偏没有相关的介绍……

当摄像头拍下了某“坏蛋”的面孔但是却没有人认识这个人……

当你看到上面的美女却压根找不到一点相关的信息……

对于这些问题，用google的图片搜索，可以吗？baidu能够告诉你答案吗？虽然Google 图片搜索的时候，在搜索结果页面的网址后面加入&imgtype=face这个参数，即可将图片类型限定为人脸，但是很显然，这样的技术并不能帮助我们解决上面那些问题。而这些需求却是一直都存在的，那么能够帮我们解决这些问题的真正意义上的多媒体（注：不仅仅是图片，其实包括声音文件，影像文件等）搜索引擎应该如何去实现？下面是我所能想到的几种方案

●统一多媒体文件的存储格式。不管是BMP,JPG,GIF……还是MP3,RM，AVI……在生成这样的文件的时候都必须添加必要的文本信息，以特有的结构体存储。这样输入一张图片进行查询的时候，搜索引擎需要的只不过是去解析这一图片的信息，抽取关键字进行查询就可以了。但是，这个世界，是没有想象中那么理想的，否则也不会存在中文，英文，法语，日语……也不会有东方神仙与西方大神了……要制定这样的标准，不是google，yahoo这样的公司可以做到的，也不是美国，中国可以做到的。所以这只能说是镜中水月……无法实现的，就当时我心中的一个美丽的肥皂泡吧。

●提取事物特有的信息对搜索引擎进行训练。研究过搜索引擎的朋友们应该知道，中文分词不同于英文分词，英文可以按照空格来划分单词，但是中文却是连成一片的。所以为了提高中文分词的准确率，通常会准备大量的语料对其进行训练。而有用3D Max之类工具建模经验的朋友们应该知道，在构造某一事物的时候，最先需要对这一事物的特征进行分析，确定好坐标，然后进行构造。不管后面用什么场景来渲染，所建的模都是一样的。比如茶壶，有自己特有的曲线，还有人的脸，一些坐标是相对固定的，不管这个人是年轻，还是变老，这些特征都是无法改变的。所以如果可以采集到足够的“语料”，对搜索引擎进行训练，那么随着训练的进行，搜索引擎认识的东西也就不断的增加，能够提供给我们的信息帮助我们解决的问题也就越来越多。这个和早期的文本搜索引擎应该是一样的。

●对多媒体文件的内容进行分析索引。这种方式是OODA告诉我他正在研究的，大体思路是这样的，比如BMP位图，实际上是以比特流，也就是位的方式存储的，某一类物质，比如说rose，实际上内部的很多比特流都是有一定特征的，这个和通常意义上的文本分类很像，先根据大的特征进行大的分类，然后范围逐步缩小，最终确定目标。不过这个所需要的知识面太过于广泛，至少我无法分析出两张rose图片的相似比特流，希望OODA能够带来一个惊喜吧。

各大搜索引擎公司目前都在投入大量的资金研究这样的搜索引擎，我的Minidx是基于文本的搜索引擎，而我本身对图片之类的比较“白痴”，所以也只能写这么些废话，来贻笑大方了。：）]]> http://www.xd-tech.com.cn/blog/default.asp?id=76 <![CDATA[搜索引擎之排序技术分析]]> jaddy0302@126.com(admin) Wed,15 Oct 2008 17:25:38 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=76
所谓的排序技术，我们可以简单的理解为曝光率，谁出现的次数最多，谁排在前面。要谈到排序技术，就不得不说Google的PageRank，而提到PageRank，则我们需要先来了解一下一种称为HillTop的排序算法。


PageRank技术：通过对由超过 50,000 万个变量和 20 亿个词汇组成的方程进行计算，PageRank能够对网页的重要性做出客观的评价。PageRank 并不计算直接链接的数量，而是将从网页 A 指向网页 B 的链接解释为由网页 A 对网页B 所投的一票。这样，PageRank 会根据网页 B 所收到的投票数量来评估该页的重要性。 

PageRank的思想，链接的重要度整体加重了网站的权重，而网站的权重又反过来影响内部链接的排名。而HillTop算法（也被称为“专家系统”，由Krishna Bharat和George A. Mihaila提出），则是以Dan Thiesw为首的TSPR(Topic-Sensitive-PageRank：主题性页面级别技术)理论。相比PageRank算法，HillTop更强调了内容的相关性，也就是我们常说的“粘性”，“黏度”，而非网站权重，这样避免了可能转贴的权重较高的站点（比如门户站点）比原创作者站点排名还要靠前的问题。那么，到底

什么是Hilltop算法 

Bharat提出：在利用”页面等级”来寻找”权威”网页时，不应单纯依赖于值的大小来定夺，而应将重点放在它与查询主题的相关性上；即不但需要考虑网页的页面等级，还要考虑该网页的页面等级与查询主题的相关性是否相称。若一个网页只与查询主题只沾点边，那么即使其页面等级非常之高，对用户来说也是没有意义的。如此一来，于网页而言，那些来自于”相关主题”的文档的链接就更有意义了 (Bharat称这种”相关主题”文档为”专家文档”)，一个网页的所有外部”专家文档”链接构成了该网页的”权威性值”。Hilltop算法的意义在于：相同主题网站之间的链接应比非相关网站的链接具有更高的价值。 

其实GOOLE早在几年前已经开始混合使用HiilTop和PageRank算法共同确定搜索结果排名了，通过HiilTop的方法，计算来自描述相同主题的相关文档的链接对于搜索者的价值会更大（即相同主题网站之间的链接比不相关网站的链接价值要更大），正是由于HiilTop的影响，这也是我们看到即使各项指标（被收录链接数量，反向链接，访问量等）都非常不错的门户类网站PR很难达到7以上，而专业性的站点却非常容易就达到7，甚至有一大批的都达到了9（注：这里的PR指的是Google综合结果通过Google 工具条显示的结果，而并非上面的PageRank值）。

Hilltop算法的不足 

●Hilltop的前提是每个专家文件都是完全公正的，且无欺骗和人工操纵成分。专家文件的一个小小污点就可以对排名产生极大的负面影响。 

●运行Hilltop算法需要大量的计算机处理能力，像Google的成千上万台服务器集群可以轻松的实现，但是对于一般的企业级用户，服务器就未必具有这样的处理能力。 

排名所采用的相关技术 

●词干技术(stemming) 

Google等各搜索引擎中，目前都已经采用了词干技术(stemming) 。最早的搜索引擎，如果搜索一个单数查询条件如”live”，则搜索结果中不会出现如”lives”，”living”这样的关键词变化形式，反之亦然。对于搜索引擎的用户来说，这种特性是一件好事情，因为搜索提供的结果更多了，但站在搜索引擎商业用户来说，那就意味着需要多购买一些关键词，这个也体现了技术的进步在商业中的价值。 

●拼写纠错 

拼写检查和上面的词干技术一样，也已经被应用于搜索结果中。例如，当输入查询条件为”Search Engine Optimisation”后，以往Google只会提示你是否是要找”Search Engine Optimization”，但显示的还是符合”Optimisation”的搜索结果。不过现在则能看到”Optimization”的搜索结果。 

这两项处理其实都是在分词阶段完成的。  

排名的商业价值

排名在商业中的价值，在互联网蓬勃发展的今天，已经得到了充分的体现。2003年Google大规模调整算法的时候就引来了种种传言和猜测 ： 

开始使用词典对号入座； 
意图施压使商业站点使用Adwords广告服务； 
开始使用”基于贝叶斯定理的SPAM过滤系统” ； 
开始处罚互惠链接，”优化”网页，或”链接文本” ； 
众多猜测中，”Google意图施压使商业站点使用Adwords广告服务”显然占了上风。许多搜索引擎优化分析家都认为：Google通过一个保密的过滤系统”黑名单”来对商业网站进行筛选，从而达到上述目的。虽然这都紧紧是一些猜测，但是这样的传言和猜测，恰恰反应了排名的重要商业价值。
参考资料：
・The Google Hilltop Algorithm
http://www.rankforsales.com/search-engine-algorithms/google-hilltop-algorithm.html
・Hilltop: A Search Engine based on Expert Documents
ftp://ftp.cs.toronto.edu/pub/reports/csri/405/hilltop.html]]> http://www.xd-tech.com.cn/blog/default.asp?id=75 <![CDATA[使用Netbeans开发搜索引擎Nutch]]> jaddy0302@126.com(admin) Wed,15 Oct 2008 17:04:44 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=75
　　Nutch 是一个开源的、Java 实现的搜索引擎。它提供了我们运行自己的搜索引擎所需的全部工具。Nutch致力于让每个人能很容易, 同时花费很少就可以配置世界一流的Web搜索引擎. 为了完成这一宏伟的目标, nutch能够做到: 每个月取几十亿网页; 为这些网页维护一个索引; 对索引文件进行每秒上千次的搜索; 提供高质量的搜索结果; 以最小的成本运作. 

　　测试环境： 

　　Nutch release 0.9 

　　Netbean5.5.1 中文版 

　　Java 1.6 

　　Ubuntu 7.10 

　　步骤: 

　　1.安装：Nutch 

　　下载 Nutch 0.9 的压缩包并解压 

　　（下载地址：http://apache.mirror.phpchina.com/lucene/nutch/） 

　　按照教程进行安装 

　　(教程地址: http://wiki.apache.org/nutch/NutchTutorial) 

　　2.在Netbeans中创建项目 

　　启动Netbeans5.5.1； 

　　创建过程：文件-＞新建项目-＞常规； 

　　选择“基于现有源代码的Java项目”-＞下一步，选择项目名称和项目文件夹，可以根据自己的需要自行指定； 

　　选择下一步，点击“源包文件夹”文本框右边的“添加文件夹”按钮，浏览文件目录选择Nutch安装目录下的src文件夹； 

　　点击完成，此时工程已经建立，当需要对项目进行配置才能实现代码的调试； 

　　在左边的“项目”导航窗口中，选择库包，点击右键，选择属性，此时弹出项目属性配置窗口 

　　选择配置“库”，点击按钮“添加JAR/文件夹”，添加Nutch安装目录下的 "conf"目录以及nutch-0.9.jar包； 

　　继续将Nutch安装目录下“lib”和“plugin”文件夹中的所有JAR包添加进来，此处比较麻烦，因为Netbeans不能自动扫描到文件夹下所有的JAR包，必须手工将其添加进来。 

　　最后需要添加两个JAR包，这两个包分别是解析MP3和RTF文档的，因为license的不兼容性，它们从代码中分离了，你可以在如下地址下载： 

http://nutch.cvs.sourceforge.net/nutch/nutch/src/plugin/parse-mp3/lib/ 

http://nutch.cvs.sourceforge.net/nutch/nutch/src/plugin/parse-rtf/lib/ 

　　下载后将其分别放至src/plugin/parse-mp3/lib和src/plugin/parse-rtf/lib/目录下，同时像添加其他JAR包一样，将其添加至“编译时库”中。此时，您可以选择左方“项目”导航窗口中的项目图标，点击右键，选择“生成项目”，项目应该能正确通过编译。您还需要对Nutch进行配置以调试Nutch的爬行代码。 

　　3.配置 Nutch 

　　在Nutch安装目录下，找到文件/conf/nutch-defaul.xml， 将其 "plugin.folders" 属性值改为"Nutch安装目录/src/plugin" 

　　4.在Nutch中运行Nutch爬虫 

　　选择左方“项目”导航窗口中的项目图标，点击右键，选择“属性”，在左方类别窗口中选择“运行”，对运行参数进行配置 

　　主类： 选择 org.apache.nutch.crawl.Crawl 

　　参数： 填入 urls -dir crawl -depth 3 -topN 50 

　　VM选项：填入 -Dhadoop.log.dir=logs -Dhadoop.log.file=hadoop.log 

　　点击“确定”按钮退出 

　　选择左方“项目”导航窗口中的项目图标，点击右键，选择“运行项目” 

　　注:对于Ubuntu来说，可能由于权限的问题导致不能正常调试，可以在用户和组管理中设置当前用户的组为ROOT组。
]]> http://www.xd-tech.com.cn/blog/default.asp?id=74 <![CDATA[基于Lucene/XML的站内全文检索解决方案：WebLucene]]> jaddy0302@126.com(admin) Wed,15 Oct 2008 16:52:08 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=74 为Lucene做一个通用XML接口一直是我最大的心愿：更方便的在WEB应用中嵌入全文检索功能

提供了XML的数据输入接口：适合将原有基于各种数据库的数据源导入到全文索引中，保证了数据源的平台无关性； 
通过了基于XML的搜索结果输出：方便了通过XSLT进行前台的结果显示； 
    MySQL  \                                                  / JSP        oracle - DB      -  ==>   XML ==> (Lucene Index) ==> XML  -  ASP        MSSQL  /                                                  -  PHP                         MS Word /                                        \         / XHTML                 PDF /                                         =XSLT=> -  TEXT                                                                        \ XML                                                                                                     \_________WebLucene__________/ 使用过程如下：将数据用脚本导出成XML格式； 
将XML数据源导入LUCENE索引； 
从WEB界面得到XML结果输出，并通过XSLT生成HTML页面

站内全文检索的必要性
虽然大型搜索引擎的功能已经越来越强大了，很多站点都使用了Google的站内检索site:domain.com代替了自己的站内数据库“全文”检索。 但依靠GOOGLE这样的大型搜索引擎做站内检索会有以下弊端：

数量有限：搜索引擎并不会深度遍历一个网站，而将网站所有的内容都索引进去，比如Google就喜欢静态网页，而且是最新更新的，而不喜欢带?的动态网页，Google甚至会定期将缺少入口的网站内容逐渐抛弃； 
更新慢：搜索引擎针对站点的更新频率也是有一定周期的，很多内容需要一定时间后才能进入GOOGLE的索引：目前Google Dance的周期是21天左右； 
内容不精确：搜索引擎需要通过页面内容提取技术将导航条，页头页尾等内容过滤掉，反而不如直接从后台数据库提取数据来得直接，这种摘要和排重机制是很难实现的； 
无法控制输出：也许有更多的输出需求，按时间排序，按价格，按点击量，按类目过滤等 
系统的搭建
下载：
http://sourceforge.net/projects/weblucene/

XML数据源的导入：

只要数据源可以导出成3层的XML结构，就都可以用IndexRunner这个命令行工具导入：

比如从数据库导出：news_dump.xml
<?xml version="1.0" encoding="GB2312"?>
<Table>
    <Record>
        <Title>标题</Title>
        <Author>作者</Author>
        <Content>内容</Content>
        <PubTime>2003-06-29</PubTime>       
    </Record>
    <Record>
        <Title>My Title</Title>
        <Author>chedong</Author>
        <Content>abc</Content>
        <PubTime>2003-06-30</PubTime>
    </Record>
    ...
</Table>

IndexRunner -i news_dump.xml -o c:\index -t Title,Content -n Author 
-i news_dump.xml:  以news_dump.xml为数据源
-o c:\index   索引库建立在c:\index目录下
索引建立Title Author Content PubTime这几个字段外，按以下规则建立索引：
-t Title,Content 一个进行分词的全文索引TokenIndex：数据是Title Content这2个字段
-n Author    一个不分词的索引：NoTokenIndex：数据源是Author这个字段。

对于RSS数据源：
<?xml version="1.0"?>
<rss version="0.92">
<channel>
  <title>Amazon: Books Arts &amp; Photography</title>
  <link>http://www.lockergnome.com/</link>
  <description>Amazon RSS Feed</description>
  <lastBuildDate>Sun, 29 Jun 2003 01:05:01 GMT</lastBuildDate>
  <docs>http://www.lockergnome.com/</docs>
  <webMaster>amazonfeed@lockergnome.com (Lockergnome RSS Generator)</webMaster>
  <item>
    <title>The Artist's Way: A Spiritual Path to Higher Creativity - $11.17</title>
    <link>http://www.amazon.com/exec/obidos/ASIN/1585421464/lockergnomedigit/?ref=nosim&amp;dev-it=D34HUVGKB34YFX</link>
    <description>http://www.lockergnome.com/    </description>
  </item>
  ...
</channel>

IndexRunner -i http://www.example.com/rss.xml -o c:\index -t title,description -n link  -l  4
-l 4 表示拿第4层节点作为字段映射，

IndexRunner还提供了-a -m这两个选项：用于增量索引和批量索引优化。
-a  增量索引，表示在原有索引的基础上扩展
-m  mergeFactor 在Lucene中mergeFactor是一个针对批量索引的优化参数，控制多少条处理完多少条记录（Document）后，写入一次索引，写入频率越高，内存使用越少，但索引速度越慢，所以在大批量数据导入时需要增大文件写入的间隔，多让索引在内存中操作。

搜索结果输出：


以下是系统设计过程中一些设计的思路：

做为工业标准的XML
记得以前有关于肯德基的炸薯条断顿的报道。从这个事件报道中我们可以看到一种更高效的管理体系：对于快餐店这样全球性的企业来说，要保证各地提供的薯条品质，成本最低的方法肯定是依靠机器而不是厨师，如果要求薯条机能够处理各种形状不一的土豆，机器的复杂程度和维护成本都会很高。所以土豆必须严格符合工业标准才能让结构比较简单的薯条机生产出符合标准的薯条，因此，薯条的加工机械会严格按照土豆协会的土豆工业标准设计。高质量的原料可以大大降低后期加工设备的成本，因此从总体成本上讲还是合算的。 
对于软件应用开发者来说：应用和应用之间，企业和企业之间交换的数据好比就是土豆，白菜，按照严格的XML标准设计的接口作为企业之间后台数据交换的工业标准，虽然不如简单的CSV格式高效，但缺能大大简化下游工序的后期加工成本。


不难想象为什么处理HTML的浏览器：IE和Mozilla等浏览器软件大小都在10M以上，但一般处理XML的解析器一般都在几百K。除了没有界面外，HTML浏览器需要为太多不规范的HTML代码提供大量容错处理也是一个很重要的原因，而语法严格，规则简单的XML处理器就可以做的很简短，高效，体积越“小”就意味着适应性越广：这点在手机这样的硬件配置比较低的设备环境中显得尤其重要。

虽然XML在后台数据交换方面，有着巨大的潜力。在前台表现方面，XML并不会马上代替HTML，很多通过XSLT输出的HTML仍然需要结合CSS来进行表现。XML ==XSLT==> HTML + CSS。但是由于太多的网页都是用HTML做的，相信XML没有必要马上代替这些已有的机制。

此外在应用的国际化支持方面XML和Java简直是绝配：XML数据源用Java解析后是UNICODE，这样无论是日文，繁体中文还是德文的内容我们都可以在一个索引库中同时进行搜索。这样针对其他语言的支持只是设计各种语言界面的问题了。

      GBK          \                                       / BIG5      BIG5          -  UNICODE        ====>       Unicode -  GB2312      SJIS          -   (XML)                     (XML)   -  SJIS      ISO-8859-1   /                                       \ ISO-8859-1使用XML的另外一个额外好处在于：开发人员一般都没有仔细理解Java的字符集（其实上是JVM的缺省file.encoding属性）受系统本地化设置的影响，基于XML的输入使得数据的字符解码过程变得透明：不用再和用户解释需要如何解码，编码数据源。不过，XML的学习成本还是比较高的，假设你HTML的学习成本是1，XML则可能为10，而XSLT的学习成本则可能高达100。

传统数据库应用的全文检索加速
让数据库负责精确匹配，将模糊匹配用独立的系统实现
一个站点内容积累在万级以上，站内全文检索就会是用户定位最主要的手段，而关键词检索是用户最熟悉的方法。因此基于数据库的传统WEB应用在全文检索需求还是很大的。

但是可怕的%like%数据库操作可能会吃掉数据库服务器90%以上的CPU。Oracle MSSQL等数据库服务器中数据库内置的全文检索基本上都不太适合WEB应用。而数据库另外一个的弊端在于对于条件简单的查询返回结果集非常大：数据库并不知道如何面向用户最关心的的头100条结果进行优化。根据以前的统计：头100条结果往往已经可以满足95％以上用户需求。

需要缓存设计：根据我们的经验，在应用设计中没有必要进行内置的结果缓存设计：让前台的应用服务器内置的缓存机制或者反相代理缓存服务器进行缓存就够了。

数据同步策略
总体上讲，全文检索和数据库其实是2种根本不同的应用模式，全文检索系统其实往往也没有必要和数据库那么高的实时同步机制，如果按照：低更新，高缓存的模式进行设计：数据库数据到全文索引的同步过程一般都可以通过脚本定期将数据库的数据导出成XML，然后进入Lucene的全文索引。而针对原有数据记录的更新和删除，其实一般可以通过定期的重建索引解决。WebLucene其中索引部分是一个IndexRunner的命令行程序实现的。

结果排序策略
站内全文索引另外一个很重要的需求是可定制的排序：按时间，按价格，按点击量……Lucene全文索引缺省只提供了根据关键词在原文中的匹配度排序，而任何根据某个字段的值进行排序的都无法避免再次遍历数据，从而导致性能有数量级的下降（等于又是做%Like%检索），而在索引中，除了匹配度SCORE外，唯一能用来排序的就是索引记录的ID，所以一个比较高效率实现定制排序的方法时：在索引时，让进入Lucene全文的顺序对应着一定规则：比如时间，然后在搜索时，让搜索结果按照索引记录的ID进行排序（或倒排）。

搜索结果关键词标引的实现
搜索结果中关键词通过红色或者黑体字标记出来，为了能够更恰当的显示相关上下文的问题，标引是通过限制了一个扫描范围，然后根据一个分析器将指定的词流式的读取出来，然后

全文检索和其他应用的集成
其实核心的是一个Lucene的XML接口：SAX方式的数据导入和DOM方式的结果输出。

XML的数据源定义：
只要是能够映射成表＝》记录＝》字段这样层次结构的都可以。因此WebLucene索引的设计比较灵活，甚至可以直接用来索引RSS。

XML结果定义：参考了Google的XML接口的设计

如果没有SERVLET界面，提供XML输出的DOMSearcher也可以很方便集成到各种应用系统中。


参考资料：

系统设计中使用的一些模块：


Jakarta Lucene: http://jakarta.apache.org/lucene/
Xerces / Xalan http://xml.apache.org/

Log4j http://jakarta.apache.org/log4j/

Google的XML接口定义： http://www.google.com/google.dtd
其他开发人员的一些反馈和改进

将WebLucene中的lucene部分升级到2.1
WebLucene安装实习篇 
WebLucene的安装经验
银杏咨询： 站内搜索引擎提供商，为点评，饭统网提供了站内全文检索服务； ]]> http://www.xd-tech.com.cn/blog/default.asp?id=73 <![CDATA[SQL Server 2005全文检索技术在网站上的应用实录(7)]]> jaddy0302@126.com(admin) Wed,15 Oct 2008 15:22:05 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=73
除了硬件资源 [如内存（3GB 限制）、磁盘速度和 CPU 速度] 以外，全文搜索性能还受到 Microsoft SQL Server 和 Microsoft Full-Text Engine for SQL Server (MSFTESQL) 服务对这些资源的争用情况的影响。MSFTESQL 服务只对磁盘进行写操作，而 SQL Server 会对磁盘进行读写操作。从性能角度出发，关键是很好地优化 MSFTESQL 服务，以便获得最佳使用效果。

全文搜索性能包含两个方面：

◆全文索引性能
◆全文查询性能

全文索引性能

Microsoft SQL Server 2005 中的全文搜索的索引性能很大程度上取决于下面两个因素：

◆SQL Server 创建全文批花费的时间。
◆MSFTESQL 服务使用这些批的速度。

若要达到最佳性能，需要优化 SQL Server 与 MSFTESQL 服务之间的交互。如果 MSFTESQL 服务处理不完 SQL Server 生成的批，该服务将暂停，并生成一个爬网日志消息来指示此暂停状态。有关如何解决此问题的信息，请参阅Microsoft SQL Server 全文引擎 (MSFTESQL) 服务已暂停。

另一方面，如果 SQL Server 没有生成足够的全文批, 使 MSFTESQL 服务充分运行，该服务就会闲置，这样就不能达到最佳性能。若要确保 MSFTESQL 服务处于最佳使用状况，需要跟踪并优化下列计数器：

正在处理的批计数器 - Microsoft Full-Text Engine Filter Daemon (MSFTELFD)

此计数器应当等于系统中的 CPU 数或其两倍。当 CPU 使用值为 0、1 或 2 时，指示 SQL Server 执行情况不好。例如，如果计算机上具有 4 个 CPU，此数值就应该为 4 或 8。

已就绪的批队列 - MSFTESQL 服务

如果批数较少，可以执行下列操作：

◆增加全文批的大小。
◆确保基表具有聚集索引。
◆将 SQL 日志、数据库文件和全文目录分别放在单独的磁盘上。
◆默认情况下，全文批的大小是每批 1600 行。如果计算机上有八个频率为 700Mhz 的 CPU，推荐采用的批大小为 5000 行。

注意：  

增加批大小会导致批的生成速度变慢，而且 MSFTSQL 要执行更多的操作来处理每个批。此外，请记住全文批的大小受共享内存区域大小的限制。共享内存区域大小的默认值为 4Mb。

爬网范围 

◆使用 sp_configure 最大全文爬网范围选项增大爬网范围计数器。理想情况下，此值应该是 CPU 数的两倍。
◆使用 Update STATISTICS 语句更新基表的统计信息。 

提高全文查询性能的建议

下面列出了有助于提高全文查询性能的建议。

使用 Alter INDEX REORGANIZE 对基表的索引进行碎片整理。

使用 Alter FULLTEXT CATALOG REORGANIZE 重新组织全文目录。切记要在进行性能测试之前执行此操作，因为它会引起该目录中全文索引的主合并。

仅选择较小的列作为全文键列。即使支持 900 字节的列，也不建议您使用这么大的键列来创建全文索引。

将多个 CONTAINS 合并为一个 CONTAIN。在 Microsoft SQL Server 中，您可以在 CONTAINS 查询中指定一个包含若干列的列表。

如果只需要全文键或排名的信息，请分别使用 CONTAINSTABLE 或 FREETEXTTABLE，而不要使用 CONTAINS 或 FREETEXT。

使用 FREETEXTTABLE 和 CONTAINSTABLE 语法的 TOP_N_BY_RANK 选项来限制结果数并提高性能。如果您不是对可能查询到的所有信息都感兴趣，可使用此选项。

六、需求规划

我们知道做好网站检索不仅仅面临纯技术的问题，而且本身需要事前的需求规划，这里给出了全网搜索在功能性需求和非功能性需求上的典型需求。

功能性的需求： 

（1）哪些业务数据需要提供全文的检索服务？ 
（2）这些业务数据中那些关键信息是业务人员关心的？ 
（3）需要支持哪些国家的语言？ 
（4）有哪些行业术语、常用缩略词、替换词？ 
（5）需要哪些检索功能，分别基于什么范畴的关键字展开检索？ 

非功能性的需求： 

（1）业务上以前是否尝试过关系数据库查询、多维数据分析解决手头的问题？ 
（2）检索时效性要求。 
（3）习惯的检索操作平台（浏览器 / 桌面），查询结果的展示方式。 
（4）授权控制。 
（5）查询结果的导出和发布方式要求。 

七、结束语

本文提供了网站如何设计和实现基于SQL Server 2005的全文检索实例，希望能对正在使用SQL Server 2005构建网站搜索的同仁有所裨益。

]]> http://www.xd-tech.com.cn/blog/default.asp?id=72 <![CDATA[SQL Server 2005全文检索技术在网站上的应用实录(6)]]> jaddy0302@126.com(admin) Wed,15 Oct 2008 15:21:20 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=72
Create PROCEDURE [dbo].[USP_GetFrontDataList_ByFullIndex](@TableViewQueryName  Varchar( 1024 ),   --Table或View或者Query的名字或字符串 @Key    Varchar( 50 ),  --关键字 @SelectStr   Varchar( 500 ),   --选择列字符串 @Criteria   Varchar( 8000 ),--查询条件 @Sort    Varchar( 255 ), --排序字符串 @FristTopNum   INT,      --显示的第一页置顶的数目 @Page    BIGINT  OUTPUT, --显示的当前页号 @CurrentPageRow  BIGINT,  --页大小(显示多少行)@TotalCount   BIGINT OUTPUT   --通过该查询条件，返回的查询记录的总页数 )ASSET NOCOUNT ON if charindex(';',@Criteria)>0 or charindex('--',@Criteria)>0 or charindex('/*',@Criteria)>0 or charindex('*/',@Criteria)>0 or charindex('syscolumns',@Criteria)>0  or charindex('sysfiles',@Criteria)>0or charindex('char(124)',@Criteria)>0  or charindex('1=1',@Criteria)>0 RETURN DECLARE @TotalStr  nVarchar(4000)DECLARE @Str   nVarchar(4000)DECLARE @TopRowNum bigintIF  @SelectStr IS NULL ANDRTRIM(LTRIM(@Criteria)) = ''SET @SelectStr = '*'IF @FristTopNum IS NULL AND @FristTopNum < 0BEGINSET @FristTopNum = 0ENDELSE IF @FristTopNum > @CurrentPageRowBEGINSET @FristTopNum = @CurrentPageRowENDIF  @CurrentPageRow > 0BEGINIF @Criteria IS NOT NULL ANDRTRIM(LTRIM(@Criteria)) <> ''BEGINSET  @TotalStr = 'Select @TotalCount=COUNT(*) FROM  ' + '('+ @TableViewQueryName   +')'+ ' T '+ ' Where ' + @CriteriaENDELSEBEGINSET  @TotalStr = 'Select @TotalCount=COUNT(*) FROM ' + '('+@TableViewQueryName  +')'+ ' T ' ENDPRINT @TotalStrEXEC  sp_ExecuteSql @TotalStr, N'@TotalCount bigint output',@TotalCount outputSET @TotalCount = @TotalCount + isnull(@FristTopNum  ,0)DECLARE @TotalPage bigintSET @TotalPage = @TotalCount/@CurrentPageRowIF @TotalCount%@CurrentPageRow > 0BEGINSET @TotalPage = @TotalPage + 1END IF @Page <= 0 BEGINSET @Page = 1ENDIF @TotalPage > 0 AND@Page > @TotalPageBEGINSET @Page = @TotalPageEND --组织查询语句 SET  @Str =  'Select   ' +   @SelectStr + ' FROM (' +  @TableViewQueryName  + ') T Where  T.SerialNumber >' +cast ((@Page-1)  as varchar(10)) + '*' +cast( @CurrentPageRow as varchar(10))+  ' AND T.SerialNumber <= '+cast (@Page  as varchar(10)) + '*' +cast( @CurrentPageRow as varchar(10))IF @Sort IS NOT NULL ANDRTRIM(LTRIM(@Sort)) <> ''BEGINIF @Criteria IS NOT NULL AND  RTRIM(LTRIM(@Criteria)) <> ''BEGINSET  @Str = @Str +   ' AND (' + @Criteria + ') orDER BY '+@Sort ENDELSEBEGINSET  @Str = @Str +   ' AND  (' + @Criteria + ') orDER BY '+@Sort ENDENDELSEBEGIN IF @Criteria IS NOT NULL AND   RTRIM(LTRIM(@Criteria)) <> ''BEGINSET @str = @str +  ' AND (' + @Criteria + ')  '   ENDEND--对无记录时当前页数的处理 IF @TotalCount=0BEGINSET @Page = 0ENDENDEXEC  sp_ExecuteSql @Str 
 
由于本行业网站可以提高如下几类信息资源，现列表分示如下：

ID 检索内容 数据表 检索命令示例 
1 投资 CapitalInfoTab DECLARE @RC int 
DECLARE @TableViewQueryName varchar(1024) 
DECLARE @SearchKeyword nvarchar(100) 
DECLARE @SelectStr varchar(500) 
DECLARE @Criteria varchar(8000) 
DECLARE @Sort varchar(255) 
DECLARE @FristTopNum int 
DECLARE @Page bigint 
DECLARE @CurrentPageRow bigint 
DECLARE @TotalCount bigint 
DECLARE @Totaltimes bigint 
　 
-- TODO: 在此处设置参数值。 
 SET @SearchKeyword = '地产项目' 
 SET @SelectStr = '*' 
 SET @Sort = '' 
 SET @Page= 1 
 SET @CurrentPageRow = 20 
  
EXECUTE @RC = [InvestDM].[dbo].USP_CapitalInfo_FullIndex  
   @TableViewQueryName 
  ,@SearchKeyword 
  ,@SelectStr 
  ,@Criteria 
  ,@Sort 
  ,@FristTopNum 
  ,@Page   
  ,@CurrentPageRow 
  ,@TotalCount OUTPUT 
  ,@Totaltimes OUTPUT 
Select @Page,@TotalCount,@Totaltimes 
2 融资 ProjectInfoTab DECLARE @SearchKeyword nvarchar(100)  --传入的查询关键字 
SET      @SearchKeyword = '深圳' 
　 
Select  p.title,  
p.infoid, 
f.[rank] , 
keyword,title,provinceName,cityName,CountyName  
  
FROM  
FREETEXTTABLE([ProjectInfoFactTab], (provinceName,cityName,CountyName,keyword,title), @SearchKeyword) AS f 
INNER JOIN [ProjectInfoFactTab] AS p 
ON f.[key] = p.infoID  
orDER BY RANK DESC 
3 招商 MerchantInfoTab     DECLARE @SearchKeyword nvarchar(100)  --传入的查询关键字 
    SET      @SearchKeyword = '深圳' 
    Select   
 ROW_NUMBER() OVER (ORDER BY RANK DESC) AS SerialNumber , 
 F.[rank],  
 p.*  
 FROM  
 FREETEXTTABLE( MerchantInfoFactTab , (ProvinceName, CityName,    CountyName, Keyword,  
 Title ,IndustryBName , shortcontent, ZoneAbout , ZoneAboutBrief, MerchantTypeName ,MerchantAttributeName,

CooperationDemandName ) ,

@SearchKeyword) AS f 
 
 INNER JOIN   MerchantInfoFactTab   AS p   
 ON f.[key] = p.infoID 
4 资讯 NewsTab      DECLARE @SearchKeyword nvarchar(100)  --传入的查询关键字 
     SET      @SearchKeyword = '深圳' 
     Select    
  ROW_NUMBER() OVER (ORDER BY RANK DESC) AS SerialNumber ,  
 F.[rank] , 
  p.*   
 FROM   
  FREETEXTTABLE( NewsInfoFactTab , (AreaName,   Keyword,   
  Title , DisplayTitle, subtitle ,Summary , Content  ,NewsIndustryName ,    NewsTypeName ) , @SearchKeyword ) AS f  
 INNER JOIN   NewsInfoFactTab   AS p   
  ON f.[key] = p.infoID   

]]> http://www.xd-tech.com.cn/blog/default.asp?id=71 <![CDATA[SQL Server 2005全文检索技术在网站上的应用实录(5)]]> jaddy0302@126.com(admin) Wed,15 Oct 2008 15:19:34 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=71
Create FULLTEXT INDEX ON TableName KEY INDEX PK_IndexName ON  DB WITH CHANGE_TRACKING AUTOAlter FULLTEXT INDEX ON TableName ADD ColumnName   


b)选择或创建新的索引目录。

 

图7 

c)定义填充计划。

 

图8 

至此，表的全文索引已经建立完毕，表示只要键入SQL 指令就可以完成全文检索功能。

第三步，开发存储过程并把结果集分页，以供前台页面调用返回查询的结果。

1) 建立找资本全文检索储存过程USP_CaptialInfo_FullIndex。

/* 找资本全文索引开发过程  */Create PROCEDURE USP_CaptialInfo_FullIndex(@TableViewQueryName Varchar( 1024 ), --传入的查询字符窜@SearchKeyword  nvarchar(100), --传入的查询关键字@SelectStr  Varchar( 500 ),  --选择列字符串 @Criteria  Varchar( 8000 ), --查询条件 @Sort   Varchar( 255 ),  --排序字符串 @FristTopNum  int,   --显示的第一页置顶的数目 @Page   bigint OUTPUT  ,  --显示的当前页号 @CurrentPageRow bigint,   --页大小(显示多少行)  @TotalCount  bigint output,  --通过该查询条件，返回的查询记录的总页数 @Totaltimes  bigint output  --所有搜索时间，以秒为单位)as  DECLARE @starttime datetime, @endtime datetimeSelect  @starttime = getdate()IF  ISNULL(@SearchKeyword,'') !='' or  RTRIM(@SearchKeyword)!=''BEGINSET @TableViewQueryName = ' Select  '+' ROW_NUMBER() OVER (ORDER BY RANK DESC) AS SerialNumber ,'+' F.[rank], '+' p.*' +' FROM '+' FREETEXTTABLE( CapitalInfoFactTab , (ProvinceName, CityName,  CountyName, Keyword,Title ,IndustryBName , shortcontent, ComAbout , ComBreif) ,'+ ''''+@SearchKeyword+ ''''+') AS f '+' INNER JOIN   CapitalInfoFactTab   AS p  '+' ON f.[key] = p.infoID ' EXEC [USP_GetFrontDataList_ByFullIndex] @TableViewQueryName, @SearchKeyword, @SelectStr, @Criteria, @Sort, @FristTopNum,@Page OUTPUT , @CurrentPageRow , @TotalCount OUTPUTEND ELSE BEGINEXEC dbo.GetFrontDataList 'dbo.ProjectInfoFactTab', 'InfoID',@SelectStr,@Criteria,@Sort,0, @Page output, @CurrentPageRow, @TotalCount outputENDSelect  @endtime = getdate()Select  @Totaltimes  = DATEdiff(Ms, @starttime ,@endtime)RETURN  

]]> http://www.xd-tech.com.cn/blog/default.asp?id=70 <![CDATA[SQL Server 2005全文检索技术在网站上的应用实录(4)]]> jaddy0302@126.com(admin) Wed,15 Oct 2008 15:17:26 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=70
 


ProjectInfoTab（项目信息明细表）

 


MerchantInfoTab（政府招商信息明细表）

 


四、数据库全文检索实现 

至此，我们已经完成了全文检索的设计工作，现在可以来实现它的功能啦！

首先， 让我们建立检索表的全文检索，全文检索要求唯一索引，故需要在相关表建立唯一聚集索引。

第二步，使用SQL DDL或者SQL Server Management Studio建立表的全文检索。

1）使数据库支持全文检索。

 

图5 

或者通过键入命令  EXEC SP_FULLTEXT_DATABASE  'Enable'  命令达到同样效果。

2）定义表的全文检索目录和索引字段。

在表的鼠标右键通过点击“全文检索\定义全文检索”将弹出如下执行向导，本向导执行完毕则该表的全文检索业已完毕。

a)选择要索引的字段
 
图6 ]]> http://www.xd-tech.com.cn/blog/default.asp?id=69 <![CDATA[SQL Server 2005全文检索技术在网站上的应用实录(3)]]> jaddy0302@126.com(admin) Wed,15 Oct 2008 14:56:18 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=69
1、架构设计 

采用OLTP交易数据库和OLAP数据仓库（用于搜索和分析）分离的模式，OLTP作为OLAP的数据源通过SQL Server Integration Services (SSIS)定期导入到OLAP数据仓库环境中，OLAP采用星型结构以便于更好地满足搜索和将来的数据挖掘。 OLAP数据仓库的建立目标为了检索和数据挖掘，故其事实表的建立可以反范式原则设计。

 
图2 

2、原型设计（由于篇幅限制，这里仅给出搜索主页和主要资源查询页面）

 
图3 

3、数据库设计

 
图4 

4、数据字典

MainInfoTab(信息主表)]]> http://www.xd-tech.com.cn/blog/default.asp?id=68 <![CDATA[SQL Server 2005全文检索技术在网站上的应用实录(2)]]> jaddy0302@126.com(admin) Wed,15 Oct 2008 14:54:55 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=68
 

图1 

让我们逐一介绍两类重要的引擎及其在整个体系结构中的重要作用。

Full-Text Engine for SQL Server (MSFTESQL)

MSFTESQL 服务负责进行下列操作：

◆填充全文索引。
◆管理全文索引和全文目录。
◆帮助对 SQL Server 数据库中的表进行全文搜索。

让我们来看看SQL Server 2005全文索引的过程

全文填充（也称为爬网或爬虫）开始后，数据库引擎会将大批数据存入内存并通知 Microsoft SQL Server 全文引擎 (MSFTESQL) 服务开始进行索引。MSFTESQL 服务将对表的某一列或几列中的字符和格式化二进制数据编制索引。全文引擎将使用协议处理程序组件从内存中取出数据并进行进一步处理，从而生成全文索引。

对存储在 varbinary(max) 或 image 列中的数据编制索引时，筛选器（实现了 IFilter 接口）将基于为该数据指定的文件格式（例如，Microsoft Word）来提取文本。在某些情况下，筛选器组件会要求将 varbinary(max) 或 image 数据写到服务帐户 Temp 目录中，而不是将其存入内存。

在处理过程中，通过断字符将收集到的文本数据分隔成各个单独的标记或关键字。用于标记化的语言将在列级指定，或者也可以通过筛选器组件在 varbinary(max)、image 或 xml 数据内标识。

还可能执行其他处理以删除干扰词并在将标记存储到全文索引或索引片断中之前将这些标记规范化。 

Microsoft Full-Text Engine for SQL Server 的功能

SQL Server 2005 为全文引擎提供了并行安装方式。这意味着对于每个 SQL Server 实例，都存在一个专用的 MSFTESQL 实例，其中包括专用的组件（例如断字符和筛选器）、资源（例如内存）和配置（例如服务级设置，实例级的 resource_usage 是一个更具体的例子）。单个 MSFTESQL 服务实例可管理相关联的 SQL Server 实例的全文索引。利用 MSFESQL 服务，SQL Server 可超出 SQL 标准对字符串列执行更为复杂的搜索。

MSFTESQL 服务担当了以下角色： 

索引支持 

MSFTESQL 实现了为数据库定义的全文目录和索引。

查询支持 

MSFTESQL 可处理全文搜索查询并确定索引中符合全文选择条件的项。对于符合选择条件的每一项，MSFTESQL 将向 SQL Server 服务返回相应行的标识外加一个排名值，而后者将使用这些信息来构造查询结果集。所支持的查询类型包括：

◆搜索词或短语。
◆搜索位置邻近的词。
◆搜索词的变形。 

可管理性支持 

全文目录和索引不会存储在 SQL Server 数据库中。MSFTESQL 服务负责管理全文目录。

Microsoft Full-Text Engine Filter Daemon

MSFTEFD 由负责从表中访问和筛选数据以及进行断字和词干分析的组件组成。

◆筛选器

筛选器的任务是从文档中提取文本化信息流，并舍弃所有非文本化信息和格式化信息。筛选器将生成文本字符串和属性/值对，并依次将它们传递给索引引擎。 

筛选器可从特定的文档格式（如 Microsoft Word 文档或文本文件）中提取文本化信息。例如，Microsoft 提供了 Microsoft Office 筛选器，此筛选器可以从 Word、Microsoft Excel 和 Microsoft PowerPoint 文件中提取文本和属性。其他筛选器用于处理 HTML 或电子邮件。还可以使用第三方筛选器。 

◆SQL 协议处理程序

在 SQL Server 2005 中，SQL 协议处理程序的工作是从指定数据库中的表内访问数据。

断字符

断字符是用于在查询或抓取的文档中确定字符流中的字符边界位置。有关详细信息。

全文搜索的索引组件负责全文索引的初始填充，以及当全文索引表中的数据被修改时该索引的后续更新。为了提升全文索引过程的效率，Microsoft SQL Server 2005 改进了全文收集机制的体系结构，从而大大增强了性能。

Microsoft Full-Text Engine for SQL Server (MSFTESQL) 服务是一个全文索引和搜索引擎。MSFTESQL 引擎基于 Microsoft Search (MSSearch) 技术，它与 Microsoft SQL Server 2005 Database Engine 进行了最为紧密的集成。 

全文引擎作为 MSFTESQL 服务在操作系统上运行。SQL Server 与 MSFTESQL 必须拥有相同的服务帐户。默认情况下将安装 MSFTESQL 服务，但是只有在使用全文搜索时才会运行此项服务。]]> http://www.xd-tech.com.cn/blog/default.asp?id=67 <![CDATA[SQL Server 2005全文检索技术在网站上的应用实录(1)]]> jaddy0302@126.com(admin) Wed,15 Oct 2008 14:53:57 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=67
“人类失去搜索，世界将会怎样?”，同样，很难想象一个拥有极大信息量的行业网站门户没有站内全文搜索将会出现怎样的局面，网站全文检索对于挖掘网站信息和整合网站资源的价值是不言而喻的。我们看到，通用型的搜索引擎已经成为了互联网世界的门户，而对于一个信息量极其丰富的网站而言，全网搜索或许会成为本网站的门户，正是所谓的门户之门。

实现网站全文检索有几种常见方案，比如应用数据库全文检索，开源搜索引擎，使用Google API等， 本文我们将就如何使用SQL Server 2005多快好省地建立网站全文检索展开探讨。

二、全文检索技术说明

1、应用背景 

先介绍下Z网站，它是国内投融资行业最大的行业门户，网站拥有海量的融资信息、投资信息、招商信息、创业信息、商机信息、资讯信息、产权交易信息、招标投标信息、中标信息、会展信息等投融资行业的信息资源。网站全文检索实现的首要需求就在于能够让用户输入诸如行业关键字后系统能快速返回给符合用户在全范围内查找条件的记录, 从而有效地利用资源，更好地满足用户需求。

2、主要检索技术的区别 

有了数据但是没有被使用，那么这些数据不应该被称为信息。它们无非是不断充斥设备和网络的比特而已，但是如何把数据挖掘出来提供给需要的人员，检索技术是其中非常有效的途径之一。

现基于微软平台，针对SQL Server 2005提供的全文检索技术进行介绍。与关系数据查询、多维数据库查询和基于XML的XQuery、XPath不同，全文检索技术主要处理对象是基于超大 数据量的文本数据和结构化的二进制数据上类似LIKE的模糊查询。主要区别见下表。  

表1：全文检索与关系数据库查询、多维数据查询、XML查询的对比

　 关系数据库查询 多维数据查询 XML查询 全文检索 
检索技术 SQL MDX XQuery、XPath SQL (extension) 
主要处理对象 关系二维数据 结构化多维数据 层次型数据 大容量二维和层次型数据的模糊检索 
主要应用领域 一般的OLTP类应用 一般的OLAP类分析型应用 面向Internet、Intranet的松散耦合SOA应用 企业/网站内部信息/知识管理类应用 
索引 大量使用非聚簇索引，一般保存在数据库中。 通过层次型、保存中间结果的方式，通过不同的轴向快速定位信息剖面。 基于XPath的索引，索引一般保存在数据库中。 基于关键字的索引，保存在文件系统中。每个表仅支持一个索引。 


3、全文检索技术简要介绍 

全文检索主要应用领域如下： 

（1）大数据量、超大数据量的结构化平文本数据和模糊匹配查找（Char、Varchar、Nvarchar）。 

（2）大数据量、超大数据量的层次型XML数据展开后的查找---含模糊查找（Xml type）。 

（3）标准格式的二进制非结构化Word数据的查找（VarBinary[max]、Image）。 

与其他检索技术不同的是，全文检索不仅仅提供词汇层次的查询支持，而且可以根据语言环境、不同语言的特点，甚至于用户自定义的配置提供不同语义级的大容量的数据模糊匹配检索支持。为了提供语义层次的检索，SQL Server 2005的全文检索明确了如下几个概念： 

（1）断字符（Word Breaker）：因为对于不同的语言，哪些符号可以用于词汇的分割是不同的，因此全文检索支持不同语言环境的不同断字符。 

（2）标记（Token）：是由断字符标识的词或字符串。由于划分是基于特定语言完成的，因此也可以做到语义层次的支持。 

（3）干扰词（Noise Word）：主要是那些经常出现，但是对于检索没有多少帮助的词汇。例如：英语中的“a”、 “and”、 “is”、 “the”，汉语中的“的”、 “不”、 “以”、 “了”等。SQL Server 2005中提供配置文件，允许用户自定义自己语言、甚至与本行业、本企业的检索干扰词。 

（4）词干分析器（Stemmer）：通过断字符分割后，根据具体的语言和该语言的语法规程生成的特定词汇的变形。 这个即是搜索引擎常提到的分词技术。

（5）同义词：即便是同一个语言，在检索的情况下也存在同义词如何处理的问题。如果一个检索系统不能够识别近义词，而只能识别完全匹配的词汇，那对于我们中文这种表义的语言而言会带来很大不便。同样的，一个行业内部也有很多同义词或者是缩略语。例如如下的词语。 

广播行业：“ABC”与“英国ABC广播公司”基本上类似，但是也可能和“澳大利亚广播公司”混淆。 

政府行文：“ABC”与南美的“阿根廷、巴西、智利三国”是同义词。 

不仅如此，由于日常使用的习惯，我们在口语表达和书面语表达上也有区别，这个也需要预先定义。例如，很多口头常用的技术产品“Win2K”、 “WinXP”等，一般都很正式的称为“Windows 2000”和 “Windows XP”，因此SQL Server 2005上也提供类似词汇替换的支持，而且这些支持也是与具体语言相关的。

4、SQL Server 2005全文检索的技术架构 

让我们首先得问自己，什么是全文检索？它是指Microsoft SQL Server 2005 具备针对 Microsoft SQL Server 表中基于纯字符的数据进行全文查询的功能。全文查询可以包括词和短语，或者词或短语的多种形式。

当我们明确了全文检索概念之后，我们来看看它的内部结构。

Microsoft SQL Server 2005 中的全文搜索由 Microsoft Full-Text Engine for SQL Server (MSFTESQL) 服务提供支持。MSFTESQL 服务有两个角色，即索引支持和查询支持。 

全文搜索的组件

全文搜索的体系结构由下列组件构成：

◆Microsoft Full-Text Engine for SQL Server (MSFTESQL)
◆Microsoft Full-Text Engine Filter Daemon (MSFTEFD)，它包含下列组件：
（1）筛选器
（2）协议处理程序
（3）断字符]]> http://www.xd-tech.com.cn/blog/default.asp?id=66 <![CDATA[Oracle9i的全文检索技术]]> jaddy0302@126.com(admin) Wed,15 Oct 2008 14:52:20 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=66
　　4 为文本建立索引

　　文本装入文本列后，就可以创建Oracle Text索引。文档以许多不同方案、格式和语言存储。因此，每个 oracle Text 索引有许多需要设置的选项，以针对特定情况配置索引。创建索引时，Oracle Text可使用若干个默认值，但在大多数情况下要求用户通过指定首选项来配置索引。

　　每个索引的许多选项组成功能组，称为"类"，每个类集中体现配置的某一方面，可以认为这些类就是与文档数据库有关的一些问题。例如：数据存储、过滤器、词法分析器、相关词表、存储等。

　　每个类具有许多预定义的行为，称之为对象。每个对象是类问题可能具有的答案，并且大多数对象都包含有属性。通过属性来定制对象，从而使对索引的配置更加多变以适应于不同的应用。

　　（1）存储（Storage）类

　　存储类指定构成Oracle Text索引的数据库表和索引的表空间参数和创建参数。它仅有一个基本对象：BASIC_STORAGE，其属性包括：I_Index_Clause、I_Table_Clause、K_Table_Clause、N_Table_Clause、P_Table_Clause、R_Table_Clause。

　　（2）数据存储（Datastore）类

　　数据存储：关于列中存储文本的位置和其他信息。默认情况下，文本直接存储到列中，表中的每行都表示一个单独的完整文档。其他数据存储位置包括存储在单独文件中或以其 URL 标识的 Web 页上。七个基本对象包括：Default_Datastore、Detail_Datastore、Direct_Datastore、File_Datastore、Multi_Column_Datastore 、URL_Datastore、User_Datastore，。

　　（3）文档段组（Section Group）类

　　文档段组是用于指定一组文档段的对象。必须先定义文档段，然后才能使用索引通过 WITHIN 运算符在文档段内进行查询。文档段定义为文档段组的一部分。包含七个基本对象：AUTO_SECTION_GROUP、BASIC_SECTION_GROUP、HTML_SECTION_GROUP、NEWS_SECTION_GROUP、NULL_SECTION_GROUP、XML_SECTION_GROUP、PATH_SECTION_GROUP。

　　（4）相关词表（Wordlist）类

　　相关词表标识用于索引的词干和模糊匹配查询选项的语言，只有一个基本对象BASIC_WORDLIST，其属性有：Fuzzy_Match、Fuzzy_Numresults、Fuzzy_Score、Stemmer、Substring_Index、Wildcard_Maxterms、Prefix_Index、Prefix_Max_Length、Prefix_Min_Length。

　　（5）索引集（Index Set）

　　索引集是一个或多个Oracle 索引 (不是Oracle Text索引) 的集合，用于创建 CTXCAT类型的Oracle Text索引，只有一个基本对象BASIC_INDEX_SET。

　　（6）词法分析器（Lexer）类

　　词法分析器类标识文本使用的语言，还确定在文本中如何标识标记。默认的词法分析器是英语或其他西欧语言，用空格、标准标点和非字母数字字符标识标记，同时禁用大小写。包含8个基本对象：BASIC_LEXER、CHINESE_LEXER、CHINESE_VGRAM_LEXER、JAPANESE_LEXER、JAPANESE_VGRAM_LEXER、KOREAN_LEXER、KOREAN__MORPH_ LEXER、MULTI_LEXER。

　　（7）过滤器（Filter）类

　　过滤器确定如何过滤文本以建立索引。可以使用过滤器对文字处理器处理的文档、格式化的文档、纯文本和 HTML 文档建立索引，包括5个基本对象：CHARSET_FILTER、INSO_FILTER INSO、NULL_FILTER、PROCEDURE_FILTER、USER_FILTER。

　　（8）非索引字表（Stoplist）类

　　非索引字表类是用以指定一组不编入索引的单词 (称为非索引字)。有两个基本对象：BASIC_STOPLIST (一种语言中的所有非索引字) 、 MULTI_STOPLIST (包含多种语言中的非索引字的多语言非索引字表)。

　　5 查询

　　建立了索引，就可以使用 Select 语句中的 CONTAINS 运算符发出文本查询。使用 CONTAINS 可以进行两种查询：单词查询和ABOUT查询。

　　5．1 词查询示例

　　词查询是对输入到 CONTAINS 运算符中单引号间的精确单词或短语的查询。在以下示例中，我们将查找文本列中包含 oracle 一词的所有文档。每行的分值由使用标签 1 的 SCORE 运算符选定：

Select SCORE(1) title from news Where CONTAINS(text, ’oracle’, 1) >0;

　　在查询表达式中，可以使用 AND 和 or 等文本运算符来获取不同结果。还可以将结构性谓词添加到 Where 子句中。可以使用 count(*)、CTX_QUERY.COUNT_HITS 或 CTX_QUERY.EXPLAIN 来计算查询的命中 (匹配) 数目。

　　5．2 ABOUT查询示例

　　在所有语言中，ABOUT查询增加了某查询所返回的相关文档的数目。在英语中，ABOUT 查询可以使用索引的主题词组件，该组件在默认情况下创建。这样，运算符将根据查询的概念返回文档，而不是仅依据所指定的精确单词或短语。例如，以下查询将查找文本列中关于主题 politics 的所有文档，而不是仅包含 politics 一词的文档：

Select SCORE(1) title from news Where CONTAINS(text, ’about(politics)’, 1) >0;]]> http://www.xd-tech.com.cn/blog/default.asp?id=65 <![CDATA[全文检索技术、搜索引擎]]> jaddy0302@126.com(admin) Wed,15 Oct 2008 14:51:09 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=65
Lucene是apache软件基金会[4] jakarta项目组的一个子项目，是一个开放源代码[5]的全文检索引擎工具包，即它不是一个完整的全文检索引擎，而是一个全文检索引擎的架构，提供了完整的查询引擎和索引引擎，部分文本分析引擎（英文与德文两种西方语言）。Lucene的目的是为软件开发人员提供一个简单易用的工具包，以方便的在目标系统中实现全文检索的功能，或者是以此为基础建立起完整的全文检索引擎。
Lucene的原作者是Doug Cutting，他是一位资深全文索引/检索专家，曾经是V-Twin搜索引擎[6]的主要开发者，后在Excite[7]担任高级系统架构设计师，目前从事于一些Internet底层架构的研究。早先发布在作者自己的http://www.lucene.com/，后来发布在SourceForge[8]，2001年年底成为apache软件基金会jakarta的一个子项目：http://jakarta.apache.org/lucene/。


    Lucene的应用、特点及优势


作为一个开放源代码项目，Lucene从问世之后，引发了开放源代码社群的巨大反响，程序员们不仅使用它构建具体的全文检索应用，而且将之集成到各种系统软件中去，以及构建Web应用，甚至某些商业软件也采用了Lucene作为其内部全文检索子系统的核心。apache软件基金会的网站使用了Lucene作为全文检索的引擎，IBM的开源软件eclipse[9]的2.1版本中也采用了Lucene作为帮助子系统的全文索引引擎，相应的IBM的商业软件Web Sphere[10]中也采用了Lucene。Lucene以其开放源代码的特性、优异的索引结构、良好的系统架构获得了越来越多的应用。


Lucene作为一个全文检索引擎，其具有如下突出的优点：


（1）索引文件格式独立于应用平台。Lucene定义了一套以8位字节为基础的索引文件格式，使得兼容系统或者不同平台的应用能够共享建立的索引文件。


（2）在传统全文检索引擎的倒排索引的基础上，实现了分块索引，能够针对新的文件建立小文件索引，提升索引速度。然后通过与原有索引的合并，达到优化的目的。


（3）优秀的面向对象的系统架构，使得对于Lucene扩展的学习难度降低，方便扩充新功能。


（4）设计了独立于语言和文件格式的文本分析接口，索引器通过接受Token流完成索引文件的创立，用户扩展新的语言和文件格式，只需要实现文本分析的接口。


（5）已经默认实现了一套强大的查询引擎，用户无需自己编写代码即使系统可获得强大的查询能力，Lucene的查询实现中默认实现了布尔操作、模糊查询（Fuzzy Search[11]）、分组查询等等。


    面对已经存在的商业全文检索引擎，Lucene也具有相当的优势。首先，它的开发源代码发行方式（遵守Apache SoftwareLicense[12]），在此基础上程序员不仅仅可以充分的利用Lucene所提供的强大功能，而且可以深入细致的学习到全文检索引擎制作技术和面相对象编程的实践，进而在此基础上根据应用的实际情况编写出更好的更适合当前应用的全文检索引擎。在这一点上，商业软件的灵活性远远不及Lucene。其次，Lucene秉承了开放源代码一贯的架构优良的优势，设计了一个合理而极具扩充能力的面向对象架构，程序员可以在Lucene的基础上扩充各种功能，比如扩充中文处理能力，从文本扩充到HTML、PDF[13]等等文本格式的处理，编写这些扩展的功能不仅仅不复杂，而且由于Lucene恰当合理的对系统设备做了程序上的抽象，扩展的功能也能轻易的达到跨平台的能力。最后，转移到apache软件基金会后，借助于apache软件基金会的网络平台，程序员可以方便的和开发者、其它程序员交流，促成资源的共享，甚至直接获得已经编写完备的扩充功能。最后，虽然Lucene使用Java语言写成，但是开放源代码社区的程序员正在不懈的将之使用各种传统语言实现（例如.net framework[14]），在遵守Lucene索引文件格式的基础上，使得Lucene能够运行在各种各样的平台上，系统管理员可以根据当前的平台适合的语言来合理的选择。]]> http://www.xd-tech.com.cn/blog/default.asp?id=64 <![CDATA[完美解决Discuz 论坛大数据量的全文检索问题]]> jaddy0302@126.com(admin) Wed,15 Oct 2008 14:45:46 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=64
     今天我给大家带来的引擎构建于J2EE平台，继承了它跨平台和安全的特性，内置的中文语言处理引擎支持从抓取的数据中自动提取关键字与自动生成摘要、采用增量采集方式，对于已经采集过的数据不会重复抓取，通过后台的配置，可以自动对于已经变动过的数据内容进行再次抓取，这并不需要太多的人工干预。然后建立系统独立的索引供用户检索；下面是我们单台服务器检索性能.

原文 地址：http://hi.baidu.com/xd%5Ftech/blog/item/e614a2f8aa43ad0ad9f9fd02.html]]> http://www.xd-tech.com.cn/blog/default.asp?id=63 <![CDATA[Lucene：基于Java的全文检索引擎简介]]> jaddy0302@126.com(admin) Wed,15 Oct 2008 14:36:42 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=63
Lucene

Lucene不是一个完整的全文索引应用，而是是一个用Java写的全文索引引擎工具包，它可以方便的嵌入到各种应用中实现针对应用的全文索引/检索功能。

Lucene的作者：Lucene的贡献者Doug Cutting是一位资深全文索引/检索专家，曾经是V-Twin搜索引擎(Apple的Copland操作系统的成就之一)的主要开发者，后在Excite担任高级系统架构设计师，目前从事于一些INTERNET底层架构的研究。他贡献出的Lucene的目标是为各种中小型应用程序加入全文检索功能。

Lucene的发展历程：早先发布在作者自己的www.lucene.com，后来发布在SourceForge，2001年年底成为APACHE基金会jakarta的一个子项目：http://jakarta.apache.org/lucene/

已经有很多Java项目都使用了Lucene作为其后台的全文索引引擎，比较著名的有：

Jive：WEB论坛系统； 
Eyebrows：邮件列表HTML归档/浏览/查询系统，本文的主要参考文档“TheLucene search engine: Powerful, flexible, and free”作者就是EyeBrows系统的主要开发者之一，而EyeBrows已经成为目前APACHE项目的主要邮件列表归档系统。 
Cocoon:基于XML的web发布框架，全文检索部分使用了Lucene 
Eclipse:基于Java的开放开发平台，帮助部分的全文索引使用了Lucene

对于中文用户来说，最关心的问题是其是否支持中文的全文检索。但通过后面对于Lucene的结构的介绍，你会了解到由于Lucene良好架构设计，对中文的支持只需对其语言词法分析接口进行扩展就能实现对中文检索的支持。

全文检索的实现机制

Lucene的API接口设计的比较通用，输入输出结构都很像数据库的表==>记录==>字段，所以很多传统的应用的文件、数据库等都可以比较方便的映射到Lucene的存储结构/接口中。总体上看：可以先把Lucene当成一个支持全文索引的数据库系统。

比较一下Lucene和数据库：

Lucene 数据库 
索引数据源：doc(field1,field2...) doc(field1,field2...)                  \  indexer /                 _____________                | Lucene Index|                --------------                 / searcher \ 结果输出：Hits(doc(field1,field2) doc(field1...))
 索引数据源：record(field1,field2...) record(field1..)              \  SQL: insert/               _____________              | DB  Index   |               -------------              / SQL: select \结果输出：results(record(field1,field2..) record(field1...))
 
Document：一个需要进行索引的“单元”
一个Document由多个字段组成 Record：记录，包含多个字段 
Field：字段 Field：字段 
Hits：查询结果集，由匹配的Document组成 RecordSet：查询结果集，由多个Record组成 

全文检索 ≠ like "%keyword%"

通常比较厚的书籍后面常常附关键词索引表（比如：北京：12, 34页，上海：3,77页……），它能够帮助读者比较快地找到相关内容的页码。而数据库索引能够大大提高查询的速度原理也是一样，想像一下通过书后面的索引查找的速度要比一页一页地翻内容高多少倍……而索引之所以效率高，另外一个原因是它是排好序的。对于检索系统来说核心是一个排序问题。

由于数据库索引不是为全文索引设计的，因此，使用like "%keyword%"时，数据库索引是不起作用的，在使用like查询时，搜索过程又变成类似于一页页翻书的遍历过程了，所以对于含有模糊查询的数据库服务来说，LIKE对性能的危害是极大的。如果是需要对多个关键词进行模糊匹配：like"%keyword1%" and like "%keyword2%" ...其效率也就可想而知了。

所以建立一个高效检索系统的关键是建立一个类似于科技索引一样的反向索引机制，将数据源（比如多篇文章）排序顺序存储的同时，有另外一个排好序的关键词列表，用于存储关键词==>文章映射关系，利用这样的映射关系索引：[关键词==>出现关键词的文章编号，出现次数（甚至包括位置：起始偏移量，结束偏移量），出现频率]，检索过程就是把模糊查询变成多个可以利用索引的精确查询的逻辑组合的过程。从而大大提高了多关键词查询的效率，所以，全文检索问题归结到最后是一个排序问题。

由此可以看出模糊查询相对数据库的精确查询是一个非常不确定的问题，这也是大部分数据库对全文检索支持有限的原因。Lucene最核心的特征是通过特殊的索引结构实现了传统数据库不擅长的全文索引机制，并提供了扩展接口，以方便针对不同应用的定制。

可以通过一下表格对比一下数据库的模糊查询：

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

全文检索和数据库应用最大的不同在于：让最相关的头100条结果满足98%以上用户的需求

Lucene的创新之处：

大部分的搜索（数据库）引擎都是用B树结构来维护索引，索引的更新会导致大量的IO操作，Lucene在实现中，对此稍微有所改进：不是维护一个索引文件，而是在扩展索引的时候不断创建新的索引文件，然后定期的把这些新的小索引文件合并到原先的大索引中（针对不同的更新策略，批次的大小可以调整），这样在不影响检索的效率的前提下，提高了索引的效率。

Lucene和其他一些全文检索系统/应用的比较：

　 Lucene 其他开源全文检索系统 
增量索引和批量索引 可以进行增量的索引(Append)，可以对于大量数据进行批量索引，并且接口设计用于优化批量索引和小批量的增量索引。 很多系统只支持批量的索引，有时数据源有一点增加也需要重建索引。 
数据源 Lucene没有定义具体的数据源，而是一个文档的结构，因此可以非常灵活的适应各种应用（只要前端有合适的转换器把数据源转换成相应结构）， 很多系统只针对网页，缺乏其他格式文档的灵活性。 
索引内容抓取 Lucene的文档是由多个字段组成的，甚至可以控制那些字段需要进行索引，那些字段不需要索引，近一步索引的字段也分为需要分词和不需要分词的类型：
   需要进行分词的索引，比如：标题，文章内容字段
   不需要进行分词的索引，比如：作者/日期字段 缺乏通用性，往往将文档整个索引了 
语言分析 通过语言分析器的不同扩展实现：
可以过滤掉不需要的词：an the of 等，
西文语法分析：将jumps jumped jumper都归结成jump进行索引/检索
非英文支持：对亚洲语言，阿拉伯语言的索引支持 缺乏通用接口实现 
查询分析 通过查询分析接口的实现，可以定制自己的查询语法规则：
比如： 多个关键词之间的 + - and or关系等 　 
并发访问 能够支持多用户的使用 　 

　

关于亚洲语言的的切分词问题(Word Segment)

对于中文来说，全文索引首先还要解决一个语言分析的问题，对于英文来说，语句中单词之间是天然通过空格分开的，但亚洲语言的中日韩文语句中的字是一个字挨一个，所有，首先要把语句中按“词”进行索引的话，这个词如何切分出来就是一个很大的问题。

首先，肯定不能用单个字符作(si-gram)为索引单元，否则查“上海”时，不能让含有“海上”也匹配。

但一句话：“北京天安门”，计算机如何按照中文的语言习惯进行切分呢？
“北京 天安门” 还是“北 京 天安门”？让计算机能够按照语言习惯进行切分，往往需要机器有一个比较丰富的词库才能够比较准确的识别出语句中的单词。

另外一个解决的办法是采用自动切分算法：将单词按照2元语法(bigram)方式切分出来，比如：
"北京天安门" ==> "北京 京天 天安 安门"。

这样，在查询的时候，无论是查询"北京" 还是查询"天安门"，将查询词组按同样的规则进行切分："北京"，"天安安门"，多个关键词之间按与"and"的关系组合，同样能够正确地映射到相应的索引中。这种方式对于其他亚洲语言：韩文，日文都是通用的。

基于自动切分的最大优点是没有词表维护成本，实现简单，缺点是索引效率低，但对于中小型应用来说，基于2元语法的切分还是够用的。基于2元切分后的索引一般大小和源文件差不多，而对于英文，索引文件一般只有原文件的30%-40%不同，

 自动切分 词表切分 
实现 实现非常简单 实现复杂 
查询 增加了查询分析的复杂程度， 适于实现比较复杂的查询语法规则 
存储效率 索引冗余大，索引几乎和原文一样大 索引效率高，为原文大小的30％左右 
维护成本 无词表维护成本 词表维护成本非常高：中日韩等语言需要分别维护。
还需要包括词频统计等内容 
适用领域 嵌入式系统：运行环境资源有限
分布式系统：无词表同步问题
多语言环境：无词表维护成本 对查询和存储效率要求高的专业搜索引擎 

目前比较大的搜索引擎的语言分析算法一般是基于以上2个机制的结合。关于中文的语言分析算法，大家可以在Google查关键词"wordsegment search"能找到更多相关的资料。

安装和使用

下载：http://jakarta.apache.org/lucene/

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

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

索引过程：从命令行读取文件名（多个），将文件分路径(path字段)和内容(body字段)2个字段进行存储，并对内容进行全文索引：索引的单位是Document对象，每个Document对象包含多个字段Field对象，针对不同的字段属性和数据输出的需求，对字段还可以选择不同的索引/存储字段规则，列表如下： 方法 切词 索引 存储 用途 
Field.Text(String name, String value) Yes Yes Yes 切分词索引并存储，比如：标题，内容字段 
Field.Text(String name, Reader value) Yes Yes No 切分词索引不存储，比如：META信息，
不用于返回显示，但需要进行检索内容 
Field.Keyword(String name, String value) No Yes Yes 不切分索引并存储，比如：日期字段 
Field.UnIndexed(String name, String value) No No Yes 不索引，只存储，比如：文件路径 
Field.UnStored(String name, String value) Yes Yes No 只全文索引，不存储 

public class IndexFiles {   //使用方法：: IndexFiles [索引输出目录] [索引的文件列表] ...   public static void main(String[] args) throws Exception {    String indexPath = args[0];    IndexWriter writer;    //用指定的语言分析器构造一个新的写索引器（第3个参数表示是否为追加索引）    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]);      //构造包含2个字段Field的Document对象      //一个是路径path字段，不索引，只存储      //一个是内容body字段，进行全文索引，并存储      Document doc = new Document();      doc.add(Field.UnIndexed("path", args[i]));      doc.add(Field.Text("body", (Reader) new InputStreamReader(is)));      //将文档写入索引      writer.addDocument(doc);      is.close();    };    //关闭写索引器    writer.close();  }}　
索引过程中可以看到：

语言分析器提供了抽象的接口，因此语言分析(Analyser)是可以定制的，虽然lucene缺省提供了2个比较通用的分析器SimpleAnalyser和StandardAnalyser，这2个分析器缺省都不支持中文，所以要加入对中文语言的切分规则，需要修改这2个分析器。 
Lucene并没有规定数据源的格式，而只提供了一个通用的结构（Document对象）来接受索引的输入，因此输入的数据源可以是：数据库，WORD文档，PDF文档，HTML文档……只要能够设计相应的解析转换器将数据源构造成成Docuement对象即可进行索引。 
对于大批量的数据索引，还可以通过调整IndexerWrite的文件合并频率属性（mergeFactor）来提高批量索引的效率。 
检索过程和结果显示：

搜索结果返回的是Hits对象，可以通过它再访问Document==>Field中的内容。

假设根据body字段进行全文检索，可以将查询结果的path字段和相应查询的匹配度(score)打印出来，

public class Search {   public static void main(String[] args) throws Exception {    String indexPath = args[0], queryString = args[1];    //指向索引目录的搜索器    Searcher searcher = new IndexSearcher(indexPath);    //查询解析器：使用和索引同样的语言分析器    Query query = QueryParser.parse(queryString, "body",                               new SimpleAnalyzer());    //搜索结果使用Hits存储    Hits hits = searcher.search(query);    //通过hits可以访问到相应字段的数据和查询的匹配度    for (int i=0; i<hits.length(); i++) {      System.out.println(hits.doc(i).get("path") + "; Score: " +                          hits.score(i));    };  }}
在整个检索过程中，语言分析器，查询分析器，甚至搜索器（Searcher）都是提供了抽象的接口，可以根据需要进行定制。 
Hacking Lucene

简化的查询分析器

个人感觉lucene成为JAKARTA项目后，画在了太多的时间用于调试日趋复杂QueryParser，而其中大部分是大多数用户并不很熟悉的，目前LUCENE支持的语法：

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

中间的逻辑包括：and or + - &&||等符号，而且还有"短语查询"和针对西文的前缀/模糊查询等，个人感觉对于一般应用来说，这些功能有一些华而不实，其实能够实现目前类似于Google的查询语句分析功能其实对于大多数用户来说已经够了。所以，Lucene早期版本的QueryParser仍是比较好的选择。

添加修改删除指定记录（Document）

Lucene提供了索引的扩展机制，因此索引的动态扩展应该是没有问题的，而指定记录的修改也似乎只能通过记录的删除，然后重新加入实现。如何删除指定的记录呢？删除的方法也很简单，只是需要在索引时根据数据源中的记录ID专门另建索引，然后利用IndexReader.delete(Termterm)方法通过这个记录ID删除相应的Document。

根据某个字段值的排序功能

lucene缺省是按照自己的相关度算法（score）进行结果排序的，但能够根据其他字段进行结果排序是一个在LUCENE的开发邮件列表中经常提到的问题，很多原先基于数据库应用都需要除了基于匹配度（score）以外的排序功能。而从全文检索的原理我们可以了解到，任何不基于索引的搜索过程效率都会导致效率非常的低，如果基于其他字段的排序需要在搜索过程中访问存储字段，速度回大大降低，因此非常是不可取的。

但这里也有一个折中的解决方法：在搜索过程中能够影响排序结果的只有索引中已经存储的docID和score这2个参数，所以，基于score以外的排序，其实可以通过将数据源预先排好序，然后根据docID进行排序来实现。这样就避免了在LUCENE搜索结果外对结果再次进行排序和在搜索过程中访问不在索引中的某个字段值。

这里需要修改的是IndexSearcher中的HitCollector过程：

...　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) {              /* 原先：Lucene将docID和相应的匹配度score例入结果命中列表中：        * hq.put(new ScoreDoc(doc, score));   // update hit queue               * 如果用doc 或 1/doc 代替 score，就实现了根据docID顺排或逆排               * 假设数据源索引时已经按照某个字段排好了序，而结果根据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());
更通用的输入输出接口

虽然lucene没有定义一个确定的输入文档格式，但越来越多的人想到使用一个标准的中间格式作为Lucene的数据导入接口，然后其他数据，比如PDF只需要通过解析器转换成标准的中间格式就可以进行数据索引了。这个中间格式主要以XML为主，类似实现已经不下4，5个：

数据源: WORD       PDF     HTML    DB       other         \          |       |      |         /                       XML中间格式                            |                     Lucene INDEX
目前还没有针对MSWord文档的解析器，因为Word文档和基于ASCII的RTF文档不同，需要使用COM对象机制解析。这个是我在Google上查的相关资料：http://www.intrinsyc.com/products/enterprise_applications.asp
另外一个办法就是把Word文档转换成text：http://www.winfield.demon.nl/index.html


索引过程优化

索引一般分2种情况，一种是小批量的索引扩展，一种是大批量的索引重建。在索引过程中，并不是每次新的DOC加入进去索引都重新进行一次索引文件的写入操作（文件I/O是一件非常消耗资源的事情）。

Lucene先在内存中进行索引操作，并根据一定的批量进行文件的写入。这个批次的间隔越大，文件的写入次数越少，但占用内存会很多。反之占用内存少，但文件IO操作频繁，索引速度会很慢。在IndexWriter中有一个MERGE_FACTOR参数可以帮助你在构造索引器后根据应用环境的情况充分利用内存减少文件的操作。根据我的使用经验：缺省Indexer是每20条记录索引后写入一次，每将MERGE_FACTOR增加50倍，索引速度可以提高1倍左右。

搜索过程优化


lucene支持内存索引：这样的搜索比基于文件的I/O有数量级的速度提升。
http://www.onjava.com/lpt/a/3273
而尽可能减少IndexSearcher的创建和对搜索结果的前台的缓存也是必要的。


Lucene面向全文检索的优化在于首次索引检索后，并不把所有的记录（Document）具体内容读取出来，而起只将所有结果中匹配度最高的头100条结果（TopDocs）的ID放到结果集缓存中并返回，这里可以比较一下数据库检索：如果是一个10,000条的数据库检索结果集，数据库是一定要把所有记录内容都取得以后再开始返回给应用结果集的。所以即使检索匹配总数很多，Lucene的结果集占用的内存空间也不会很多。对于一般的模糊检索应用是用不到这么多的结果的，头100条已经可以满足90%以上的检索需求。

如果首批缓存结果数用完后还要读取更后面的结果时Searcher会再次检索并生成一个上次的搜索缓存数大1倍的缓存，并再重新向后抓取。所以如果构造一个Searcher去查1－120条结果，Searcher其实是进行了2次搜索过程：头100条取完后，缓存结果用完，Searcher重新检索再构造一个200条的结果缓存，依此类推，400条缓存，800条缓存。由于每次Searcher对象消失后，这些缓存也访问那不到了，你有可能想将结果记录缓存下来，缓存数尽量保证在100以下以充分利用首次的结果缓存，不让Lucene浪费多次检索，而且可以分级进行结果缓存。

Lucene的另外一个特点是在收集结果的过程中将匹配度低的结果自动过滤掉了。这也是和数据库应用需要将搜索的结果全部返回不同之处。

我的一些尝试：

支持中文的Tokenizer：这里有2个版本，一个是通过JavaCC生成的，对CJK部分按一个字符一个TOKEN索引，另外一个是从SimpleTokenizer改写的，对英文支持数字和字母TOKEN，对中文按迭代索引。 
基于XML数据源的索引器：XMLIndexer，因此所有数据源只要能够按照DTD转换成指定的XML，就可以用XMLIndxer进行索引了。 
根据某个字段排序：按记录索引顺序排序结果的搜索器：IndexOrderSearcher，因此如果需要让搜索结果根据某个字段排序，可以让数据源先按某个字段排好序（比如：PriceField），这样索引后，然后在利用这个按记录的ID顺序检索的搜索器，结果就是相当于是那个字段排序的结果了。 
从Lucene学到更多

Luene的确是一个面对对象设计的典范

所有的问题都通过一个额外抽象层来方便以后的扩展和重用：你可以通过重新实现来达到自己的目的，而对其他模块而不需要； 
简单的应用入口Searcher, Indexer，并调用底层一系列组件协同的完成搜索任务； 
所有的对象的任务都非常专一：比如搜索过程：QueryParser分析将查询语句转换成一系列的精确查询的组合(Query),通过底层的索引读取结构IndexReader进行索引的读取，并用相应的打分器给搜索结果进行打分/排序等。所有的功能模块原子化程度非常高，因此可以通过重新实现而不需要修改其他模块。 
除了灵活的应用接口设计，Lucene还提供了一些适合大多数应用的语言分析器实现（SimpleAnalyser,StandardAnalyser），这也是新用户能够很快上手的重要原因之一。 
这些优点都是非常值得在以后的开发中学习借鉴的。作为一个通用工具包，Lunece的确给予了需要将全文检索功能嵌入到应用中的开发者很多的便利。

此外，通过对Lucene的学习和使用，我也更深刻地理解了为什么很多数据库优化设计中要求，比如：

尽可能对字段进行索引来提高查询速度，但过多的索引会对数据库表的更新操作变慢，而对结果过多的排序条件，实际上往往也是性能的杀手之一。 
很多商业数据库对大批量的数据插入操作会提供一些优化参数，这个作用和索引器的merge_factor的作用是类似的， 
20%/80%原则：查的结果多并不等于质量好，尤其对于返回结果集很大，如何优化这头几十条结果的质量往往才是最重要的。 
尽可能让应用从数据库中获得比较小的结果集，因为即使对于大型数据库，对结果集的随机访问也是一个非常消耗资源的操作。 
参考资料：

Apache: Lucene Project
http://jakarta.apache.org/lucene/
Lucene开发/用户邮件列表归档
Lucene-dev@jakarta.apache.org
Lucene-user@jakarta.apache.org

The Lucene search engine: Powerful, flexible, and free
http://www.javaworld.com/javaworld/jw-09-2000/jw-0915-Lucene_p.html

Lucene Tutorial
http://www.darksleep.com/puff/lucene/lucene.html

Notes on distributed searching with Lucene
http://home.clara.net/markharwood/lucene/

中文语言的切分词
http://www.google.com/search?sourceid=navclient&hl=zh-CN&q=chinese+word+segment

搜索引擎工具介绍
http://searchtools.com/

Lucene作者Cutting的几篇论文和专利
http://lucene.sourceforge.net/publications.html

Lucene的.NET实现：dotLucene
http://sourceforge.net/projects/dotlucene/


Lucene作者Cutting的另外一个项目：基于Java的搜索引擎Nutch
http://www.nutch.org/ http://sourceforge.net/projects/nutch/


关于基于词表和N-Gram的切分词比较
http://china.nikkeibp.co.jp/cgi-bin/china/news/int/int200302100112.html]]> http://www.xd-tech.com.cn/blog/default.asp?id=62 <![CDATA[使用站内检索的五大理由]]> jaddy0302@126.com(christian) Fri,07 Dec 2007 13:35:03 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=62         本文主要介绍站内检索对internet网站的五大作用：所寻即所得；了解访问者的意图；符合网民的习惯；提升网站信息的价值；身份的象征。最后介绍目前的网际搜索引擎不能替代站内检索的原因。

 


自从有了计算机以后，人类开始用计算机保存信息，有保存，就有查找，于是检索技术诞生了。文本检索技术的发展从最初的SMART文档检索系统[1]到Altavista搜索引擎，到现在的搜索巨头Google[2]，其发展可谓日新月异、与时具进，人们开始习惯互联网的搜索时代，站内检索的需求也逐渐显露出来。下面列举需要站内检索的五大理由：


 


一、所寻即所得。


信息量总在不断增长，而访问者的耐心却逐渐下降。据统计，每需要多点击一次鼠标，就有三分之一的用户选择放弃。这意味着100个访问者进入我们的网站，如果需要点击三次鼠标才能找到所需要的东西，那么就只剩下不到4个人了。根据第十一次中国互联网信息调查表明，53.1%的人上网是为了获取信息[3]，大部分网站的目的是让外界了解自己，了解的人越多，效果就越好。把访问者最想要的返回给用户，就可让更多的用户了解自己，这样站内检索成为必然选择。


 


二、了解访问者的意图。

 


管理大师彼得.德鲁克说：“一定要知道你的客户想要什么？”客户的需求永远都是最重要的，因此我们总在分析我们的客户在哪里及他们需要什么。所有访问我们网站的人都可能是我们的潜在客户，了解他们的意图对于我们做决策很重要。站内检索技术可以实现这个功能，站内检索的日志功能可以记录每个访问者的检索词和检索结果，这是访问者意图的最直接的表现。通过分析这些信息，我们还可以调整网站结构，把访问者最想要的放在明显的位置（了解我们的人就多啦）。这个理由经常被人忽视，我在这里放在第二位也是希望引起大家重视，特别是那些已经使用站内检索的网站所有者。


 


三、  符合网民习惯。

 


根据调查表明，68.3％的上网者经常使用搜索引擎[3]。大部分人已经习惯通过检索来找到他们想要的东西，而不是按照某个栏目一级一级往下找(我就很少用yahoo的分类目录）。在网站内访问者要是没看见那熟悉的按钮会多少有些不习惯（我们千万不要让上帝感到不习惯）。在心理学角度讲，人们如果对某个事物不习惯很容易产生厌烦情绪，这也就是为什么你第一次去某个地方会觉得特别远，要是路熟了这种感觉就消失了。看来，为了上帝我们也需要使用站内检索。


 


四、  提升网站信息价值。

 


我们经常会发生这样的事情：明明记得有一篇写关于吃香辣虾的文件，就是想不起存放在什么地方了。访问者也有类似困扰，只记得某个网站上说了关于张国荣跳楼的消息，但不知道具体的链接在哪里。另外，要是隐藏在目录很深的html文档可能自从网站建立到整个网站关闭也没有一个人看过，这些都不是我们所想要的。站内检索毫无疑问可以解决上述问题。同时，按照一个主题把所有相关文档提供给访问者，可以让访问者更全面的了解他所想要的东西，这增加了网站信息间的组织性和逻辑性，方便了访问者的使用，提升用户体验度（用户体验度：一个让我们忐忑不安的名词）。


 


五、 身份的象征。

 


有没有站内检索其实已经不只是用户体验度的问题了，还是一个网站专业身份的象征。浏览国外公司的网站，会发现几乎所有网站都在首页最明显的区域放置了一个搜索框，这传达的信息是：专业的网站都有站内检索（呵呵，我没说国外网站就是专业网站）。网民的心态是：我用不用，你管不着，你要是没有就说明你不够专业。为了树立形象，也需要使用站内检索。


 


最后还得解释一个问题：为什么有了搜索引擎还需要站内检索？用网际搜索引擎不是直接可以查到吗？这其中有两个问题：1 搜索羽毛球，你会搜索到235,000个网页[4]，也不知道我公司的排在第10,000页还是10,001页，搜索者可能永远也不会去看。2 搜索引擎通过网络Spider收集网页，对于网站内隐藏很深的网页很难索引到的。

]]> http://www.xd-tech.com.cn/blog/default.asp?id=61 <![CDATA[站内搜索引擎之比较〔转〕]]> jaddy0302@126.com(christian) Fri,07 Dec 2007 12:02:43 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=61 关键词：站内搜索


     有很多网站都在网页上加个“站内搜索引擎”、“搜索引擎”、“全文检索”等等相关字样。
     用户一用，结果发现，既不能多关键组合查询，也不能支持国际语法，甚至不能支持全文检索，就更别谈不支持相关性排序等真正的搜索引擎具备的功能了。这些搜索和真正的站内搜索引擎有和区别呢？
     真正的全文检索应具备 相关性排序技术 和 分词索引功能。 如果需要进行互联网的信息抓取和采集那么还需要网络蜘蛛模块。 分词、索引、排序这是全文检索的基本和核心，缺一不可。全文检索至少需要具备中文分词、索引、相关性排序功能。
     所以简单考查一个站内搜索引擎的真伪只需要知道：能否实现相关性排序、国际标准的搜索语法、动态摘要、飘红、支持海量数据多并快速发查询、搜索耗时极短。
（当然这只是全文检索的基本内容，一个全文检索的搜索引擎的品质好坏还和相关的技术水平、各种技术的结合、产品的管理有很大关系。 评价全文检索的标准是用户体验度，今后我们会提供相关方面的内容）


常用的站内搜索技术比较：


　 基于数据库的搜索 基于spider抓取的站内搜索 全文检索者站内搜索软件系统
原理 数据库搜索 通过Spider抓取网页，经html解析，分词，索引实现网页式站内搜索。 对数据库数据进行html解析、图片缩略，分词，索引，实现站内搜索。
检索效率 非常低下 消耗大量硬件资源 高效 高效
检索范围 无法完成全文检索（可以用sql的单字索引功能最简单的完成索引功能实现最低级的全文检索），只能进行标题检索。 数据库效率太低，无法开展各种附加功能。 网页检索 优点：不需要做各种工作，直接即可使用 缺点： 1.有大量的不必要的信息影响搜索结果的排序和显示的效果。严重影响精确度。 2.部分页面无法抓取到。 3.用户对搜索范围和内容以及体现的结果无法精确控制 标题＋内容 基于内容分析的排序方法。基于内容分析排序是最佳的排序方法。 标题和内容可控制，搜索结果准确到位。 内容可控，用户可对搜索的内容范围和体现的结果进行精确的控制
检索语法 无 支持标准的国际搜索语法。 支持标准的国际搜索语法。
动态摘要 无 摘要内容不清晰各种垃圾信息过多 提供动态摘要，摘要清晰精确，便于用户快速寻找到需要的信息。
关键词飘红 无 有 有
内容的范围 可控制 不可有效控制，动态网页抓取效果不佳，没有链接的网页无法抓取，页面出现杂乱信息影响搜索结果。对于时间控制也无法做到精准，对于栏目的归属无法做到准确。 可有效控制，您可以把多个字段拆分合并，可以确定那些需要，哪些不需要。所有动态网页和没有链接的网页均可有效收入。 栏目控制精准。
图片缩略 无 无 有
同义词 无 无 有
相关性排序 无 有 有
其他 低效率低质量的平台无法开展增值服务 二次研发成本高 具有持续不断的升级能力和良好的售后服务。
成本 低 价格高 以产品形式运作，多家客户分摊成本，成本相对低廉。运维成本低。
维护成本  不大 维护量不大。 程序维护无须投入，但是需要进行一定量的内容维护。 经过简单培训即可胜任。
]]> http://www.xd-tech.com.cn/blog/default.asp?id=60 <![CDATA[Windows 下运行Hadoop的脚本]]> jaddy0302@126.com(admin) Wed,10 Oct 2007 22:22:27 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=60 将以下文本内容存放入HADOOP_HOME\bin 目录下 ， 命名为hadoop.bat，将set HADOOP_HOME=C:\work\hadoop 修改为HADOOP存放的目录，设置一下JAVA_HOME，然后命令行进入 HADOOP_HOME\bin 目录下 ，运行 hadoop 就可以看到效果了。
需要注意的是 Hadoop 运行datanode 的时候，它使用了 Runtime 执行操作系统命令 df -k 来获得存储空间信息，而windows 下是不支持这个命令的，所以需要修改一下org.apache.hadoop.fs.DF.java 的 141 行左右如下：

  private String[] getExecString() {
    return new String[] {"df","-k", dirPath};
  }

把这个命令改掉后编译打包就OK了

@echo off
set JAVA_HEAP_MAX="-Xmx1000m"
set JAVA=$JAVA_HOME/bin/java

if not "%1"=="" goto INIT else goto echoMSG
:echoMSG 
  echo Title:欢迎使用北京线点科技 Hadoop 运行脚本
  echo Author:jaddy0302 mail:jaddy0302@126.com QQ:5622928
  echo Site:http://www.xd-tech.com.cn 线点科技 专业垂直搜索引擎产品
  echo Usage: hadoop [--config confdir] COMMAND
  echo where COMMAND is one of:
  echo   namenode -format     format the DFS filesystem
  echo   secondarynamenode    run the DFS secondary namenode
  echo   namenode             run the DFS namenode
  echo   datanode             run a DFS datanode
  echo   dfsadmin             run a DFS admin client
  echo   fsck                 run a DFS filesystem checking utility
  echo   fs                   run a generic filesystem user client
  echo   jobtracker           run the MapReduce job Tracker node
  echo   pipes                run a Pipes job
  echo   tasktracker          run a MapReduce task Tracker node
  echo   job                  manipulate MapReduce jobs
  echo   version              print the version
  echo   jar jar            run a jar file
  echo   distcp srcurl desturl copy file or directories recursively
  echo  or
  echo   CLASSNAME            run the class named CLASSNAME
  echo Most commands print help when invoked w/o parameters.
  goto end;
:INIT 
  set HADOOP_HOME=C:\work\hadoop
  if "%HADOOP_HOME%"=="" set HADOOP_HOME=.. 
  set CLASSPATH=%HADOOP_HOME%;%HADOOP_HOME%\conf;%JAVA_HOME%/lib/tools.jar;
  set HADOOP_LOG_DIR=%HADOOP_HOME%/logs
  set HADOOP_LOGFILE=hadoop.log
  @echo @echo off>setclasspath.bat
  for %%i in (%HADOOP_HOME%\hadoop-*.jar) do @echo set CLASSPATH=%%CLASSPATH%%%%i>>setclasspath.bat;
  for %%i in (%HADOOP_HOME%\lib\*.jar) do @echo set CLASSPATH=%%CLASSPATH%%%%i>>setclasspath.bat;
  for %%i in (%HADOOP_HOME%\lib\jetty-ext\*.jar) do @echo set CLASSPATH=%%CLASSPATH%%%%i>>setclasspath.bat;
  goto EXEC
:EXEC
  call setclasspath.bat
  if  "%1" == "namenode" set CLASS=org.apache.hadoop.dfs.NameNode
  if  "%1" == "secondarynamenode" set CLASS=org.apache.hadoop.dfs.SecondaryNameNode
  if  "%1" == "datanode" set  CLASS=org.apache.hadoop.dfs.DataNode
  if  "%1" == "fs" set  CLASS=org.apache.hadoop.fs.FsShell
  if  "%1" == "dfs" set  CLASS=org.apache.hadoop.fs.FsShell
  if  "%1" == "dfsadmin" set  CLASS=org.apache.hadoop.dfs.DFSAdmin
  if  "%1" == "fsck" set  CLASS=org.apache.hadoop.dfs.DFSck
  if  "%1" == "jobtracker" set  CLASS=org.apache.hadoop.mapred.JobTracker
  if  "%1" == "tasktracker" set  CLASS=org.apache.hadoop.mapred.TaskTracker
  if  "%1" == "job" set  CLASS=org.apache.hadoop.mapred.JobClient
  if  "%1" == "pipes" set  CLASS=org.apache.hadoop.mapred.pipes.Submitter
  if  "%1" == "version" set  CLASS=org.apache.hadoop.util.VersionInfo
  if  "%1" == "jar" set  CLASS=org.apache.hadoop.util.RunJar
  if  "%1" == "distcp" set  CLASS=org.apache.hadoop.util.CopyFiles
goto SPLI
:SPLI
  set HADOOP_OPTS=
  set HADOOP_OPTS=%HADOOP_OPTS% -Dhadoop.log.dir=%HADOOP_LOG_DIR%
  set HADOOP_OPTS=%HADOOP_OPTS% -Dhadoop.log.file=%HADOOP_LOGFILE%
  set HADOOP_OPTS=%HADOOP_OPTS% -Dhadoop.home.dir=%HADOOP_HOME%
  set HADOOP_OPTS=%HADOOP_OPTS% -Dhadoop.id.str=%HADOOP_IDENT_STRING%
  call "%JAVA_HOME%\bin\java" %JAVA_HEAP_MAX% %HADOOP_OPTS% -classpath "%CLASSPATH%" %CLASS% %2 %3 %4 %5 %6 %7 %8 %9
  rem if "%ERRORLEVEL%" == "1" goto SPLI else goto end 
:end

]]> http://www.xd-tech.com.cn/blog/default.asp?id=59 <![CDATA[网络语料正文的识别/抽取规则 标签密度判定法]]> jaddy0302@126.com(admin) Wed,08 Aug 2007 16:57:05 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=59 在确定了对不同的URL进行的不同的操作之后，自然就进入到了本软件的核心部分：如何判定HTML源码中，哪一部分是正文。只有确定了正文部分，才能够确定操作集中的对象，才能够进行抽取。

在各种网络文本中，最容易获得的，就是网络新闻之类。这类文章，甚至包括很多的非新闻类的网上文章，特点都是具有一个标题，这个标题一般会放在正文开头在<h1> </h1>标签中，有些网站也会放在<title> </title>标签中；另外，在一般的网上文章中，正文往往都是用<p> </p>来进行段落划分。同时，正文成分在网页源代码中，分布往往较为集中。因此，本文提出一种正文判定法则，即标签密度判定法，即，首先判断一个<p> </p>代码块中的标签密度，如果低于某一阈值，就认为其标签含量很低，是正文的可能性就比较大。下面举两个例子来论证标签密度是否能成为判定正文的标准：代码片段A是一篇新闻网页的源码中，正文部分的Fragment，而代码片段B，则是非正文部分的Fragment。这两段网页源代码，是随机地从某一搜索引擎结果集中抽取的，因而具有相当的代表性：

 

<P>　　对于吉林石化爆炸污染松花江水源的说法，吉林省委宣传部表示目前还没有听说这个情况。吉林市市委宣传处一位人士更是表示，由于哈尔滨处于松花江下游，哈尔滨多年来一直抓住水指标的问题，作水污染的文章，这次停水是否因为吉林石化爆炸所导致还不好说。他告诉记者，自11月14日下午开始，吉林市松花江江北在恢复供水后一直保持正常。

</P>

<P>　　吉林石化方面人士强调，爆炸产生的是二氧化碳和水，绝对不会污染到水源，而吉林石化也有自己的污水处理厂，不合格的污水是不会排放到松花江的。本报记者翟宇许

金晶王婷婷 发自哈尔滨 北京<A href="http://weather.qq.com/preend.htm?dc80.htm"

target=_blank> <IMG alt=点击查看北京及更多城市天气预报

src="http://weather.qq.com/images/endnew/weather_icon.gif"

border=0> </A> </P>

 

图3-1 代码片段A，从某HTML页面源文件中摘取的片断

 

 

<DD class="nadlinkB  marginupdown"> <!--广告 -->

  <DD class=focus>

  <DIV class="focustit px14">焦点关注 </DIV>

  <DD class=foucscnt>

  <DIV class=foucscnt1> <A href="http://news.qq.com/a/20051124/000309.htm"

  target=new> <IMG class=marginupdown height=88 alt="交友广告在高校派发 寻伊启事专盯单身美女"

  src="http://img1.qq.com/news/20051124/2719358.jpg" width=130

  border=1> </A> <BR>交友广告专盯单身美女<BR> <BR> <A

  href="http://ent.qq.com/a/20051124/000048.htm" target=new> <IMG

  class= marginupdown height=88 src="http://img1.qq.com/ent/20051124/2720851.jpg"

  width=130 border=0> </A> <BR> 怀孕王菲遭媒体“围堵”<BR> </DIV>

  <DIV class=foucscnt2> · <A href="http://news.qq.com/a/20051120/000704.htm"

  target=_blank> 小泉谈中日关系 称不担心中日交恶(图) </A> <BR> · <A

  href="http://news.qq.com/a/20051119/000757.htm" target=_blank> 戒毒所警察强奸女生被判10年

  不服判决 </A> <BR> · <A href="http://news.qq.com/a/20051118/001595.htm"

  target=_blank> 甘肃省委宣传部原副部长石星光遇害< /A> <BR> · <A

  href="http://news.qq.com/a/20051116/001154.htm" target=_blank> 按下劫警键五分钟获救

  新版GPS救下的姐命 </A> <BR> · <A href="http://news.qq.com/a/20051110/001447.htm"

  target=new>全国中小学后勤工作论坛上鼾声一片(组图) </A> <BR> · <A

  href="http://news.qq.com/a/20051110/000472.htm" target=_blank> 孕妇被打流产索赔81万

  被告提异议 </A> <BR> <BR> · <A href="http://news.qq.com/a/20051124/000469.htm"

  target=new> 女子结婚3年未孕 医院检查才知是男儿身 </A> <BR> · <A

  href="http://news.qq.com/a/20051124/000540.htm" target=new> 变性美女返家

  3万乡亲敲锣打鼓迎接(图) </A> <BR> · <A href="http://news.qq.com/a/20051124/000833.htm"

  target=new> 女教师多次性骚扰14岁男生被判软禁(图) </A> <BR> · <A

  href="http://news.qq.com/a/20051119/000154.htm"

  target=new> 网络工程师网上散发前女友裸照(图) </A> <BR> · <A

  href="http://news.qq.com/a/20051110/001756.htm"

  target=new> 丈夫迷网络色情与老婆演淫秽真人秀(图) </A> <BR> </DIV>

  <DIV class=foucscnt3> <A href="http://sports.qq.com/a/20051124/000243.htm"

  target=new> <IMG class=marginupdown height=88 alt=鲁尼偷腥事件女主角裸照

  src="http://img1.qq.com/sports/20051124/2720121.jpg"

  width=130> </A> <BR> 鲁尼偷腥事件女主角裸照 <BR> <BR> <A

  href="http://news.qq.com/a/20051124/001281.htm" target=new> <IMG

  class=marginupdown height=88 alt="千万富豪驾宝马高校征婚 传单散10所高校"

  src="http://img1.qq.com/news/20051124/2723345.jpg" width=130

border=1> </A> <BR> 千万富豪驾宝马高校征婚 <BR> </DIV>

 

图3-2 代码片段B，从同一HTML页面源文件中摘取的片断

 

 

这代码片段A指示的就是我们要提取的正文。如何把这样的代码，与代码段B这样的代码区分开呢？首先从语言内容角度是行不通的，目前电脑很难理解自然语言；也不能从是否是超级链接入手，前面已经说了，正文中有时也会出现不能随意整个去除的超级链接，必须判断出哪里是正文，才能对正文中的超级链接进行处理。笔者在这个问题上也曾徘徊很久，最后的突破在于寻找到了这样一个规律：正文部分的HTML标签密度，远远大于非正文部分。为了验证这个规律，我们统计分析一下上面的两个例子（HTML标签：这里指所有在HTML源代码中出现的，尖括号（<>）中的内容，每对尖括号，连同其内容，算作一个标签，每个类似于<html> </html>的两个标签，其中一个标示标签内容开始，另一个标志标签内容结束的，称为一个标签对。）：

代码片段A的统计分析：

 

正文字数：242字（正文字数： 指的是非标签的文本字数，标点符号计在内。）

标签数：7个（标签数：只计算标签的个数，忽略标签内文本的多少。）

标签密度：28.93个/千字（标签密度：指的是前面定义的标签数与正文数的商，单位规定为“个/千字”，计算公式为“标签密度=1000*标签数/字数”。）

代码片段B的统计分析：

 

正文字数（非标签文本）：221字

标签数：69个

标签密度：312.22个/千字

从上面的两组统计数据可以看出，网络文本源代码中，正文部分的HTML标签密度远远小于非正文部分，同时，对于更多的网络文本的统计数据分析可以知道，按照上文的方法所算出的标签密度，正文部分与非正文部分，存在着极大的差异。从而我们可以得出初步结论：可以依据对HTML标签密度的统计分析来指出在一份HTML源代码中，文章正文的位置。

于是，在对更多的文本进行类似的统计后，笔者得出一个正式的统计的结论，正文部分的HTML标签密度大于50个/千字的概率接近于零，而非正文部分的标签密度小于200个/千字的机率也几乎为零。所以，理论上，在50个/千字和200个/千字这个统计得出标签密度数据的“真空区”中选择任何一个数值作为正文与非正文部分的分界线都是可以的。但是，为了保证不遗漏正文（不遗漏正文：对于标注对象来说，正文的缺失是难以接受的，而少量的冗余资料则被认为是对工作无害的。所以，在提取正文时，宁可放行一些无用的资料，也不能把丝毫的正文过滤掉），笔者建议选择的分界值是150个/千字（150个/千字：这是针对网络新闻资料得出的建议分界值，可能并不适用于其他类型的资料）。当然，在其后的设计分析中，我们可以知道，对于不同网站的文本语料，存在不同的设计风格差异，体现在源码上，就是正文部分与非正文部分的标签密度存在一定的波动。我们可以通过对这个阈值进行调整，来达到最适合的抽取精度。当然，在软件中，会存在一个Scroll Bar，对这个阈值进行调整。

]]> http://www.xd-tech.com.cn/blog/default.asp?id=58 <![CDATA[Windows 下运行Nutch批处理脚本]]> jaddy0302@126.com(admin) Wed,25 Jul 2007 22:00:55 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=58 将以下文本内容存放入NUTCH_HOME\bin 目录下 ， 命名为nutch.bat，设置以下JAVA_HOME 和 NUTCH_HOME，然后在命令行运行 %NUTCH_HOME%\bin\nutch

 @echo off
set JAVA_HEAP_MAX="-Xmx512M"
if not "%1"=="" goto INIT else goto echoMSG
:echoMSG
  echo Title:欢迎使用北京线点科技 Nutch 运行脚本
  echo Author:jaddy0302 mail:jaddy0302@126.com QQ:5622928
  echo Site:http://www.xd-tech.com.cn 线点科技 专业垂直搜索引擎产品
  echo Nutch Version: 0.7.2
  echo Usage: nutch COMMAND
  echo where COMMAND is one of:
  echo   crawl             one-step crawler for intranets
  echo   admin             database administration, including creation
  echo   inject            inject new urls into the database
  echo   generate          generate new segments to fetch
  echo   fetchlist         print the fetchlist of a segment
  echo   fetch             fetch a segment's pages
  echo   parse             parse a segment's pages
  echo   index             run the indexer on a segment's fetcher output
  echo   merge             merge several segment indexes
  echo   dedup             remove duplicates from a set of segment indexes
  echo   updatedb          update db from segments after fetching
  echo   updatesegs        update segments with link data from the db
  echo   mergesegs         merge multiple segments into a single segment
  echo   readdb            examine arbitrary fields of the database
  echo   analyze           adjust database link-analysis scoring
  echo   prune             prune segment index(es) of unwanted content
  echo   segread           read, fix and dump segment data
  echo   segslice          append, join and slice segment data
  echo   server            run a search server
  echo   namenode          run the NDFS namenode
  echo   datanode          run an NDFS datanode
  echo   ndfs              run an NDFS admin client
  echo   jobtracker        run the MapReduce job Tracker node
  echo   tasktracker       run a MapReduce task Tracker node
  echo  or
  echo   CLASSNAME         run the class named CLASSNAME
  echo Most commands print help when invoked w/o parameters.
  goto end;
:INIT 
  set NUTCH_HOME=C:\work\nutch-0.7.2
  if "%NUTCH_HOME%"=="" set NUTCH_HOME=.. 
  set CLASSPATH=%NUTCH_HOME%;%NUTCH_HOME%\conf;%NUTCH_HOME%\plugin
  @echo @echo off>setclasspath.bat
  for %%i in (%NUTCH_HOME%\nutch-*.jar) do @echo set CLASSPATH=%%CLASSPATH%%;%%i>>setclasspath.bat;& for %%i in (%NUTCH_HOME%\lib\*.jar) do @echo set CLASSPATH=%%CLASSPATH%%;%%i>>setclasspath.bat;
  goto EXEC
:EXEC
  call setclasspath
  if  "%1" == "crawl" set CLASS=org.apache.nutch.tools.CrawlTool
  if  "%1" == "admin" set CLASS=org.apache.nutch.tools.WebDBAdminTool
  if  "%1" == "inject" set CLASS=org.apache.nutch.db.WebDBInjector
  if  "%1" == "generate" set CLASS=org.apache.nutch.tools.FetchListTool
  if  "%1" == "fetchlist" set CLASS=org.apache.nutch.pagedb.FetchListEntry
  if  "%1" == "fetch" set CLASS=org.apache.nutch.fetcher.Fetcher
  if  "%1" == "parse" set CLASS=org.apache.nutch.tools.ParseSegment
  if  "%1" == "index" set CLASS=org.apache.nutch.indexer.IndexSegment
  if  "%1" == "merge" set CLASS=org.apache.nutch.indexer.IndexMerger
  if  "%1" == "dedup" set CLASS=org.apache.nutch.indexer.DeleteDuplicates
  if  "%1" == "updatedb" set CLASS=org.apache.nutch.tools.UpdateDatabaseTool
  if  "%1" == "updatesegs" set CLASS=org.apache.nutch.tools.UpdateSegmentsFromDb
  if  "%1" == "mergesegs" set CLASS=org.apache.nutch.tools.SegmentMergeTool
  if  "%1" == "readdb" set CLASS=org.apache.nutch.db.WebDBReader
  if  "%1" == "prune" set CLASS=org.apache.nutch.tools.PruneIndexTool
  if  "%1" == "segread" set CLASS=org.apache.nutch.segment.SegmentReader
  if  "%1" == "segslice" set CLASS=org.apache.nutch.segment.SegmentSlicer
  if  "%1" == "analyze" set CLASS=org.apache.nutch.tools.LinkAnalysisTool
  if  "%1" == "server" set CLASS=org.apache.nutch.searcher.DistributedSearch$Server
  if  "%1" == "namenode" set CLASS=org.apache.nutch.ndfs.NDFS$NameNode
  if  "%1" == "datanode" set CLASS=org.apache.nutch.ndfs.NDFS$DataNode
  if  "%1" == "ndfs" set CLASS=org.apache.nutch.fs.TestClient
  if  "%1" == "jobtracker" set CLASS=org.apache.nutch.mapReduce.JobTracker
  if  "%1" == "tasktracker" set CLASS=org.apache.nutch.mapReduce.TaskTracker
  call "%JAVA_HOME%\bin\java" %JAVA_HEAP_MAX% -classpath "%CLASSPATH%" %CLASS% %2 %3 %4 %5 %6 %7 %8 %9
:end

 

]]> http://www.xd-tech.com.cn/blog/default.asp?id=57 <![CDATA[搜索引擎重复网页发现技术分析]]> jaddy0302@126.com(admin) Tue,10 Jul 2007 17:55:58 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=57
统计结果表明，近似镜像网页数占总网页数的比例高达全部页面的29%,而完全相同的页面大约占全部页面的22%。这些重复网页有的是没有一点改动的拷贝，有的在内容上稍作修改，比如同一文章的不同版本，一个新一点，一个老一点，有的则仅仅是网页的格式不同（如 HTML, Postscript）,文献[Models and Algorithms for Duplicate Document Detection 1999年]将内容重复归结为以下四个类型:

1.如果2篇文档内容和格式上毫无差别，则这种重复叫做full-layout duplicate。

2.如果2篇文档内容相同，但是格式不同，则叫做full-content duplicates

3.如果2篇文档有部分重要的内容相同，并且格式相同，则称为partial-layout duplicates

4.如果2篇文档有部分重要的内容相同，但是格式不同，则称为partial-content duplicates

近似重复网页发现技术就是通过技术手段快速全面发现这些重复信息的手段.如何快速准确地发现这些内容上相似的网页已经成为提高搜索引擎服务质量的关键技术之一。发现重复或者近似网页对于搜索引擎有很多好处:

1.       首先，如果我们能够找出这些重复网页并从数据库中去掉，就能够节省一部分存储空间，进而可以利用这部分空间来存放更多的有效网页内容，同时也提高了web检索的质量。

2.       其次，如果我们能够通过对以往搜集信息的分析，预先发现重复网页，在今后的网页搜集过程中就可以避开这些网页，从而提高有效网页的搜集速度。有研究表明重复网页随着时间级别不发生太大变化,所以这种从重复页面集合中选择部分页面进行索引是有效的.

3.       另外，如果某个网页的镜像度较高，也就预示着该网页相对重要，在搜集网页时应赋予它较高的优先级，而当搜索引擎系统在响应用户的检索请求并对输出结果排序时，应该赋予它较高的权值。

4.       从另外一个角度看,如果用户点击了一个死链接,那么可以将用户引导到一个相同页面,这样可以有效的增加用户的检索体验.因而近似镜像网页的及时发现有利于改善搜索引擎系统的服务质量。



二. 基本处理流程

通过分析现有技术,可以归纳出以下几个解决该问题的核心技术点,每个不同的技术基本上是由这几个技术点构成,无非是具体采纳的技术不同而已:



1.   文档对象的特征抽取:将文档内容分解,由若干组成文档的特征集合表示,这一步是为了方面后面的特征比较计算相似度.

2.   特征的压缩编码:通过HASH编码等文本向数字串映射方式以方便后续的特征存储以及特征比较.起到减少存储空间,加快比较速度的作用.

3.   文档相似度计算:根据文档特征重合比例来确定是否重复文档.

4.   聚类算法:通过叠代计算算出哪些文档集合是根据相似度计算是相近的;

5.   工程化问题:出于海量数据计算速度的考虑,提出一些速度优化算法以使得算法实用化.



我们可以从几个不同的角度对于现有的方法进行分类:

l   按照利用的信息，现有方法可以分为以下三类

1．只是利用内容计算相似

2．结合内容和链接关系计算相似

3．结合内容，链接关系以及url文字进行相似计算

评价:现有绝大部分方法还是利用文本内容进行相似识别,其它两种利用链接关系以及URL文字的方法还不是很成熟,而且从效果看引入其它特征收效并不明显,所以从实际出发还是选择利用内容进行相似计算的算法.



l   按照特征提取的粒度现有方法可以分为以下三类

1.   按照单词这个级别的粒度进行特征提取.

2.   按照SHINGLE这个级别的粒度进行特征提取.SHNGLE是若干个连续出现的单词,级别处于文档和单词之间,比文档粒度小,比单词粒度大.

3.   按照整个文档这个级别的粒度进行特征提取

评价:

目前这个领域里面很多工作借鉴类似于信息检索的方法来识别相似文档,其本质和SHINGLE等是相同的，都是比较两个文档的重合程度，但是区别是SHINGLE是将若干单词组成片断，粒度比较大，而信息检索类方法其实是用单词作为比较粒度，粒度比较小，粒度越大计算速度越快，而粒度越小计算速度越慢，所以信息检索类方法是不实用的，而且对SHINGLE的改进以及新提出的方法的发展趋势也是粒度越来越大，这样才能解决实际使用中速度的问题。粒度最大的极端情况是每个文档用一个HASH函数编码（比如MD5），这样只要编码相同就说明文档完全相同，但是粒度太大带来的问题是对于细微的变化文档无法判别，只能判断是否完全相同，至于部分相同以及相同的程度无法判断.

所以，现有方法也可以从以下角度分类：粒度。最小粒度：单词；中等粒度：SHINGLE；最大粒度：整个文档；可见SHINGLE类方法其实是在速度和精确程度上的一种折中方法。可以探讨不同粒度的效果，比如以句子为单位进行编码，以段落为单位编码等不同粒度的编码单位，还可以考虑动态的编码：首先以自然段落编码进行判别，如果发现部分相似，然后针对不同的部分再以细小粒度比如句子甚至单词级别的比较 所谓SUPER SHINGLE就是将粒度放大得到的。粒度越大，好处是计算速度越快（对于MD5整个文档来说，每个文档一个HASH编码，然后排序，将相同的找出，是速度最快的），缺点是会遗漏很多部分相似的文档；粒度越小，好处是招回率比较高，缺点是计算速度减慢。



l   按照去处重复的级别进行分类,去处重复三个级别:

1.   镜像站点:根据站点内相似页面多少进行判断.实现相对简单.

2.   完全相同网页:实现相对简单并且速度比较块,可以根据页面MD5整个文档来说，每个文档一个HASH编码，然后排序，将相同的找出.

3.   部分相同页面:实现相对负责,目前大多工作在这个部分.



评价:

三个级别应该从最高级别到较低级别分别进行,因为有很大比例(22%)的内容是完全相同的,这个部分实现起来相对简单,而且如果这个部分已经识别,那么针对部分相同页面的计算量会大量减少,这样应该可以减少总体的计算时间..



l   按照去重的时机,可以分为以下三类

（1）   抓取页面的时候去重，这样可以减少带宽以及减少存储数量；

（2）   索引之后进行去重；

（3）   用户检索时候进行再次去重；增加准确性，耗费时间；



评价:

可以结合三个时机某个或者所有都结合,对于GOOGLE来说,很可能是结合了2和3两种方法, GOOGLE的很多思路建立在后台计算和实时计算联合，比如相关度计算，后台计算重要性得分，在用户输入查询后得到初始数据集合，然后根据这个数据集合之间文档的关系重新调整顺序；比如去处重复，首先在后台进行重复发现，为了增加精确度，在返回查询结果后，在返回文档集合内，又根据“描述”部分重新计算哪些文档是重复的，这样增加了准确性，估计其它很多相关算法也采取这种联合策略，为了加快速度，实时计算部分可以和CACHE部分结合进行计算。



l   按照不同的特征选择方法,有几种方式:

1.   完全保留特征

2.   特征选择,设置不同的选择策略来保留部分特征,抛弃其它特征

a.   比如对于单词级别的抛弃权重小的单词(I-MATCH)

b.   对于SHINGLE方法,可以保留部分SHINGLE抛弃其它SHINGLE

(1)   一种是保留FINGERPRINT第I个位置为0的SHINGLE,其它抛弃;

(2)   一种是每隔I个SHINGLE进行抽样保留,其它抛弃;这两种得到的文档SHINGLE数目是变长的;

(3)   一种是选择最小的K个SHINGLE,这种得到定长的SHINGLE数目;

(4)   用84个RABIN FINGERPRINT函数对于每个SHINGLE进行计算,保留数值最小的84个FINGERPRINT,这个方法是定长的.



对于SHINGLE类方法来说,还可以区分为:定长的和变长的block切分算法

定长算法：速度快，但是如果内容有稍微变化（比如插入或者删除一个字符或者单词），其影响会比较大。比如Shingle及其改进方法（Super-Shingle），CSC及其改进方法（CSC-SS）。

变长算法：速度相对慢，但是内容变化只是造成局部影响。比如CDC,TTTD等算法。



评价: 为了提高计算速度,一种策略是在特征提取的时候,抛弃部分特征,保留部分特征,通过减少特征数目来加快计算速度.另外一个策略是粒度尽可能加大,比如SUPER-SHINGLE,MEGA-SHINGLE甚至是文档基本;为了提高算法效果,策略是采取变长的内容切割算法比如CSC算法等;这三种策略是方法加快速度和准确性的发展方向.





一些初步的结论:

1.   对于信息检索类型的方法来说,由于其特征选择是基于单词的,所以计算速度是个根本的问题,所以基本上是不实用的;

2.   从利用的信息来看,实用的系统还是应该立足于只是利用文本内容来判别相似性,排除掉利用链接信息等方法;

3.   从算法特征抽取粒度来看,应该立足于SHINLGE类的粒度甚至是文档级别的粒度算法;而SHINGLE类别的算法又应该优先选择抛弃部分特征的算法以及变长的算法;

4.   从去重级别角度考虑,应该将完全相同的文档和部分相同的文档识别分开进行,而且首先进行完全相同文档的识别,这样会有效加快计算速度;

5.   从去重时机考虑,可以考虑结合后台去重以及实时去重,这样增加去重的效果;

6.   从压缩编码方法来看,最有效的方式可能是RABIN FINGERPRINT变体算法;

7.   从聚类方法来看,最有效的方式可能是UNION FIND算法,目前比较快的算法基本上都采用这个方法;

8.   从整体方法选择来看,应该选择改进的SHINLGE方法,在此基础上进行进一步的改进;





三. 方法效率比较

1.   SHINGLING 方法:时间效率O((mn)2) ,其中 m是SHINGLE的大小,n是文档数目.计算时间为:3千万文档,10台机器算一天,或者一台机器算10天;

2.   改进的SHINGLE方法(On the Evolution of Clusters of Near-Duplicate Web Pages.):时间效率接近于线性的O(n),计算时间为:1亿5千万网页计算3个小时;

3.   IMACH方法: 最坏的情况下时间复杂度是(O(d log d))，速度比较快

4.   BLOOM FILTER方法:10k数据花费大约66ms;



从计算效率考虑,速度排序为:

1.   改进的SHINGLE方法;

2.   IMATCH方法;

3.   BLOOM FILTER方法;

4.   SHINGLE方法;





四. 目前代表性解决方法分析

1.   Shingle方法(1997年)

a.   特征抽取

Shingle方法:所谓Shingle类似于自然语言处理中常用的N-GRAM方法,就是将相互连续出现窗口大小为N的单词串作为一个Shingle,两者的不同点在于Shingle是这些串的集合,相同的串会合并为一个,而N-GRAM则由于考虑的是文本线性结构,所以没有相同合并步骤.每个Shingle就是文档的一个特征,一篇文档就是由所有这些Shingle构成的.



b.   压缩编码

40 bit长度 Rabin FingerPrint方法;至于存储方式则类似于传统信息检索领域的倒排文档技术,存储<Shingle,ID>信息以记录某个特征在哪些文档中出现过,然后进一步计算文档的相似性;



c.   文档相似度计算

(1)   相似度:任意两个文档A和B,相似度指的是两者相同的Shingle数目占两者Shingle数目总和的比例;

(2)   包含度:指的是两者相同的Shingle数目占某篇文档Shingle数目的比例;



d.   优化措施:

(1)   分布计算然后合并;

(2)   抛弃超高频出现Shingle,分析发现这些Shingle是无意义的片断;

(3)   完全相同文档保留一份进行聚类;(文档是否完全相同根据压缩编码后数值是否相同判断)

(4)   Super Shingle:关于Shingle的Shingle,从更大结构上计算相似性以节省存储空间;





2.   Google可能采取的方法

a.   特征抽取

类似于Shingle方法,不同点在于:对于每个单词根据HASH函数决定属于哪个LIST,这样每个文档由若干个这样的LIST构成;



b.   压缩编码

FingerPrint方法;对于组成文档的LIST进行FingerPrint方法计算;



c.   文档相似度计算

    编辑距离(Edit Distance):如果两个文档有任何一个FingerPrint相似就判断为内容接近.



d.   聚类方法

首先对<FingerPrint,Doc ID>按照Doc ID进行排序;然后采取Union Find聚类方法,聚类结果就是相似文档集合;



e.   优化措施



3.   HP实验室方法(2005年)

a.   特征抽取

基于内容的Chunk方法:变长而非定长的Chunk算法(TTTD算法);将一篇文档分解为若干个长度不同的Chunk,每个Chunk作为文本的一个特征.与shingle方法相比这种变长Chunk方法能够增加系统招回率;



b.   压缩编码

128bit MD5 HASH方法;每篇文章压缩编码后由若干 <Chunk 长度, 定长HASH编码>二元组构成;



c.   文档相似度计算

(1)   构建所有文档和Chunk构成的二分图;

(2)   找到文档A包含的所有CHUNK,计算这些CHUNK还被哪些其它文档包含;

(3)   计算这些文档和A的相似性;



d.   聚类方法:Union Find 算法

e.   优化措施:Bipartite 划分,本质上是将大规模数据分成小规模数据进行识别然后再合并结果.相当于分布计算;



4．bloom filter(2005年)

(1).特征抽取方法

基于内容的语块（Content-defined chunking CDC）：CDC将文档切分为变长的内容片断，切分边界由rabin fringerprint和预先制定的maker数值匹配来进行判断。

(2)编码（构造 bloom filter集合元素）

对于切分的片断进行编码。bloom filter的编码方式如下：整个文档是由片断构成的，文档由长为m的二值数组表示。在将一个元素（内容片断）进行编码插入集合的时候，利用k个不同的hash函数进行编码，每个hash函数设置m个位置的某个位置为1。这种技术以前主要用来进行判断某个元素是否被集合包含。

（3）相似度计算方法

bloom filter方法：对于两个已经编码的文档（两个长度为m的二值数组），通过bit逻辑运算AND计算，如果两者很多位置都同时为1，那么两个文档被认为是近似的。

（4）优势

1．文档编码形式简洁，便于存储。

2．由于计算相似性是BIT逻辑运算，所以速度快。

3．相对Shingling 方式来说便于判断文档包含关系。（某个文档包含另外一个短小的文档）



5．内容+链接关系（2003年）

1．特征抽取方法

  这个方法在抽取特征的时候同时考虑了文档的内容因素以及链接关系因素。

  内容因素：通过Random Projection技术将文档内容从高维空间映射到低维空间，并且由实数表示，如果两个文档映射后的数字越接近则表明两者内容越相似。

  链接因素：通过考虑类似于PAGERANK的连接关系，将某个网页的内容因素计算获得的分值通过链接传播到其他网页（传播关系见下列公式），多次叠代计算后得到每个页面的链接得分。

       






2．相似度计算方法

  每个文档由二元组<RP,HM>构成，RP代表内容部分的数值，HM代表链接关系代表的数值。如果两个文档每个项之间的差值都小于指定值，则判断两个文档是相似的。

3．效果

只采取内容精度达到90%，两者结合精度达到93%。从中看出，链接的作用并不明显。这可能跟这个方法的链接使用方法有关，因为通过链接计算的还是内容的情况。



6．I-Match方法（2002年）

（1）I-Match不依赖于完全的信息分析，而是使用数据集合的统计特征来抽取文档的主要特征，将非主要特征抛弃。输入一篇文档，根据词汇的IDF值过滤出一些关键特征，并且计算出这篇文档的唯一的Hash值，那些Hash值相同的文档就是重复的。

（2）使用SHA1作为Hash函数，因为它的速度很快而且适用于任何长度。SHA-1生成一个20-byte 或者160-bit 的hash值并且使用一个安全的冲突消解算法，使得不同的标志串(token streams)生成相同的hash值的概率非常低。.把<docid, hashvalue>元组插入树结构的时间复杂度是(O(d log d))，其他的如检索数据结构（hash表）需要(O(d))。对重复(duplicate)的识别是在将数据插入hash数组或是树结构中进行的，任何的hash值的冲突就表示检测到一个重复内容。

（3）最坏的情况下时间复杂度是(O(d log d))，速度比较快。
]]> http://www.xd-tech.com.cn/blog/default.asp?id=56 <![CDATA[如何才能做好一个垂直搜索引擎 ]]> jaddy0302@126.com(admin) Wed,20 Jun 2007 17:40:14 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=56
“确解用户之意，切返用户之需。”

“门户网站都想着是怎样省钱，而不是怎样花钱来买技术。”

“搜索引擎不是人人都能做的领域，进入的门槛比较高。”

“只是优秀还不够，最好的方式是将一件事情做到极致。”(google十大真理)

“做搜索引擎需要专注” “对于一项排到第四的业务，门户很难做到专注。”

“用户无法描述道他要找什么，除非让他看到想找的东西。”

“所谓楔形，其实就是个倒三角，倒三角的尖端部分代表搜索技术，中部是基于技术的产品应用平台，最上端是对整个搜索引擎用户人群文化的认识和理解，以及现代公司竞争最关键也最捉摸不定的所谓品牌。”

“楔形”蕴涵的另一个意义是:楔子要打到墙里，尖端是否锐利很重要，但楔子的破坏性有多强，究竟能在墙面挤压出多大的空间，其中端、后端的沉稳与厚重才是关键。

搜索引擎的技术和理念都是需要时间和经验的积累的，更是需要长期不断的完善进步的，绝对不要认为可以一蹴而就，要达到一个相对成熟领先的搜索引擎从开始到领先的周期一般需要是四年。着急不得。原因是因为搜索引擎太复杂，而且“用户无法描述他要找什么，除非让他看到想找的东西。” 一切都需要摸索，尝试，问题需要一个一个解决，用户的需要得一点点的挖掘。

搜索引擎是一个产品，给用户提供服务的产品，需要长期的不断的改进升级调整才能持续不断的提用户体验，需要满足用户不断增长并且变化的需求、需要不断适应网络的变化。这是因为网络环境是不断变化的、网民的需求也是不断变化的。千万不要把搜索当成项目来做，做完了撂那让用户去用那你肯定没戏。在搜索引擎领域是讲体验的、新的引擎如果用户体验一旦整体上有领先一年以上的差距并且持续2年，那前期的领先者的优势就荡然无存，因为搜索引擎的用户转移成本相对而言是比较低的而且口碑是最佳的传播方式。如果一个搜索引擎不能持续不断的技术创新理念创新，那对于这个搜索引擎来说就等于死亡。我们一般形容搜索引擎的领先是以时间计算的。比如:中搜离百度整体差距×年，百度离google的整体差距×年，……只要你能在用户体验上保持一年的领先优势持续2年，不需要炒作，一切纷至沓来。在用户体验面前，任何的炒作都显得很渺小。

作垂直搜索引擎，麻雀虽小，但是五脏俱全。无论理念文化、产品管理、应用、技术都和搜索引擎的楔形理论没有什么区别。所以要做好一垂直搜索必须解决这几个方面。

楔形的尖:垂直搜索技术。 


垂直搜索技术主要分为两个层次:模板级和网页库级。模板级是针对网页进行模板设定或者自动生成模板的方式抽取数据，对网页的采集也是针对性的采集，适合规模比较小、信息源少且稳定的需求，优点是快速实施、成本低、灵活性强，缺点是后期维护成本高，信息源和信息量小。网页库级就是在信息源数量上、数据容量上检索容量上、稳定性可*性上都是网页库搜索引擎级别的要求，和模板方式最大的区别是对具体网页不依赖，可针对任意正常的网页进信息采集信息抽取……。这就导致这种方式数据容量上和模板方式有质的区别，但是其灵活性差、成本高。当然模板方式和网页库级的方式不是对立的，这两者对于垂直搜索引擎来说是相互补充的，因为技术只是手段，目的是切反用户之需。本文谈及的技术主要是指网页库级别垂直搜索引擎技术。

搜索引擎的确是一项对技术要求比较高的应用，几年前相关的人才也比较少。现在搜索技术人才多了，相关的技术和技术的应用得相对以前而言更加成熟，但是竞争也更加激烈了。垂直搜索大致需要以下技术:

1. 信息采集技术

2. 网页信息抽取技术

3. 信息的处理技术，包括:重复识别、重复识别、聚类、比较、分析、语料分析等

4. 语意相关性分析

5. 分词

6. 索引

信息采集技术，垂直搜索引擎spider和网页库的spider相比应该是更加专业，可定制化。可定向性的采集和垂直搜索范围相关的网页忽略不相关的网页和不必要的网页，选择内容相关的以及适合做进一步处理的网页深度优先采集、对页面有选择的调整更新频率……，采集可通过人工设定网址和网页分析url方式共同进行。垂直搜索对信息的更新有着特别的要求，根据这些特点可以从以下几点考虑1.信息源的稳定性(不能让信息源网站感觉到spider的压力)2.抓取的成本问题3.对用户体验改善程度。根据以上几点制定一种比较好的策略，要做到恰到好处。策略上可以评估网站/网页更新的系数、网站/网页的重要系数、用户点击系数(或曝光系数)、网站稳定系数……，根据这些系数来确定对这些网站/网页更新的频率。再由于新信息和更新了的信息list页面前面或者首页，所以对网页进行很好的分级可以以低成本很好的解决更新问题，系数比较低的网页一月update一次，稍微高点的一周update一次、中等的几天到一天一次、高的几小时到几分钟一次。类似搜索引擎的大库、周库、日库，小时库……

基于视觉网页块分析技术，模拟IE浏览器的显示方式，对网页进行解析。根据人类视觉原理，把网页解析处理的结果，进行分块，再根据需要，对这些块进行处理，如:采集定向、介绍抽取和一些必要的内容的抽取正文抽取……

结构化信息抽取技术，将网页中的非结构化数据按照一定的需求抽取成结构化数据。有两种方式，简单的就是模板方式，另外就是对网页不依赖web结构化信息抽取方式，这两种方式可以互取长处，以最简单最有效的办法满足需求。垂直搜索引擎和通用搜索引擎最大的区别就是对网页信息结构化抽取后再结构化数据进行深度的处理，提供专业的搜索服务。所以web结构化信息抽取的技术水平是决定垂直搜索引擎质量的重要技术指标。其实web结构化信息抽取在百度、google早已经广泛应用了，如:MP3、图片搜索、google的本地搜索就是从网页库抽取出企业信息，添加到其地图搜索中的，google通过这种技术正在颠覆做内容的方式。同样的技术应用还在qihoo、sogou购物、shopping等各种应用中体现。

简单的语法分析，简单的语法分析在搜索引擎中非常重要，可以通过简单的语法分析来改善数据的质量，低成本的获得某类信息，改善排序，寻找需要的内容……

信息处理技术，信息处理包括的范围比较广，主要包括去重、聚类、分析……，这根据需要相关的技术就非常多。

数据挖掘，找出您的信息的关联性对于垂直搜索来说非常重要，有效，可以在这些相关性上为用户提供更细致的服务。

分词技术，面向搜索的分词技术，建立和您的行业相关的词库。注意这是面向搜索的分词，不是面向识别和准确的分词。就这个工作安排十几个人不停的维护也不会嫌多。

索引技术，索引技术对于垂直搜索非常关键，一个网页库级的搜索引擎必须要支持分布索引、分层建库、分布检索、灵活的更新、灵活的权值调整、灵活的索引和灵活的升级扩展、高可*性稳定性冗余性。还需要支持各种技术的扩展，如偏移量计算等。

其它技术，略。

垂直搜索引擎的技术评估应从以下几点来判断

1. 全面性

2. 更新性

3. 准确性

4. 功能性
]]> http://www.xd-tech.com.cn/blog/default.asp?id=55 <![CDATA[搜索技术已经发生了改变，您是否跟上了它的发展呢？]]> jaddy0302@126.com(admin) Wed,20 Jun 2007 16:21:54 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=55 寻找并有所发现

您输入一个关键字列表，点击 Search 按钮，马上将得到相关文档的列表。这非常容易，不是吗？是的，的确很容易。这是什么魔法吗？其实并不是。

信息检索或简称为“搜索”，目前是计算机科学中的一个非常重要的领域。从技术的角度来看，倒排索引用于存储文档中出现的关键字，并且支持搜索，它是一种广为熟悉并且精确描述的数据结构。

公正地说，查找包含关键字的文档列表是件很容易的事情，但是，排序技术却涉及到很多未知的技术和深奥的计算公式。事实上，对数以千计的、包含请求搜索的关键字的文档进行排序，以便将与用户最相关的文档列在最上方，这并不是一件容易的任务。尽管如此，用于排序结果的数学模型通常是常用的词频/倒排文档频率模型的变体，而对于这种模型，已有很好的研究基础。

每年，美国国家标准局都组织关于搜索引擎的“奥运比赛”：称为 TREC 挑战赛，这一赛事提供给参赛者海量的文档，而他们必须在这些文档中查找出满足要求的少部分内容。不幸的是，大多数商业搜索引擎都拒绝使用这类科学的方法进行评估。

除了使用关键字进行搜索之外，您还可以使用浏览的方法进行搜索，这种方法使用分层结构的、类似于目录的结构来定位文档。有些时候将这些分层结构称为分类，通常由专家来构建这些分类。例如曾经很受欢迎的 Open Directory 项目，这是一种用于 Web 站点的常规分类。

这个基本搜索方法的一种变体是高级搜索，其中使用预先选定的一组特定字段的值来执行搜索，如标题、作者，等等。通常认为这是“超级用户”的特性，超级用户希望查找特定的来源，而不是有关特定主题的任何来源。例如，如果您知道准确的标题、作者名、出版时间、或者关于您正在查找的文档的一些其他精确信息，那么您就可以使用高级搜索。

尽管这不是“高级”用户专用的，但是高级搜索也并非适用于所有的用户。如果您了解关于您正在搜索的对象的细节信息，那么什么因素可能阻止您使用高级搜索，并成为所谓的超级用户呢？高级搜索可能很麻烦。我的看法是，用于定义这些高级条件的用户接口和计算机语言通常令人费解或非常复杂，以至于普通人难以使用。

但是事情正在发生变化，并且现在有更多的方法用于获得相关的内容。要了解搜索技术所经历的发展趋势，并且要了解如何获得所需的搜索结果，很重要的一点是，必须弄清楚下面两种使用搜索引擎的方法之间的区别：发现和获得。

通常在需要发现 网络上可用的资源时，您需要搜索 Web；在您开始进行搜索之前，您并不清楚可能存在什么样的资源。另一方面，当您在搜索自己的硬盘时，通常试图获得 某项已经存在的信息，而您只是不知道该信息的具体位置而已。以下是两个基本的场景：发现与获得之间的比较。换句话说，寻找关于某个特定主题所存在的内容与寻找某项已经知道的特定信息，这两种搜索是不相同的。


回页首


后过滤（Post-filtering）和方面（facet）：这是高级搜索的终结吗？

很明显，高级搜索主要用于获得场景，而这些场景很少出现在搜索 Web 的情况下。这正是为什么大多数最新的 Web 搜索引擎放弃了所谓的高级搜索特性的原因。另一方面，当您在搜索个人数据（或者甚至公司内部网）时，您通常知道关于正在查找的信息的一些细节信息。

这就产生了称为面向方面的搜索的新的搜索范例。面向方面的搜索的价值是，它使用户能够研究结果并且更精确地细化他们的搜索，而无需使用复杂的高级搜索语法所提供的布尔条件。当您使用支持面向方面的搜索特性的搜索引擎时，除了您的搜索结果之外，您还将得到一组方面，每个方面都描述了某种属性，如作者、出版日期，等等。对于其中的每个方面，您可以看见与搜索相关的各种可能的值所组成的列表，并且还提供了一个数字，用于表现包含对应值的结果的数量。

例如，假设您正使用词汇“marketing chicken”对您的计算机进行搜索。搜索引擎可能为这些词汇返回一个结果列表，同时包括下面的这些方面：

Source:Lotus Notes (34), Disk (26)
Author:John H. (12), David K (23), Others (25)
Updated:Last Week (15), Last Month (45)

这意味着在搜索结果的范围中，其中 34 项存储于您的 Lotus® Notes 电子邮件中，而有 26 项存储在您的硬盘上。如果不考虑存储位置，那么 John H. 是其中 12 项结果的作者，David K. 是其中 23 项结果的作者，而由其他人所撰写的内容共计 25 项。另外，如果不考虑存储位置和作者，那么在上周进行更新的有 15 项，而在上个月进行更新的有 45 项。

如何使用这些方面呢？很容易。这些方面都是链接，所以当您认为某个方面对您是最重要的，只需单击它即可，这将显示来自对应来源的筛选结果，而且所显示的结果将使用剩下的方面进行组织。例如，单击 Lotus Notes 链接，可能出现下列的方面：

Author:John H. (3), David K (11), Others (20)
Updated:Last Week (11), Last Month (23)

当只考虑那些来自 Lotus Notes 的结果时，您可以通过深入研究最重要的方面并且更精确地定制搜索，直到找到所需的信息。您可以在任何时候撤消所做的选择，从而研究其他的路径。

这种方法的优点可能非常明显。当搜索结果中包含很多属性时，您可以采用简单而直观的方式对其进行研究，而无需求助于布尔逻辑。此外，因为通过数值表示了每个方面可用内容的潜在范围，所以您可以确保不会深入研究任何“空”的路径。

在 Internet 上的电子商务站点（如消费电子产品站点）中，当前最流行的是面向方面的搜索，这类产品信息有足够的特性和部分，以使得这种导航操作非常有意义。尽管对于标准的 Web 页面，面向方面的搜索目前看起来并不是很合适，但有足够的特性以使得面向方面的搜索适用于个人和内部网搜索引擎的环境，所以我相信在今后的几年中，随着我们越来越多地对电子邮件、个人文件和内部网信息进行搜索，我们将会更多地看到这种特性。


回页首


标记和社会化搜索：这是分类法的终结吗？

如前所述，您可以使用分类法对感兴趣的主题和相应的文档进行定位。尽管对于这些分类，很难进行维护。在创建一个新的文档时，必须将其与这种复杂数据结构中合适的类别关联。这引出了一种新的趋势，称为 大众分类法 ：您可以对您撰写的或者访问的文档进行分类，而无需依赖分类专家或者其他人根据实际情况对信息加以分类。通过将文档关联于单个单词或者标记，就可以完成这项操作。然后，任何用户都可以搜索并利用这个标记空间，查看其中最频繁使用的标记，查看使用这个单词标记了哪些文档，等等。从理论上讲，标记将帮助更多的人找到更多的文档。例如，可以使用“微电子学”这个单词来标记一篇关于微电子学的文章，即使“微电子学”这个术语根本没有出现在文档本身的内容中。因此，如果使用这个词作为标记搜索微电子学相关的内容，那么将在搜索结果中找到该文档，这正是由于那位有远见或判断力的人创建了这个标记，并且标记本身具有动态实用性。而使用关键字进行搜索，则不会出现这种情况。

当然，在实践中，标记的使用可能会使得一些事情变得复杂。因为任何人都可以随意地建立标记，所以经过一段时间后，在搜索集合中无法防止无关标记或错误标记的出现。在企业环境中，安全性也是一个问题。如果不允许某些用户访问某个文档，那么当他们使用标记空间时，是否应该允许他们看到与这个文档相关联的标记呢？这种方法可以简化和改进在个人控制的信息集合（您的团队文件、您的照片）中的搜索，但是，同时会使得对大型企业范围内的信息集合的搜索变得更加复杂。


回页首


来自多个来源的结果

当您进行搜索时，可能希望通过多个来源进行搜索。例如，在 Web 上，通常会限制您只能使用一个搜索引擎，这是因为，使用多个搜索引擎并对其进行比较是非常麻烦的。当搜索您的个人文件或者企业内部网时，这个问题甚至变得更加复杂。有一些搜索引擎，可以使用不同的用户接口进行访问，可以访问不同的数据集，并产生不同的结果集。在这种情况下，联合和聚合这两种方式可以提供帮助。

联合 意味着使用某种工具注册所有可用的搜索引擎，将您所进行的搜索转发给所有这些搜索引擎，然后检索结果，并在单个列表中显示经过组合的结果。在大多数情况下，很难以统一的方式对结果进行排序。（在某些搜索引擎中，在对结果的相关性评分中，85% 是一个“好”的评分，而在其他的引擎中，好的评分是 95%。）因此，在使用联合的时候，很有可能会将来自每个来源的结果分离开来。（在这种情况下，面向方面的搜索可能是很有帮助的。）

在使用聚合 的时候，中央搜索引擎将汇总所有的搜索内容。对某个位置进行搜索，并从所有的来源返回统一的结果。因此，聚合的方式非常方便，但是却难以实现，因为它需要通过爬网的方式处理所有可用的数据来源，并且扩展搜索引擎。多数情况下，您将不得不接受几个不同层次的联合和聚合（对于目前而言）。


回页首


门户搜索工具箱

随着需要搜索的信息越来越多，我们可以使用的搜索方式也越来越多。WebSphere Portal Search Development 团队希望帮助您使用不同的搜索方式，而有了这些方式，可以让最终用户在企业中查找信息的任务变得更加容易。这正是我们发布公共 API 以及免费提供搜索工具的原因。这些工具的目标是帮助您进行试验，以便开发出更有效的搜索应用程序，并对我们周围日益增长的信息空间，找到合适的搜索方式。

]]> http://www.xd-tech.com.cn/blog/default.asp?id=54 <![CDATA[搜 索 引 擎 分 类]]> jaddy0302@126.com(christian) Tue,15 May 2007 17:23:10 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=54 　　全文搜索引擎是名副其实的搜索引擎，国外具代表性的有Google、Fast/AllTheWeb、AltaVista、Inktomi、Teoma、WiseNut等，国内著名的有百度（Baidu）。它们都是通过从互联网上提取的各个网站的信息（以网页文字为主）而建立的数据库中，检索与用户查询条件匹配的相关记录，然后按一定的排列顺序将结果返回给用户，因此他们是真正的搜索引擎。

　　从搜索结果来源的角度，全文搜索引擎又可细分为两种，一种是拥有自己的检索程序（Indexer），俗称“蜘蛛”（Spider）程序或“机器人”（Robot）程序，并自建网页数据库，搜索结果直接从自身的数据库中调用，如上面提到的7家引擎；另一种则是租用其他引擎的数据库，并按自定的格式排列搜索结果，如Lycos引擎。

　　　　　 

 

　■ 目录索引 
　　目录索引虽然有搜索功能，但在严格意义上算不上是真正的搜索引擎，仅仅是按目录分类的网站链接列表而已。用户完全可以不用进行关键词（Keywords）查询，仅靠分类目录也可找到需要的信息。目录索引中最具代表性的莫过于大名鼎鼎的Yahoo雅虎。其他著名的还有Open Directory Project（DMOZ）、LookSmart、About等。国内的搜狐、新浪、网易搜索也都属于这一类。

　　　　　　 

 
　■ 元搜索引擎 (META Search Engine)
　　元搜索引擎在接受用户查询请求时，同时在其他多个引擎上进行搜索，并将结果返回给用户。著名的元搜索引擎有InfoSpace、Dogpile、Vivisimo等（元搜索引擎列表），中文元搜索引擎中具代表性的有搜星搜索引擎。在搜索结果排列方面，有的直接按来源引擎排列搜索结果，如Dogpile，有的则按自定的规则将结果重新排列组合，如Vivisimo。

　　除上述三大类引擎外，还有以下几种非主流形式：

　　1、集合式搜索引擎：如HotBot在2002年底推出的引擎。该引擎类似META搜索引擎，但区别在于不是同时调用多个引擎进行搜索，而是由用户从提供的4个引擎当中选择，因此叫它“集合式”搜索引擎更确切些。
　　2、门户搜索引擎：如AOL Search、MSN Search等虽然提供搜索服务，但自身即没有分类目录也没有网页数据库，其搜索结果完全来自其他引擎。
　　3、免费链接列表（Free For All Links，简称FFA）：这类网站一般只简单地滚动排列链接条目，少部分有简单的分类目录，不过规模比起Yahoo等目录索引来要小得多。　　

　　由于上述网站都为用户提供搜索查询服务，为方便起见，我们通常将其统称为搜索引擎。

]]> http://www.xd-tech.com.cn/blog/default.asp?id=53 <![CDATA[集成搜索引擎与元搜索引擎]]> jaddy0302@126.com(christian) Tue,15 May 2007 17:19:58 +0800 http://www.xd-tech.com.cn/blog/default.asp?id=53
集成搜索引擎和元搜索引擎尽可能地减少和优化了检索操作，实现了“一次检索输入，多引擎同时搜索”。

目前国内对集成搜索引擎和元搜索引擎的概念界定尚不清晰，二者多互称、通用。事实上，集成搜索引擎和元搜索引擎是两种不同类型的搜索工具，既有共同特点，又有明显差异。

一、集成搜索引擎
集成搜索引擎（ All－in－One Search Page），亦称为“多引擎同步检索系统 ”（如http://www.bioon.com/multisearch.htm）是在一个WWW页面上链接若干种独立的搜索引擎，检索时需点选或指定搜索引擎，一次检索输入，多引擎同时搜索，搜索结果由各搜索引擎分别以不同页面提交，其实质是利用网站链接技术形成的搜索引擎集合，而并非真正意义上的搜索引擎。

集成搜索引擎无自建数据库，不需研发支持技术，当然也不能控制和优化检索结果。但集成搜索引擎制作与维护技术简单，可随时对所链接的搜索引擎进行增删调整和及时更新，尤其大规模专业（如FLASH、MP3等）搜索引擎集成链接，深受特定用户群欢迎。在搜索引擎发展进程中，集成搜索引擎只是元搜索引擎的初级形态，以其方便、实用在网络搜索工具家族中占据一席之地。典型的集成搜索引擎有“搜索之家”（http://so.web165.com/）、“网际瑞士军刀”（http://free.okey.net/~free/search1.htm）等。

二、元搜索引擎
元搜索引擎（Metasearch Engine），是一种调用其它独立搜索引擎的引擎,亦称“搜索引擎之母（The mother of searce engines)”。在这里，“元”（Meta）为“总的”、“超越”之意，元搜索引擎就是对多个独立搜索引擎的整合、调用、控制和优化利用。相对元搜索引擎，可被利用的独立搜索引擎称为“源搜索引擎”（source Engine），或“搜索资源”（searcing resources），整合、调用、控制和优化利用源搜索引擎的技术，称为“元搜索技术”（Meta-searching technique），元搜索技术是元搜索引擎的核心。

元搜索引擎分为并行处理式和串行处理式两大类。并行处理式元搜索引擎将用户的查询请求同时转送给它调用链接的多个独立型搜索引擎进行查询处理，串行处理式元搜索引擎将用户的查询请求依次转送给它调用链接的每一个独立型搜索引擎进行查询处理。 

元搜索引擎是用户同时利用多引擎进行网络搜索的中介。检索时，元搜索引擎根据用户提交的检索请求，调用源搜索引擎进行搜索，对搜索结果进行汇集、筛选、删并等优化处理后，以统一的格式在同一界面集中显示。元搜索引擎虽没有网页搜寻机制，亦无独立的索引数据库，但在检索请求提交、检索接口代理和检索结果显示等方面，均有自己研发的特色元搜索技术支持。如提交检索请求时，根据源搜索引擎的特点和技术参数，指定优先顺序，并对检索时间、检索结果数量进行控制；作为若干源搜索引擎的检索接口代理，元搜索引擎必须具有较强的字符和语法转换功能，使用户的检索请求为各具语法特点的不同的源搜索引擎所人知和接受； 而对检索结果的显示，不同的元搜索引擎有不同的处理技术，由于元搜索引擎设定的检索结果排序依据、最大返回结果数量、相关度参数及优化机制等不同，调用相同的源搜索引擎的不同元搜索引擎显示检索结果的数量多少、排序先后、结果信息描述选择亦有较大差异。

一款理想的元搜索引擎应该具备以下特点和功能：第一，含盖较多的搜索资源，可随意选择和调用源搜索引擎；其次，具备尽可能多的可选择功能，如资源类型（网站、网页、新闻、软件、FTP、MP3、图像等）选择、返回结果数量控制、结果时段选择、过滤功能选择等；第三，强大的检索请求处理功能（如支持逻辑匹配检索、短语检索、自然语言检索等）和不同搜索引擎间检索语法规则、字符的转换功能（如对不支持“NEAR”算符的搜索引擎，可自动实现由“NEAR”向“AND”算符的转换等）；第四，详尽全面的检索结果信息描述（如网页名称、URL、文摘、源搜索引擎、结果与用户检索需求的相关度等）；第五，支持多种语言检索。

目前运营的元搜索引擎各具特色，功能各有侧重，完全“理想”的尚不多见。一些元搜索引擎在某些方面较为优秀，而其它功能则欠缺或需改进：如大多元搜索引擎不支持多语种，尤其是汉语检索；一些元搜索引擎实现检索语法转换的能力有限，不支持指定字段检索，不能充分发挥各个独立搜索引擎的高级检索功能；部分元搜索引擎无源搜索引擎列表，用户不能自主选择和调用源搜索引擎；大部分元搜索引擎仅支持调用AltaVista、Excite、GoTo．com、Yahoo！、Infoseek、Lycos等常用的搜索引擎，一些大型搜索引擎如NorthernLight、HotBot等被排除在外，人为地限制了搜索资源的利用；在检索结果上，元搜索引擎只能返回十几、数十条“相关度”较高的结果，大量可能有价值的源搜索引擎的检索结果被忽视，影响检索结果的全面性。元搜索引擎的功能受着源搜索引擎和元搜索技术的双重制约：一方面，源搜索引擎的各具特色的强大功能在元搜索引擎中受到限制而不能充分体现，而另一方面，任何一种元搜索技术都不能发掘和利用源搜索引擎的全部功能。

1995年华盛顿大学硕士生 Eric Selberg 和 oren Etzioni 推出第一个元搜索引擎---Metacrawler以来，这一新型的网络检索工具异军突起，发展迅速，目前可用的元搜索引擎已近百种。尽管元搜索引擎存在着这样那样的功能局限，但其以含盖较多的搜索资源，能够在尽可能短的时间内提供相对全面、准确的检索结果等诸多优异功能受到用户的青睐，已渐成为一种不可或缺的极具潜力的网络检索工具。 

元搜索引擎一览：

《搜索引擎观察》2002年最佳元搜索引擎

1、Vivisimo （ http://vivisimo.com/）
调用多种搜索引擎，并对返回的结果自动分类,界面友好，简单易用。

2、EZ2WWW （ http://www.ez2www.com/）
调用AllTheWeb, AltaVista, Google, Open Directory, Teoma, Wisenut and Yahoo等搜索引擎，高级搜索功能提供1000多种专项资源检索，可进行目录检索。

3、Kartoo （ http://www.kartoo.com/）
在搜索结果中显示链接各相关页面的关键词。

4、SurfWax （ http://www.surfwax.com/）
有一个其它元搜索引擎没有的独特功能，即点击每条结果左边的“网址揿钮”图标，可浏览该结果包括的任何页面，并显示搜索语句在文件中的位置。可以把搜索结果和文件存储起来以备后用。

5、Fazzle （ http://www.fazzle.com/）
即可进行一般的网址搜索，又有一个主题目录提供专题资源搜索。其前身为SearchOnline

著名元搜索引擎

1、InfoGrid （ http://www.infogrid.com/）
提供与主要搜索网站的直接连结和目录检索，具有强大的元搜索和新闻搜索功能。

2、Infonetware Realterm Search （ http://www.infonetware.com/）
原为检验网络分类技术而设计。它以元搜索引擎知名，但具有强大的对搜索结果进行主题分类的功能。与众不同的是，用户可选择不同的主题，并得到来自所有主题搜索结果，而不是仅仅把搜索结果限制在一个主题范围之内。

3、Ithaki （ http://www.ithaki.net/dir.html）
支持包括中文在内的14种语言检索。

4、Ixquick （ http://www.ixquick.com/）
可搜索网站、MP3、新闻、图象等多种网络资源。

5、ProFusion ( http://www.profusion.com)
拥有智能化的搜索方案，提供诸如搜索引擎选择、检索类型、结果显示、摘要选项、链接检查等较多的检索选项，支持个性化设置，可以选择三个最好的搜索引擎、或三个最快的搜索引擎、或全部搜索引擎、或手工选择任意几个搜索引擎来进行搜索。自动实现符合特殊检索语法要求的转换，如在调用Excite、InfoSeek、WebCrawler时将“NEAR”转换成“AND”，在调用GoTo、Yahoo时将“NOT”删除等。原为堪萨斯州大学所有，2000年四月被Intelliseek 搜索公司购买。

6、Mamma （ http://www.mamma.com）
1996年面世，自称为“搜索引擎之母”的并行元搜索引擎，可同时调用7个最常用的独立搜索引擎，并且可查询网上商店、新闻、股票指数、图像和声音文件等资源。其特点是检索界面友好，检索选项丰富，主要包括：可控制调用的独立搜索引擎、选择使用短语检索功能、设定检索时间、设定每页可显示记录数等。另外，Mamma支持常用检索语法在不同搜索引擎中的转换，还提供了专门检索页面文件标题的特殊检索服务，以及通过E－mail传输检索结果的特色功能。检索结果以相关性排序，内容包括网页名称、URL、文摘、源搜索引擎。　　

7、MetaCrawler （ http://www.metacrawler.com）
1995年由华盛顿大学推出，1997年被InfoSpace购买。支持调用12个独立搜索引擎，提供涵盖近20个主题的目录检索服务。其检索特性非常丰富，包括常规检索、高级检索、定制检索、国家或地区的资源检索等检索服务模式。其中，高级检索模式可实现：搜索引擎的选择调用，基于域名、地区或国家的检索结果过滤，最长检索时间设置，每页可显示的和允许每个搜索引擎返回的检索结果数量的设定，设定检索结果排序依据（包括相关度、域名、源搜索引擎）等。以上内容均可作为定制检索的个性化选项并予以保存。另外，检索结果中包括一个以1000为最大值的相关度指标。

8、ByteSearch （ http://www.bytesearch.com）
搜索速度快，可检索资源丰富，搜索范围包括Web、城市信息、公司名录、域名、FTP网站、多媒体、新闻组、包裹跟踪等，并提供新闻浏览、URL提交、最新的20个检索浏览、联机商店等内容方面的服务。支持完全匹配（All）、部分匹配（Any）、短语检索（Phrase）等特性检索功能，没有搜索引擎列表，不能控制源搜索引擎的选择。

9、SavvySearch ( http://savvy.cs.colostate.edu:2000/) 
支持二十种语言(不包括中文)，可调用全部或任意几个搜索引擎，可选择每个搜索引擎返回结果的数目，可进行目录检索。　　

常用元搜索引擎

1、qbSearch http://www.qbsearch.com/）
2、Query Server http://www.queryserver.com）
3、Turbo10 http://turbo10.com/）
4、Dogpile http://www.dogpile.com/）
5、Webcrawler http://www.webcrawler.com/）
6、Search.com http://www.search.com/）

其它元搜索引擎
1、1Blink http://www.1blink.com/）
2、Gimenei http://gimenei.com/）
3、IcySpicy http://www.icyspicy.com/）
4、MetaEureka http://www.metaeureka.com/）
5、Moonmist http://www.moonmist.info/）
6、Widow Meta Search http://www.widow.com/）
7、Family Friendly Search 
http://www.familFamily Friendly Searchyfriendlysearch.com/）
8、Searchy.co.uk http://www.searchy.co.uk/）
9、TeRespondo http://sl.terespondo.com/home/）
10、Watson for the Macintosh
http://www.apple.com/downloads/macosx/internet_utilities/watson.html）
11、Chubbahttp://chubba.whatuseek.com/） 
12、Debriefinghttp://debriefing.ixquick.com/） 
13、C4 http://www.c4.com/ ） 
14、Infindhttp://www.infind.com/） 
15、Infozoidhttp://www.infozoid.com/） 
16、Ixquickhttp://www.ixquick.com）
17、OneSeekhttp://www.oneseek.com/） 
18、One2Seekhttp://one2seek.com/） 
19、Query Serverhttp://www.queryserver.com/general.htm） 
20、Proteushttp://www.thrall.org/proteus.html） 
21、Searcheshttp://www.searches.com） 
22、Searchbug http://www.searchbug.com/） 
23、Skwormhttp://www.skworm.com/） 
24、Skwormhttp://www.skworm.com/） 
25、Sleuthhttp://www.isleuth.com） 
26、SurfWaxhttp://www.surfwax.com/） 
27、Supercrawler