整理的有关Lucene的资料(一)

来源: http://blog.csdn.net/gooogledev/archive/2007/04/06/1554285.aspx

开放源代码的全文检索引擎Lucene――介绍、系统结构与源码实现分析  

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
开放源代码的全文检索引擎 Lucene
――介绍、系统结构与源码实现分析
 
 

 第一节全文检索系统与Lucene简介

 
 
 
 
 
 
 
 
 
 
 
 
 
 
全文检索是指计算机索引程序通过扫描文章中的每一个词,对每一个词建立一个索引,指明该词在文章中出现的次数和位置,当用户查询时,检索程序就根据事先建立的索引进行查找,并将查找的结果反馈给用户的检索方式。这个过程类似于通过字典中的检索字表查字的过程。
 
全文检索的方法主要分为按字检索和按词检索两种。按字检索是指对于文章中的每一个字都建立索引,检索时将词分解为字的组合。对于各种不同的语言而言,字有不同的含义,比如英文中字与词实际上是合一的,而中文中字与词有很大分别。按词检索指对文章中的词,即语义单位建立索引,检索时按词检索,并且可以处理同义项等。英文等西方文字由于按照空白切分词,因此实现上与按字处理类似,添加同义处理也很容易。中文等东方文字则需要切分字词,以达到按词索引的目的,关于这方面的问题,是当前全文检索技术尤其是中文全文检索技术中的难点,在此不做详述。
 
全文检索系统是按照全文检索理论建立起来的用于提供全文检索服务的软件系统。一般来说,全文检索需要具备建立索引和提供查询的基本功能,此外现代的全文检索系统还需要具有方便的用户接口、面向WWW [1]的开发接口、二次应用开发接口等等。功能上,全文检索系统核心具有建立索引、处理查询返回结果集、增加索引、优化索引结构等等功能,外围则由各种不同应用具有的功能组成。结构上,全文检索系统核心具有索引引擎、查询引擎、文本分析引擎、对外接口等等,加上各种外围应用系统等等共同构成了全文检索系统。图1.1展示了上述全文检索系统的结构与功能。
 
在上图中,我们看到:全文检索系统中最为关键的部分是全文检索引擎,各种应用程序都需要建立在这个引擎之上。一个全文检索应用的优异程度,根本上由全文检索引擎来决定。因此提升全文检索引擎的效率即是我们提升全文检索应用的根本。另一个方面,一个优异的全文检索引擎,在做到效率优化的同时,还需要具有开放的体系结构,以方便程序员对整个系统进行优化改造,或者是添加原有系统没有的功能。比如在当今多语言处理的环境下,有时需要给全文检索系统添加处理某种语言或者文本格式的功能,比如在英文系统中添加中文处理功能,在纯文本系统中添加XML [2]或者HTML [3]格式的文本处理功能,系统的开放性和扩充性就十分的重要。
 
 
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 Software License [12]),在此基础上程序员不仅仅可以充分的利用Lucene所提供的强大功能,而且可以深入细致的学习到全文检索引擎制作技术和面相对象编程的实践,进而在此基础上根据应用的实际情况编写出更好的更适合当前应用的全文检索引擎。在这一点上,商业软件的灵活性远远不及Lucene。其次,Lucene秉承了开放源代码一贯的架构优良的优势,设计了一个合理而极具扩充能力的面向对象架构,程序员可以在Lucene的基础上扩充各种功能,比如扩充中文处理能力,从文本扩充到HTML、PDF [13]等等文本格式的处理,编写这些扩展的功能不仅仅不复杂,而且由于Lucene恰当合理的对系统设备做了程序上的抽象,扩展的功能也能轻易的达到跨平台的能力。最后,转移到apache软件基金会后,借助于apache软件基金会的网络平台,程序员可以方便的和开发者、其它程序员交流,促成资源的共享,甚至直接获得已经编写完备的扩充功能。最后,虽然Lucene使用Java语言写成,但是开放源代码社区的程序员正在不懈的将之使用各种传统语言实现(例如.net framework [14]),在遵守Lucene索引文件格式的基础上,使得Lucene能够运行在各种各样的平台上,系统管理员可以根据当前的平台适合的语言来合理的选择。
 
 
作为中国人民大学信息学院99级本科生的一个毕业设计项目,我们对Lucene进行了深入的研究,包括系统的结构,索引文件结构,各个部分的实现等等。并且我们启动了cLucene项目,做为一个Lucene的C++语言的重新实现,以期望带来更快的速度和更加广泛的应用范围。我们先分析了系统结构,文件结构,然后在研究各个部分的具体实现的同时开始进行的cLucene实现。限于时间的限制,到本文完成为止,cLucene项目并没有完成,对于Lucene的具体实现部分也仅仅完成到了索引引擎部分。
 
接下来的部分,本文将对Lucene的系统结构、文件结构、索引引擎部分做一个彻底的分析。以期望提供对Lucene全文检索引擎的系统架构和部分程序实现的清晰的了解。cLucene项目则作为一个开放源代码的项目,继续进行的开发。
 
       有关cLucene项目的一些信息:
n          开发语言:ISO C++ [15],STLport 4.5.3 [16],OpenTop 1.1 [17]
n          目标平台:Win32,POSIX
n          授权协议:GNU General Public License (GPL) [18]
 
 
第二节 Lucene 系统结构分析
 
 
Lucene作为一个优秀的全文检索引擎,其系统结构具有强烈的面向对象特征。首先是定义了一个与平台无关的索引文件格式,其次通过抽象将系统的核心组成部分设计为抽象类,具体的平台实现部分设计为抽象类的实现,此外与具体平台相关的部分比如文件存储也封装为类,经过层层的面向对象式的处理,最终达成了一个低耦合高效率,容易二次开发的检索引擎系统。
 
以下将讨论Lucene系统的结构组织,并给出系统结构与源码组织图:
 
    从图中我们清楚的看到,Lucene的系统由基础结构封装、索引核心、对外接口三大部分组成。其中直接操作索引文件的索引核心又是系统的重点。Lucene的将所有源码分为了7个模块(在java语言中以包即package来表示),各个模块所属的系统部分也如上图所示。需要说明的是org.apache.lucene.queryPaser是做为org.apache.lucene.search的语法解析器存在,不被系统之外实际调用,因此这里没有当作对外接口看待,而是将之独立出来。
 
    从面象对象的观点来考察,Lucene应用了最基本的一条程序设计准则:引入额外的抽象层以降低耦合性。首先,引入对索引文件的操作org.apache.lucene.store的封装,然后将索引部分的实现建立在(org.apache.lucene.index)其之上,完成对索引核心的抽象。在索引核心的基础上开始设计对外的接口org.apache.lucene.search与org.apache.lucene.analysis。在每一个局部细节上,比如某些常用的数据结构与算法上,Lucene也充分的应用了这一条准则。在高度的面向对象理论的支撑下,使得Lucene的实现容易理解,易于扩展。
 
    Lucene在系统结构上的另一个特点表现为其引入了传统的客户端服务器结构以外的的应用结构。Lucene可以作为一个运行库被包含进入应用本身中去,而不是做为一个单独的索引服务器存在。这自然和Lucene开放源代码的特征分不开,但是也体现了Lucene在编写上的本来意图:提供一个全文索引引擎的架构,而不是实现。
 
 
理解Lucene系统结构的另一个方式是去探讨其中数据流的走向,并以此摸清楚Lucene系统内部的调用时序。在此基础上,我们能够更加深入的理解Lucene的系统结构组织,以方便以后在Lucene系统上的开发工作。这部分的分析,是深入Lucene系统的钥匙,也是进行重写的基础。
 
   我们来看看在Lucene系统中的主要的数据流以及它们之间的关系图:

索引查找逻辑
 
索引构建逻辑
 
查询语句语法分析逻辑
 
词法分析逻辑
 
存储抽象
 

 
    图2.2很好的表明了Lucene在内部的数据流组织情况,并且沿着数据流的方向我们也可以对与Lucene内部的执行时序有一个清楚的了解。现在将图中的涉及到的流的类型与各个逻辑对应系统的相关部分的关系说明一下。
 
    图中共存在4种数据流,分别是文本流、token流、字节流与查询语句对象流。文本流表示了对于索引目标和交互控制的抽象,即用文本流表示了将要索引的文件,用文本流向用户输出信息;在实际的实现中,Lucene中的文本流采用了UCS-2 [19]作为编码,以达到适应多种语言文字的处理的目的。Token流是Lucene内部所使用的概念,是对传统文字中的词的概念的抽象,也是Lucene在建立索引时直接处理的最小单位;简单的讲Token就是一个词和所在域值的组合,后面在叙述文件格式时也将继续涉及到token,这里不详细展开。字节流则是对文件抽象的直接操作的体现,通过固定长度的字节(Lucene定义为8比特位长,后面文件格式将详细叙述)流的处理,将文件操作解脱出来,也做到了与平台文件系统的无关性。查询语句对象流则是仅仅在查询语句解析时用到的概念,它对查询语句抽象,通过类的继承结构反映查询语句的结构,将之传送到查找逻辑来进行查找的操作。
 
    图中的涉及到了多种逻辑,基本上直接对应于系统某一模块,但是也有跨模块调用的问题发生,这是因为Lucene的重用程度非常好,因此很多实现直接调用了以前的工作成果,这在某种程度上其实是加强了模块耦合性,但是也是为了避免系统的过于庞大和不必要的重复设计的一种折衷体现。词法分析逻辑对应于org.apache.lucene.analysis部分。查询语句语法分析逻辑对应于org.apache.lucene.queryParser部分,并且调用了org.apache.lucene.analysis的代码。查询结束之后向评分排序逻辑输出token流,继而由评分排序逻辑处理之后给出文本流的结果,这一部分的实现也包含在了org.apache.lucene.search中。索引构建逻辑对应于org.apache.lucene.index部分。索引查找逻辑则主要是org.apache.lucene.search,但是也大量的使用了org.apache.lucene.index部分的代码和接口定义。存储抽象对应于org.apache.lucene.store。没有提到的模块则是做为系统公共基础设施存在。
 
三、             基于 Lucene 的应用开发
 
通过以上的系统结构分析和数据流分析,我们已经很清楚的了解了Lucene的系统的结构特征。在此基础上,我们可以通过扩充Lucene系统来完成一个完备的全文检索引擎,紧接着还可以在全文检索引擎的基础上构建各种应用系统。鉴于本文的目的并不在此,以下我们只是略为叙述一下相关的步骤,从而给出应用开发的一些思路。
 
首先,我们需要的是按照目标语言的词法结构来构建相应的词法分析逻辑,实现Lucene在org.apache.lucene.analysis中定义的接口,为Lucene提供目标系统所使用的语言处理能力。Lucene默认的已经实现了英文和德文的简单词法分析逻辑(按照空格分词,并去除常用的语法词,如英语中的is,am,are等等)。在这里,主要需要参考实现的接口在org.apache.lucene.analysis中的Analyzer.java和Tokenizer.java中定义,Lucene提供了很多英文规范的实现样本,也可以做为实现时候的参考资料。其次,需要按照被索引的文件的格式来提供相应的文本分析逻辑,这里是指除开词法分析之外的部分,比如HTML文件,通常需要把其中的内容按照所属于域分门别类加入索引,这就需要从org.apache.lucene.document中定义的类document继承,定义自己的HTMLDocument类,然后就可以将之交给org.apache.lucene.index模块来写入索引文件。完成了这两步之后,Lucene全文检索引擎就基本上完备了。这个过程可以用下图表示:
 
    当然,上面所示的仅仅只是对于Lucene的基本扩充过程,它将Lucene由不完备的变成完备的(尤其是对于非英语的语言检索)。除此之外我们还可以在很多方面对Lucene进行改造。第一个方面即为按照文档索引的域,比如标题,作者之类的信息对返回的查询结果排序,这即需要改造Lucene的评分排序逻辑。默认的,Lucene采用其内部的相关性方法来处理评分和排序,我们可以根据需要改变它。遗憾的是,这部分Lucene并没有做到如同扩充词法解析和文档类型那样的条理清晰,没有留下很好的接口,因此需要仔细的分析其源代码的实现,自行扩充等等。其他的方面,比如改进其索引的效率,改进其返回结果时候的缓冲机制等等,都是加强Lucene系统的方面,在此也不再叙述。
 
    完成了Lucene系统,之后就可以开始考虑其上的应用系统开发。如果应用系统也使用java语言开发,那么Lucene系统能够方便的嵌入到整个系统中去,作为一个API集来调用。这个过程十分简单,以下便是一个示例程序,配合注释理解起来很容易。

图 2.4 Lucene应用代码示例
 

 
    或者,Lucene全文检索引擎也可作为服务器程序启动,但是这就需要用户自行扩充其他应用与Lucene的接口。这个可以通过传统的包装方式,比如客户服务器结构,或者采用现在流行的Web方式。诸如此类的应用方案,本文也不再继续叙述。参考Lucene的项目网站中的用户邮件列表能找到更多的信息。
 
 
第三节 Lucene 索引文件格式分析
 
一、             Lucene 源码实现分析的说明
 
通过以上对Lucene系统结构的分析,我们已经大致的清楚了Lucene系统的组成,以及在Lucene系统之上的开发步骤。接下来,我们试图来分析Lucene项目(采用Lucene 1.2版本)的源码实现,考察其实现的细节。这不仅仅是我们尝试用C++语言重新实现Lucene的必须工作,也是进一步做Lucene开发工作的必要准备。因此,这一部分所涉及到的内容,对于Lucene上的应用开发也是有价值的,尤其是本部分所做的文件格式分析。
 
    由于本文建立在我们的毕设项目之上,且同时我们需要实现cLucene项目,因此很遗憾的我们并没有完全的完成Lucene的所有源码实现的分析工作。接下来的部分,我们将涉及的部分为Lucene文件格式分析,Lucene中的存储抽象模块分析,以及Lucene中的索引构建逻辑模块分析。这一部分,我们主要涉及到的是文件格式分析与存储抽象模块分析。
 
 
在Lucene的web站点上,有关于Lucene的文件格式的规范,其规定了Lucene的文件格式采取的存储单位、组织结构、命名规范等等内容,但是它仅仅是一个规范说明,并没有从实现者角度来衡量这个规范的实现。因此,我们以下的内容,结合了我们自己的分析与文件格式的定义规范,以期望给出一个更加清晰的文件格式说明。具体的文档规范可以参考后面的文献2。
 
    首先在Lucene的文件格式中,以字节为基础,定义了如下的数据类型:
 
3.1 Lucene 文件格式中定义的数据类型
数据类型
所占字节长度(字节)
说明
Byte
1
基本数据类型,其他数据类型以此为基础定义
UInt32
4
32 位无符号整数,高位优先
UInt64
8
64 位无符号整数,高位优先
VInt
不定,最少 1 字节
动态长度整数, 每字节的最高位表明还剩多少字节,每字节的低七位表明整数的值,高位优先。可以认为值可以为无限大。其示例如下
字节 1
字节 2
字节 3
0
00000000
 
 
1
00000001
 
 
2
00000010
 
 
127
01111111
 
 
128
10000000
00000001
 
129
10000001
00000001
 
130
10000010
00000001
 
16383
10000000
10000000
00000001
16384
10000001
10000000
00000001
16385
10000010
10000000
00000001
Chars
不定,最少 1 字节
采用 UTF-8 编码 [20] Unicode 字符序列
String
不定,最少 2 字节
VInt Chars 组成的字符串类型, VInt 表示 Chars 的长度, Chars 则表示了 String 的值
 
    以上的数据类型就是Lucene索引文件格式中用到的全部数据类型,由于它们都以字节为基础定义而来,因此保证了是平台无关,这也是Lucene索引文件格式平台无关的主要原因。接下来我们看看Lucene索引文件的概念组成和结构组成。
    以上就是Lucene的索引文件的概念结构。Lucene索引index由若干段(segment)组成,每一段由若干的文档(document)组成,每一个文档由若干的域(field)组成,每一个域由若干的项(term)组成。项是最小的索引概念单位,它直接代表了一个字符串以及其在文件中的位置、出现次数等信息。域是一个关联的元组,由一个域名和一个域值组成,域名是一个字串,域值是一个项,比如将“标题”和实际标题的项组成的域。文档是提取了某个文件中的所有信息之后的结果,这些组成了段,或者称为一个子索引。子索引可以组合为索引,也可以合并为一个新的包含了所有合并项内部元素的子索引。我们可以清楚的看出,Lucene的索引结构在概念上即为传统的倒排索引结构 [21]
 
    从概念上映射到结构中,索引被处理为一个目录(文件夹),其中含有的所有文件即为其内容,这些文件按照所属的段不同分组存放,同组的文件拥有相同的文件名,不同的扩展名。此外还有三个文件,分别用来保存所有的段的记录、保存已删除文件的记录和控制读写的同步,它们分别是segments,deletable和lock文件,都没有扩展名。每个段包含一组文件,它们的文件扩展名不同,但是文件名均为记录在文件segments中段的名字。让我们看如下的结构图3.2。

项集合信息
 
项位置
 
项频数
 
被删除文档
 
标准化因子
 
图 3.2 Lucene索引文件结构组成
 
segment1 所含文件
 
项字典
 
域值存储表
 
域集合信息
 
index
 

 
    关于图3.2中的各个文件具体的内部格式,在参考文献3中,均可以找到详细的说明。接下来我们从宏观关系上说明一下这些文件组成。在这些宏观上的关系理清楚之后,仔细阅读参考文献3,即可清楚的明白具体的Lucene文件格式。
 
    每个段的文件中,主要记录了两大类的信息:域集合与项集合。这两个集合中所含有的文件在图3.2中均有表明。由于索引信息是静态存储的,域集合与项集合中的文件组采用了一种类似的存储办法:一个小型的索引文件,运行时载入内存;一个对应于索引文件的实际信息文件,可以按照索引中指示的偏移量随机访问;索引文件与信息文件在记录的排列顺序上存在隐式的对应关系,即索引文件中按照“索引项1、索引项2…”排列,则信息文件则也按照“信息项1、信息项2…”排列。比如在图3.2所示文件中,segment1.fdx与segment1.fdt之间,segment1.tii与segment1.tis、segment1.prx、segment1.frq之间,都存在这样的组织关系。而域集合与项集合之间则通过域的在域记录文件(比如segment1.fnm)中所记录的域记录号维持对应关系,在图3.2中segment1.fdx与segment1.tii中就是通过这种方式保持联系。这样,域集合和项集合不仅仅联系起来,而且其中的文件之间也相互联系起来。此外,标准化因子文件和被删除文档文件则提供了一些程序内部的辅助设施(标准化因子用在评分排序机制中,被删除文档是一种伪删除手段)。这样,整个段的索引信息就通过这些文档有机的组成。
 
    以上所阐述的,就是Lucene所采用的索引文件格式。基本上而言,它是一个倒排索引,但是Lucene在文件的安排上做了一些努力,比如使用索引/信息文件的方式,从文件安排的形式上提高查找的效率。这是一种数据库之外的处理方法,其有其优点(格式平台独立、速度快),也有其缺点(独立性带来的共享访问接口问题等等),具体如何衡量两种方法之间的利弊,本文这里就不讨论了。
 
 
分析完索引文件格式,我们接下来应该着手对存储抽象也就是org.apache.lucenestore中的源码做一些分析。我们先不着急分析这部分,而是分析图2.1中基础结构封装那一部分,因为这是整个系统的基石,然后我们在下一部分再来分析存储抽象。
 
    基础结构封装,或者基础类,由org.apache.lucene.util和org.apache.lucene.document两个包组成,前者定义了一些常量和优化过的常用的数据结构和算法,后者则是对于文档(document)和域(field)概念的一个类定义。以下我们用列表的方式来分析这些封装类,指出其要点。
 
3.2 基础类包 org.apache.lucene.util
说明
Arrays
一个关于数组的排序方法的静态类,提供了优化的基于快排序的排序方法 sort
BitVector
C/C++ 语言中位域的 java 实现品,但是加入了序列化能力
Constants
常量静态类,定义了一些常量
PriorityQueue
一个优先队列的抽象类,用于后面实现各种具体的优先队列,提供常数时间内的最小元素访问能力,内部实现机制是哈析表和堆排序算法
 
3.3 基础类包 org.apache.lucene.document
说明
Document
是文档概念的一个实现类,每个文档包含了一个域表( fieldList ),并提供了一些实用的方法,比如多种添加域的方法、返回域表的迭代器的方法
Field
是域概念的一个实现类,每个域包含了一个域名和一个值,以及一些相关的属性
DateField
提供了一些辅助方法的静态类,这些方法将 java Date Time 数据类型和 String 相互转化
 
总的来说,这两个基础类包中含有的类都比较简单,通过阅读源代码,可以很容易的理解,因此这里不作过多的展开。
 
 
有了上面的知识,我们接下来来分析存储抽象部分,也就是org.apache.lucene.store包。存储抽象是唯一能够直接对索引文件存取的包,因此其主要目的是抽象出和平台文件系统无关的存储抽象,提供诸如目录服务(增、删文件)、输入流和输出流。在分析其实现之前,首先我们看一下UML [22]图。
图 3.3 存储抽象实现UML图(一)
图 3.4 存储抽象实现UML图(二)
图 3.4 存储抽象实现UML图(三)
 
    图3.2到3.4展示了整个org.apache.lucene.store中主要的继承体系。共有三个抽象类定义:Directory、InputStream和OutputStrem,构成了一个完整的基于抽象文件系统的存取体系结构,在此基础上,实作出了两个实现品:(FSDirectory,FSInputStream,FSOutputStream)和(RAMDirectory,RAMInputStream和RAMOutputStream)。前者是以实际的文件系统做为基础实现的,后者则是建立在内存中的虚拟文件系统。前者主要用来永久的保存索引文件,后者的作用则在于索引操作时是在内存中建立小的索引,然后一次性的输出合并到文件中去,这一点我们在后面的索引逻辑部分能够看到。此外,还定以了org.apache.lucene.store.lock和org.apache.lucene.store.with两个辅助内部实现的类用在实现Directory方法的makeLock的时候,以在锁定索引读写之前来让客户程序做一些准备工作。
 
    (FSDirectory,FSInputStream,FSOutputStream)的内部实现依托于java语言中的io类库,只是简单的做了一个外部逻辑的包装。这当然要归功于java语言所提供的跨平台特性,同时也带了一些隐患:文件存取的效率提升需要依耐于文件类库的优化。如果需要继续优化文件存取的效率,应该还提供一个文件与目录的抽象,以根据各种文件系统或者文件类型来提供一个优化的机会。当然,这是应用开发者所不需要关系的问题。
 
    (RAMDirectory,RAMInputStream和RAMOutputStream)的内部实现就比较直接了,直接采用了虚拟的文件RAMFile类(定义于文件RAMDirectory.java中)来表示文件,目录则看作一个String与RAMFile对应的关联数组。RAMFile中采用数组来表示文件的存储空间。在此的基础上,完成各项操作的实现,就形成了基于内存的虚拟文件系统。因为在实际使用时,并不会牵涉到很大字节数量的文件,因此这种设计是简单直接的,也是高效率的。
 
    这部分的实现在理清楚继承体系后,相当的简单。因此接下来的部分,我们可以通过直接阅读源代码解决。接下来我们看看这个部分的源代码如何在实际中使用的。
 
    一般来说,我们使用的是抽象类提供的接口而不是实际的实现类本身。在实现类中一般都含有几个静态函数,比如createFile,它能够返回一个OutputStream接口,或者openFile,它能够返回一个InputStream接口,利用这些接口之中的方法,比如writeString,writeByte等等,我们就能够在抽象的层次上处理Lucene定义的数据类型的读写。简单的说,Lucene中存储抽象这部分设计时采用了工厂模式(Factory parttern) [23]。我们利用静态类的方法也就是工厂来创建对象,返回接口,通过接口来执行操作。
 
 
这一部分详细的说明了Lucene系统中所采用的索引文件格式、一些基础类和存储抽象。接下来我们来叙述一下我们在项目cLucene中重新实现这些结构时候的一些考虑。
 
    cLucene彻底的遵守了Lucene所定义的索引文件格式,这是Lucene对于各个兼容系统的基本要求。在此基础上,cLucene系统和Lucene系统才能够共享索引文件数据。或者说,cLucene生成的索引文件和Lucene生成的索引文件完全等价。
 
    在基础类问题上,cLucene同样封装了类似的结构。我们同样列表描述,请和前面的表3.2与3.3对照比较。
3.4 基础类包 cLucene::util
说明
Arrays
没有实现,直接利用了 STL 库中的快排序算法实现
BitVector
C/C++ 语言版本的实现,与 java 实现版本类似
Constants
常量静态类,定义了一些常量,但是与 java 版本不同的是,这里主要定义了一些宏
PriorityQueue
这是一个类型定义,直接利用 STL 库中的 std::priority_queue
 
3.3 基础类包 cLucene::document
说明
Document
C/C++ 语言版本的实现,与 java 实现版本类似
Field
C/C++ 语言版本的实现,与 java 实现版本类似
DateField
没有实现,直接利用 OpenTop 库中的 ot::StringUtil
 
    存储抽象的实现上,也同样是类似于java实现。由于我们采用了OpenTop库,因此同样得以借助其中对于文件系统抽象的ot::io包来解决文件系统问题。这部分问题与前面一样,存在优化的可能。在实现的类层次上、对外接口上,均与java版本的一样。
 
 
第四节 Lucene 索引构建逻辑模块分析
 
 
这一个部分,我们将分析Lucene中的索引构建逻辑模块。它与前面介绍的存储抽象一起构成了Lucene的索引核心部分。无论是对外接口中的查询,还是分析各种文本以进一步生成索引,都需要直接调用这部分来获得对索引文件的访问能力,因此,这部分在系统中至关重要。构建一个高效的、易使用的索引构建逻辑,即是Lucene在这一部分需要达到的目的。
 
    从面向对象的经典思考方式出发来看,我们只需要使用继承体系来表达图3.1中的各个概念,就可以通过这个继承体系来控制索引文件的结构,然后设计合适的永久化方法,以及接受分析token流的操作,即可将索引构建逻辑完成。原理上就是这样的简单。由于两个关键的概念document和field都已经在org.apache.lucene.document中当作基础类定义过了,因此实际上Lucene在这部分需要完善的概念结构还有segment和term。在此基础上继续编写各个逻辑结构的永久化方法,然后提供一个进入的接口方法,即是宣告完成了这个过程。其中永久化的部分,Lucene使用了另外实现一个代理类的方式来实现,即对于某个类X,存在XWriter类和XReader类来负责写出和读入的功能;用作永久化功能的类是被永久化的类的友元。
 
    在接下来的分析过程中,我们按照这样一个思路,以UML图和对象体系的描述来叙述这部分的设计和实现,然后通过内部的数据流理清楚调用时序。
 
 
1. 项(Term)
 
这部分主要是分析针对项(Term)这个概念所做的设计,包括概念所实际涉及的类、永久化类。首先,我们从图3.2和阅读参考文献3知道,项(Term)所表示的是一个字符串,它拥有域、频数和位置信息等等属性。因此,Lucene中设计了两个类来表示这个概念,如下图
图 4.1 UML图(-)
 
上图中,有意的突出了类Term和TermInfo中的数据成员,因为它反映了对于项(Term)这个概念的具体表示。同时上图中也同时列出了用于永久化项(Term)的代理类TermInfosWriter和TermInfosReader,它们完成永久化的功能,需要注意的是,TermInfosReader内部使用了数组indexTerms和indexInfos来存储一系列项;而TermInfosWriter则是一个类似于链表的结构,通过一个other指向下一个TermInfosWriter,每一个TermInfosWriter只负责本身那个lastTerm和lastTi的永久化工作。这是一个设计上的技巧,通过批量读取(或者称为缓冲的方式)来获得读入时候的效率优化;而通过一个链表式的、各负其责的方式,来获得写出时候的设计简化。
 
项(term)这部分的设计中,还有一些重要的接口和类,我们先介绍如下,同样我们也先展示UML图
图 4.2 UML图(二)
 
图4.2中,我们看到三个类:TermEnum、TermDocs与TermPositions,第一个是抽象类,后两个都是接口。TermEnum的设计主要用在后面Segment和Document等等的实现中,以提供枚举其中每一个项(Term)的能力。TermDocs是一个接口,用来继承以提供返回<document, frequency>值对的能力,通过这个接口就可以获得某个项(Term)在某个文档中出现的频数。TermPositions则是在TermDocs上的扩展,将项(Term)在文档中的位置信息也表示出来。TermDocs(TermPositions)接口的使用方式类似于java中的Enumration接口,即通过next方法跳转,通过doc,freq等方法获得当前的属性值。
 
2. 域(Field)
 
由于Field的基本概念在org.apache.lucene.document中已经做了定义,因此在这部分主要是针对项文件(.fnm文件、.fdx文件、.fdt文件)所需要的信息再来设计一些类。
图 4.3 UML图(三)
 
图 4.3中展示的,就是表示与域(Field)所关联的属性信息的类。其中isIndexed表示的这个域的值是否被索引过,即值是否被分词然后索引;另外两个属性所表示的意思则很明显:一个是域的名字,一个是域的编号。
 
接下来我们来看关于域表和存取逻辑的UML图。
图 4.4 UML图(四)
FieldInfos即为域表的概念表示,内部采用了冗余的方式以获取在通过域的编号访问或者通过域的名字来访问时候的高效率。FieldsReader与FieldsWriter则分别是写出和读入的代理类。在功能和实现上,这两个类都比较简单。至于FieldInfos中采用的冗余方式,则是基于域的数目相对比较少而做出的一种折衷处理。
 
3. 文档(document)
 
文档(document)同样也是在org.apache.lucene.document中定义过的结构。由于对于这部分比较重要,我们也来看看其UML图。
图 4.5 UML图(五)
 
在图4.5中我们看到,Document的设计基本上沿用了链表的处理方法。左边的Document类作为一个数据外包类,用来提供对于内部结构DocumentFieldList的增加删除访问操作等等。DocumentFieldList才是实际上的数据存储单位,它用了链表的处理方法,直接指向一个当前的Field对象和下一个DocumentFieldList对象,这个与前面的类似。为了能够逐个访问链表中的节点,还设计了DocumentFieldEnumeration枚举类。
图 4.6 UML图(六)
    实际上定义于org.apache.lucene.index中的有关于Document的就是永久化的代理类。在图4.6中给出了其UML图。需要说明的是为什么没有出现读入的方法:这个方法已经隐含在图4.5中Document类中的add方法中了,结合图2.4中的程序代码段,我们就能够清楚的理解这种设计。
 
4. 段(segment)
 
段(Segment)这一部分设计的比较特殊,在实现简单的对象结构之上,还特意的设计了用于段之间合并的类。接下来,我们仍然采取对照UML分析的方式逐个叙述。接下来我们看Lucene中如何表示段这个概念。
图 4.7 UML图(七)
Lucene定义了一个类SegmentInfo用来表示每一个段(Segment)的信息,包括名字(name)、含有的文档的数目(docCount)和段所位于的目录的位置(dir)。根据索引文件中的段的意义,有了这三点,就能唯一确定一个段了。SegmentInfos这个类则是用来表示一个段的链表(从标准的java.util.Vector继承而来),实际上,也就是索引(index)的意思了。需要注意的是,这里并没有在SegmentInfo中安插一个文档(document)的链表。这样做的原因牵涉到Lucene内部对于文档(相当于一个被索引文件)的处理;Lucene内部采用了赋予文档编号,给域赋值的方式来处理文档,即加入的文档顺次编号,以后用文档号表示文档,而路径信息,文件名字等等在以后索引查找需要的属性,都作为域存储下来;因此SegmentInfo中并没有另外存储一个文档(document)的链表,对于这些的写出和读入,则交给了永久化的代理类来做。
 
图 4.8 UML图(八)
图4.8给出了负责段(segment)的读入操作的代理类,而负责段(segment)的写出操作也同样没有定义,这些操作都直接实现在了类IndexWriter类中(后面会详细分析)。段的操作同样采用了之前的数组或者说是缓冲的处理方式,相关的细节也不在这里详细叙述了。
 
然后,针对前面项(term)那部分定义的几个接口,段(segment)这部分也需要做相应的接口实现,因为提供直接遍历访问段中的各个项的能力对于检索来说,无疑是十分重要的。即这部分的设计,实际上都是在为了检索在服务。
图 4.9 UML图(九)
 
图 4.10 UML图(十)
图4.9和图4.10分别展示了前面项(term)那里定义的接口是如何在这里通过继承实现的。Lucene在处理这部分的时候,也是分成两部分(Segment与Segments开头的类)来实现,而且很合理的运用了数组的技法,以及注意了继承重用。但是细化到局部,终归是比较简单的按照语义来获得结果而已了,因此关于更多的也就不多做分析了,我们完全可以通过阅读源代码来解决。
 
接下来所介绍的,就是在Lucene的设计过程中比较特殊的一个部分:段合并类(SegmentMerger)。这首先需要介绍Lucene中的建立索引时的段合并策略。
 
Lucene为了兼顾建立索引时的效率和读取索引查找的速度,引入了分小段建立索引的方式,即每一次批量建立索引时,先在内存中的虚拟文件系统中为每一个文档单独建立一个段,然后在输出的时候将这些段合并之后输出成为索引文件,这时仅仅存在一个段。多次建立的索引后,如果想优化索引文件,也可采取合并段的方法,将索引中的段合并成为一个段。我们来看一下在IndexWriter类中相应的方法的实现,来了解一下这中建立索引的实现。
    对于上面的代码,我们不做过多注释了,结合源码中的注解应该很容易理解。在最后那个mergeSegments函数中,将用到几个重要的类结构,它们记录了合并时候的一些重要信息,完成合并时候的工作。接下来,我们来看这几个类的UML图。
图 4.12 UML图(十一)
从图4.12中,我们看到Lucene设计一个类SegmentMergeInfo用来保存每一个被合并的段的信息,也保存能够访问其内部的接口句柄,也就是说合并时的操作使用这个类作为对被合并的段的操作代理。类SegmentMergeQueue则设计为org.apache.lucene.util.PriorityQueue的子类,做为SegmentMergeInfo的容器类,而且附带能够自动排序。SegmentMerger是主要进行操作的类,里面各个方法环环相扣,分别完成合并各个数据项的问题。
 
5. IndexReader类与IndexWirter类
 
最后剩下的,就是整个索引逻辑部分的使用接口类了。外界通过这两个类以及文档(document)类的构造函数调用之,比如图2.4中的代码示例所示。下面我们来看一下这部分最后两个类的UML图。
图 4.13 UML图(十二)
 
    IndexWriter的设计与IndexReader的设计很不相同,前者是一个实现类,而后者是一个抽象类,带有没有实现的接口。IndexWriter的主要作用就是接收新加入的文档(document),然后在内部为之生成相应的小段,最后再合并并向索引文件中输出,图4.11中已经给出了一些实现的代码。由于Lucene在面向对象上封装的努力,通过各个构造函数就已经完成了对于各个概念的构造过程,剩下部分的代码主要是依据各个数组或者是链表中的信息,逐个逐个的将信息写出到相应的文件中去了。IndexReader部分则只是做了接口设计,没有具体的实现,这个和本部分所完成的主要功能有关:索引构建逻辑。设计这个抽象类的目的是,预先完成一些函数,为以后的检索(search)部分的各种形式的IndexReader铺平道路,也是利用了在同一个包内可以方便访问其它类的保护变量这个java语言的限制。
 
    到此,在索引构建逻辑部分出现的类我们就分析完毕了,需要说明主要是做的一个宏观上的组成结构上的分析,并指出一些实现上的要点。具体的实现,由于Lucene的开放源码而显得并不是非常的重要,因为Lucene在做到良好的面相对象设计之后,实际带来的是局部复杂性的减小,因此某一些单独的函数或者实现就比较容易编写,也容易让人阅读。本文不再继续叙述这方面的细节,作为一个总结,下一个部分我们通过索引构建逻辑的数据流图的方式,再来理清楚一下索引构建逻辑这部分的调用时序。
 
 
 
从宏观上明白一个系统的设计,理清楚其中的运行规律,最好的方式应该是通过数据流图。在分析了各个位于索引构建逻辑部分的类的设计之后,我们接下来就通过分析数据流图的方式来总结一下。但是由于之前提到的原因:索引读入部分在这一部分并没有完全实现,所以我们在数据流图中主要给出的是索引构建的数据流图。
 

图 4.14 索引构建部分的数据流逻辑
 
合并输出
 
字节流输入
 
内存文件系统
 
writeNorms 写出标准化因子
 
sortPostingTable 排序位置信息
 
writePostings 写出索引信息
 
invertDocument 分析文档
 
addDocument 生成小段
 
加入 document 对象
 
document 对象方式传入
 
调用
 
生成 field 对象,根据对象性质不同,为值赋予 String 值,或者是 Reader
 
生成 document 对象,调用 add 方法加入 field 对象
 
通过 java 语言的 io 类以输入流方式传入
 

 
对于图4.14中所描述的内容,结合Lucene源代码中的一些文件看,能够加深理解。准备阶段可以参考demo文件夹中的org.apache.lucene.demo.IndexFiles类和java文件夹中的org.apache.lucene.document文件包。索引构建阶段的主要源码位于java文件夹中org.apache.lucene.index.IndexWriter类,因此这部分可以结合这个类的实现来看。至于内存文件系统,比较复杂,但是这时的逻辑相对简单,因此也不难理解。
 
    上面的数据流图十分清楚的勾画除了整个索引构建逻辑这部分的设计:通过层层嵌套的类结构,在构建时候即分步骤有计划的生成了索引结构,将之存储到内存中的文件系统中,然后通过对内存中的文件系统优化合并输出到实际的文件系统中。
 
 
前面的三个部分,已经完成了分析索引构建逻辑的任务,这里我们还是有针对性的谈谈我们这次的毕业设计项目cLucene在这一部分的情况。
 
在实现这部分的时候,为了将一些java语法中比较特殊的部分,比如内隐类、同步函数、同步对象等等,我们不得不采用了一些比较晦涩和艰深的C++语法,在OpenTop这个类库所提供的类似于java语言的设施上来实现。这个尤其体现在实现Segment相关类时,为了处理原来java源代码中用内隐类实现的Lock文件创建机制的时候,我们不得不定义了大量的cLucene::store::With的子类,并为之传入调用类的指针,设置它为调用类的友元,才得以精确的模拟了原有的语义。陷于我们这次的重写以移植为主,系统结构基本上没有大的变化,不得不产生这种重复而且大量的工作。如果需要改进这中状况,我们应该考虑按照C++语言的特点来设计索引构建部分的类库继承结构,但是很可惜在本文成文之前,时间不允许我们这样做。
 
来自java语法的特殊性只是我们解决问题的一个方面,我们还需要处理引用的调用方式。由于java语言拥有了垃圾收集机制,因此得以将一切的参数形式看作为引用,而不考虑其分配与消亡的问题。C++语言并不具备这种机制,它需要程序员自行管理分配空间与销毁对象的问题。在这里,我们使用的是来自OpenTop中所引入的计数指针RefPtr<>模板,它能够模拟指针的语义,并且计算指针被引用的次数,在引用次数为0时就自动释放资源:这是一种类似于java语言中引用的方式,不过它显得更加高效率。我们在cLucene的实现中大量的使用了计数指针模板。
 
    除此之外,我们没有改变Lucene所定义的索引构建逻辑的结构和语义,我们实现的是一个完全和java版本Lucene兼容的版本。

来源:  http://blog.csdn.net/gooogledev/archive/2007/05/05/1597219.aspx
google搜索原理论文 

这篇文章中,我们介绍了google,它是一个大型的搜索引擎(of a large-scale search engine)的原型,搜索引擎在超文本中应用广泛。Google的设计能够高效地抓网页并建立索引,它的查询结果比其它现有系统都高明。这个原型的全文和超连接的数据库至少包含24'000'000个网页。我们可以从http://google.stanford.edu/ 下载。

设计搜索引擎是一项富有挑战性的工作。搜索引擎为上亿个网页建立索引,其中包含大量迥然不同的词汇。而且每天要回答成千上万个查询。在网络中,尽管大型搜索引擎非常重要,但是学术界却很少研究它。此外由于技术的快速发展和网页的大量增加,现在建立一个搜索引擎和三年前完全不同。

本文详细介绍了我们的大型搜索引擎,据我们所知,在公开发表的论文中,这是第一篇描述地如此详细。除了把传统数据搜索技术应用到如此大量级网页中所遇到的问题,还有许多新的技术挑战,包括应用超文本中的附加信息改进搜索结果。

本文将解决这个问题,描述如何运用超文本中的附加信息,建立一个大型实用系统。任何人都可以在网上随意发布信息,如何有效地处理这些无组织的超文本集合,也是本文要关注的问题。

关键词 World Wide Web,搜索引擎,信息检索,PageRank, Google

1 绪论
Web给信息检索带来了新的挑战。Web上的信息量快速增长,同时不断有毫无经验的新用户来体验Web这门艺术。人们喜欢用超级链接来网上冲浪,通常都以象Yahoo这样重要的网页或搜索引擎开始。大家认为List(目录)有效地包含了大家感兴趣的主题,但是它具有主观性,建立和维护的代价高,升级慢,不能包括所有深奥的主题。基于关键词的自动搜索引擎通常返回太多的低质量的匹配。使问题更遭的是,一些广告为了赢得人们的关注想方设法误导自动搜索引擎。我们建立了一个大型搜索引擎解决了现有系统中的很多问题。应用超文本结构,大大提高了查询质量。我们的系统命名为google,取名自googol的通俗拼法,即10的100次方,这和我们的目标建立一个大型搜索引擎不谋而合。

1.1网络搜索引擎—升级换代(scaling up):
1994-2000 搜索引擎技术不得不快速升级(scale dramatically)跟上成倍增长的web数量。
1994年,第一个Web搜索引擎,World Wide Web Worm(WWWW)可以检索到110,000个网页和Web的文件。
到1994年11月,顶级的搜索引擎声称可以检索到2‘000'000(WebCrawler)至100‘000'000个网络文件(来自 Search Engine Watch)。
可以预见到2000年,可检索到的网页将超过1‘000'000‘000。同时,搜索引擎的访问量也会以惊人的速度增长。
在1997年的三四月份,World Wide Web Worm 平均每天收到1500个查询。
在1997年11月,Altavista 声称它每天要处理大约20'000'000个查询。随着网络用户的增长.
到2000年,自动搜索引擎每天将处理上亿个查询。我们系统的设计目标要解决许多问题,包括质量和可升级性,引入升级搜索引擎技术(scaling search engine technology),把它升级到如此大量的数据上。

1.2 Google:
跟上Web的步伐(Scaling with the Web)建立一个能够和当今web规模相适应的搜索引擎会面临许多挑战。抓网页技术必须足够快,才能跟上网页变化的速度(keep them up to date)。存储索引和文档的空间必须足够大。索引系统必须能够有效地处理上千亿的数据。处理查询必须快,达到每秒能处理成百上千个查询(hundreds to thousands per second.)。随着Web的不断增长,这些任务变得越来越艰巨。然而硬件的执行效率和成本也在快速增长,可以部分抵消这些困难。还有几个值得注意的因素,如磁盘的寻道时间(disk seek time),操作系统的效率(operating system robustness)。在设计Google的过程中,我们既考虑了Web的增长速度,又考虑了技术的更新。Google的设计能够很好的升级处理海量数据集。它能够有效地利用存储空间来存储索引。优化的数据结构能够快速有效地存取(参考4.2节)。进一步,我们希望,相对于所抓取的文本文件和HTML网页的数量而言,存储和建立索引的代价尽可能的小(参考附录B)。对于象Google这样的集中式系统,采取这些措施得到了令人满意的系统可升级性(scaling properties)。

1. 3设计目标
1.3.1提高搜索质量我们的主要目标是提高Web搜索引擎的质量。
1994年,有人认为建立全搜索索引(a complete search index)可以使查找任何数据都变得容易。根据Best of the Web 1994 -- Navigators ,“最好的导航服务可以使在Web上搜索任何信息都很容易(当时所有的数据都可以被登录)”。然而1997年的Web就迥然不同。近来搜索引擎的用户已经证实索引的完整性不是评价搜索质量的唯一标准。用户感兴趣的搜索结果往往湮没在“垃圾结果Junk result”中。实际上,到1997年11月为止,四大商业搜索引擎中只有一个能够找到它自己(搜索自己名字时返回的前十个结果中有它自己)。导致这一问题的主要原因是文档的索引数目增加了好几个数量级,但是用户能够看的文档数却没有增加。用户仍然只希望看前面几十个搜索结果。因此,当集合增大时,我们就需要工具使结果精确(在返回的前几十个结果中,有关文档的数量)。由于是从成千上万个有点相关的文档中选出几十个,实际上,相关的概念就是指最好的文档。高精确非常重要,甚至以响应(系统能够返回的有关文档的总数)为代价。令人高兴的是利用超文本链接提供的信息有助于改进搜索和其它应用 。尤其是链接结构和链接文本,为相关性的判断和高质量的过滤提供了大量的信息。Google既利用了链接结构又用到了anchor文本(见2.1和2.2节)。

1.3.2搜索引擎的学术研究随着时间的流逝,除了发展迅速,Web越来越商业化。
1993年,只有1.5%的Web服务是来自.com域名。到1997年,超过了60%。同时,搜索引擎从学术领域走进商业。到现在大多数搜索引擎被公司所有,很少技公开术细节。这就导致搜索引擎技术很大程度上仍然是暗箱操作,并倾向做广告(见附录A)。Google的主要目标是推动学术领域在此方面的发展,和对它的了解。另一个设计目标是给大家一个实用的系统。应用对我们来说非常重要,因为现代网络系统中存在大量的有用数据(us because we think some of the most interesting research will involve leveraging the vast amount of usage data that is available from modern web systems)。例如,每天有几千万个研究。然而,得到这些数据却非常困难,主要因为它们没有商业价值。我们最后的设计目标是建立一个体系结构能够支持新的关于海量Web数据的研究。为了支持新研究,Google以压缩的形式保存了实际所抓到的文档。设计google的目标之一就是要建立一个环境使其他研究者能够很快进入这个领域,处理海量Web数据,得到满意的结果,而通过其它方法却很难得到结果。系统在短时间内被建立起来,已经有几篇论文用到了Google建的数据库,更多的在起步中。我们的另一个目标是建立一个宇宙空间实验室似的环境,在这里研究者甚至学生都可以对我们的海量Web数据设计或做一些实验。

2. 系统特点
Google搜索引擎有两个重要特点,有助于得到高精度的搜索结果。
第一点,应用Web的链接结构计算每个网页的Rank值,称为PageRank,将在98页详细描述它。
第二点,Google利用超链接改进搜索结果。

2.1 PageRank:给网页排序 Web的引用(链接)图是重要的资源,却被当今的搜索引擎很大程度上忽视了。我们建立了一个包含518‘000'000个超链接的图,它是一个具有重要意义的样本。这些图能够快速地计算网页的PageRank值,它是一个客观的标准,较好的符合人们心目中对一个网页重要程度的评价,建立的基础是通过引用判断重要性。因此在web中,PageRank能够优化关键词查询的结果。对于大多数的主题,在网页标题查询中用PageRank优化简单文本匹配,我们得到了令人惊叹的结果(从google.stanford.edu可以得到演示)。对于Google主系统中的全文搜索,PageRank也帮了不少忙。

2.1.1计算PageRank 文献检索中的引用理论用到Web中,引用网页的链接数,一定程度上反映了该网页的重要性和质量。PageRank发展了这种思想,网页间的链接是不平等的。 PageRank定义如下:我们假设T1…Tn指向网页A(例如,被引用)。参数d是制动因子,使结果在0,1之间。通常d等于0.85。在下一节将详细介绍d。C(A)定义为网页A指向其它网页的链接数,网页A的PageRank值由下式给出: PR(A) = (1-d) + d (PR(T1)/C(T1) + ... + PR(Tn)/C(Tn)) 注意PageRank的形式,分布到各个网页中,因此所有网页的PageRank和是1。 PageRank或PR(A)可以用简单的迭代算法计算,相应规格化Web链接矩阵的主特征向量。中等规模的网站计算26‘000'000网页的PageRank值要花费几小时。还有一些技术细节超出了本文论述的范围。

2.1.2直觉判断 PageRank被看作用户行为的模型。我们假设网上冲浪是随机的,不断点击链接,从不返回,最终烦了,另外随机选一个网页重新开始冲浪。随机访问一个网页的可能性就是它的PageRank值。制动因子d是随机访问一个网页烦了的可能性,随机另选一个网页。对单个网页或一组网页,一个重要的变量加入到制动因子d中。这允许个人可以故意地误导系统,以得到较高的PageRank值。我们还有其它的PageRank算法,见98页。 另外的直觉判断是一个网页有很多网页指向它,或者一些PageRank值高的网页指向它,则这个网页很重要。直觉地,在Web中,一个网页被很多网页引用,那么这个网页值得一看。一个网页被象Yahoo这样重要的主页引用即使一次,也值得一看。如果一个网页的质量不高,或者是死链接,象Yahoo这样的主页不会链向它。PageRank处理了这两方面因素,并通过网络链接递归地传递。

2.2链接描述文字(Anchor Text)
我们的搜索引擎对链接文本进行了特殊的处理。大多数搜索引擎把链接文字和它所链向的网页(the page that the link is on)联系起来。另外,把它和链接所指向的网页联系起来。这有几点好处。
第一,通常链接描述文字比网页本身更精确地描述该网页。
第二,链接描述文字可能链向的文档不能被文本搜索引擎检索到,例如图像,程序和数据库。有可能使返回的网页不能被抓到。注意哪些抓不到的网页将会带来一些问题。在返回给用户前检测不了它们的有效性。这种情况搜索引擎可能返回一个根本不存在的网页,但是有超级链接指向它。然而这种结果可以被挑出来的,所以此类的问题很少发生。链接描述文字是对被链向网页的宣传,这个思想被用在World Wide Web Worm 中,主要因为它有助于搜索非文本信息,能够用少量的已下载文档扩大搜索范围。我们大量应用链接描述文字,因为它有助于提高搜索结果的质量。有效地利用链接描述文字技术上存在一些困难,因为必须处理大量的数据。现在我们能抓到24‘000'000个网页,已经检索到259‘000'000多个链接描述文字。

2.3其它特点除了PageRank和应用链接描述文字外,Google还有一些其它特点。
第一,所有hit都有位置信息,所以它可以在搜索中广泛应用邻近性(proximity)。
第二,Google跟踪一些可视化外表细节,例如字号。黑体大号字比其它文字更重要。
第三,知识库存储了原始的全文html网页。

3有关工作 Web检索研究的历史简短。
World Wide Web Worm()是最早的搜索引擎之一。后来出现了一些用于学术研究的搜索引擎,现在它们中的大多数被上市公司拥有。与Web的增长和搜索引擎的重要性相比,有关当今搜索引擎技术的优秀论文相当少。根据Michael Mauldin(Lycos Inc的首席科学家)) ,“各种各样的服务(包括Lycos)非常关注这些数据库的细节。”虽然在搜索引擎的某些特点上做了大量工作。具有代表性的工作有,对现有商业搜索引擎的结果进行传递,或建立小型的个性化的搜索引擎。最后有关信息检索系统的研究很多,尤其在有组织机构集合(well controlled collections)方面。在下面两节,我们将讨论在信息检索系统中的哪些领域需要改进以便更好的工作在Web上。

3.1信息检索信息检索系统诞生在几年前,并发展迅速。然而大多数信息检索系统研究的对象是小规模的单一的有组织结构的集合,例如科学论文集,或相关主题的新闻故事。实际上,信息检索的主要基准,the Text Retrieval Conference(),用小规模的、有组织结构的集合作为它们的基准。大型文集基准只有20GB,相比之下,我们抓到的24000000个网页占147GB。在TREC上工作良好的系统,在Web上却不一定产生好的结果。例如,标准向量空间模型企图返回和查询请求最相近的文档,把查询请求和文档都看作由出现在它们中的词汇组成的向量。在Web环境下,这种策略常常返回非常短的文档,这些文档往往是查询词再加几个字。例如,查询“Bill Clinton”,返回的网页只包含“Bill Clinton Sucks”,这是我们从一个主要搜索引擎中看到的。网络上有些争议,用户应该更准确地表达他们想查询什么,在他们的查询请求中用更多的词。我们强烈反对这种观点。如果用户提出象“Bill Clinton”这样的查询请求,应该得到理想的查询结果,因为这个主题有许多高质量的信息。象所给的例子,我们认为信息检索标准需要发展,以便有效地处理Web数据。

3.2有组织结构的集合(Well Controlled Collections)与Web的不同点 Web是完全无组织的异构的大量文档的集合。Web中的文档无论内在信息还是隐含信息都存在大量的异构性。例如,文档内部就用了不同的语言(既有人类语言又有程序),词汇(email地址,链接,邮政编码,电话号码,产品号),类型(文本,HTML,PDF,图像,声音),有些甚至是机器创建的文件(log文件,或数据库的输出)。可以从文档中推断出来,但并不包含在文档中的信息称为隐含信息。隐含信息包括来源的信誉,更新频率,质量,访问量和引用。不但隐含信息的可能来源各种各样,而且被检测的信息也大不相同,相差可达好几个数量级。例如,一个重要主页的使用量,象Yahoo 每天浏览数达到上百万次,于此相比无名的历史文章可能十年才被访问一次。很明显,搜索引擎对这两类信息的处理是不同的。 Web与有组织结构集合之间的另外一个明显区别是,事实上,向Web上传信息没有任何限制。灵活利用这点可以发布任何对搜索引擎影响重大的信息,使路由阻塞,加上为牟利故意操纵搜索引擎,这些已经成为一个严重的问题。这些问题还没有被传统的封闭的信息检索系统所提出来。它关心的是元数据的努力,这在Web搜索引擎中却不适用,因为网页中的任何文本都不会向用户声称企图操纵搜索引擎。甚至有些公司为牟利专门操纵搜索引擎。

4 系统分析(System Anatomy)
首先,我们提供高水平的有关体系结构的讨论。然后,详细描述重要的数据结构。最后,主要应用:抓网页,索引,搜索将被严格地检查。

4.1Google体系结构概述
这一节,我们将看看整个系统是如何工作的(give a high level),见图1。本节不讨论应用和数据结构,在后几节中讨论。为了效率大部分Google是用c或c++实现的,既可以在Solaris也可以在Linux上运行。 Google系统中,抓网页(下载网页)是由几个分布式crawlers完成的。一个URL服务器负责向crawlers提供URL列表。抓来的网页交给存储服务器storeserver。然后,由存储服务器压缩网页并把它们存到知识库repository中。每个网页都有一个ID,称作docID,当新URL从网页中分析出时,就被分配一个docID。由索引器和排序器负责建立索引index function。索引器从知识库中读取文档,对其解压缩和分析。每个文档被转换成一组词的出现情况,称作命中hits。Hits纪录了词,词在文档中的位置,最接近的字号,大小写。索引器把这些hits分配到一组桶barrel中,产生经过部分排序后的索引。索引器的另一个重要功能是分析网页中所有的链接,将有关的重要信息存在链接描述anchors文件中。该文件包含了足够的信息,可以用来判断每个链接链出链入节点的信息,和链接文本。 URL分解器resolver阅读链接描述anchors文件,并把相对URL转换成绝对URL,再转换成docID。为链接描述文本编制索引,并与它所指向的docID关联起来。同时建立由docID对组成的链接数据库。用于计算所有文档的PageRank值。用docID分类后的barrels,送给排序器sorter,再根据wordID进行分类,建立反向索引inverted index。这个操作要恰到好处,以便几乎不需要暂存空间。排序器还给出docID和偏移量列表,建立反向索引。一个叫DumpLexicon的程序把这个列表和由索引器产生的字典结合在一起,建立一个新的字典,供搜索器使用。这个搜索器就是利用一个Web服务器,使用由DumpLexicon所生成的字典,利用上述反向索引以及页面等级PageRank来回答用户的提问。

4.2主要数据结构经过优化的Google数据结构,能够用较小的代价抓取大量文档,建立索引和查询。
虽然近几年CPU和输入输出速率迅速提高。磁盘寻道仍然需要10ms。任何时候Google系统的设计都尽可能地避免磁盘寻道。这对数据结构的设计影响很大。

4.2.1
大文件大文件BigFiles是指虚拟文件生成的多文件系统,用长度是64位的整型数据寻址。多文件系统之间的空间分配是自动完成的。BigFiles包也处理已分配和未分配文件描述符。由于操纵系统不能满足我们的需要,BigFiles也支持基本的压缩选项。

4.2.2知识库 知识库包含每个网页的全部HTML。每个网页用zlib(见RFC1950)压缩。压缩技术的选择既要考虑速度又要考虑压缩率。我们选择zlib的速度而不是压缩率很高的bzip。知识库用bzip的压缩率接近4:1。而用zlib的压缩率是3:1。文档一个挨着一个的存储在知识库中,前缀是docID,长度,URL,见图2。访问知识库不需要其它的数据结构。这有助于数据一致性和升级。用其它数据结构重构系统,我们只需要修改知识库和crawler错误列表文件。

4.2.3文件索引
文件索引保存了有关文档的一些信息。索引以docID的顺序排列,定宽ISAM(Index sequential access mode)。每条记录包括当前文件状态,一个指向知识库的指针,文件校验和,各种统计表。如果一个文档已经被抓到,指针指向docinfo文件,该文件的宽度可变,包含了URL和标题。否则指针指向包含这个URL的URL列表。这种设计考虑到简洁的数据结构,以及在查询中只需要一个磁盘寻道时间就能够访问一条记录。还有一个文件用于把URL转换成docID。它是URL校验和与相应docID的列表,按校验和排序。要想知道某个URL的docID,需要计算URL的校验和,然后在校验和文件中执行二进制查找,找到它的docID。通过对这个文件进行合并,可以把一批URL转换成对应的docID。URL分析器用这项技术把URL转换成docID。这种成批更新的模式是至关重要的,否则每个链接都需要一次查询,假如用一块磁盘,322‘000'000个链接的数据集合将花费一个多月的时间。

4.2.4词典
词典有几种不同的形式。和以前系统的重要不同是,词典对内存的要求可以在合理的价格内。现在实现的系统,一台256M内存的机器就可以把词典装入到内存中。现在的词典包含14000000词汇(虽然一些很少用的词汇没有加入到词典中)。它执行分两部分—词汇表(用null分隔的连续串)和指针的哈希表。不同的函数,词汇表有一些辅助信息,这超出了本文论述的范围。

4.2.5 hit list
hit list是一篇文档中所出现的词的列表,包括位置,字号,大小写。Hit list占很大空间,用在正向和反向索引中。因此,它的表示形式越有效越好。我们考虑了几种方案来编码位置,字号,大小写—简单编码(3个整型数),紧凑编码(支持优化分配比特位),哈夫曼编码。Hit的详细信息见图3。我们的紧凑编码每个hit用2字节。有两种类型hit,特殊hit和普通hit。特殊hit包含URL,标题,链接描述文字,meta tag。普通hit包含其它每件事。它包括大小写特征位,字号,12比特用于描述词在文档中的位置(所有超过4095的位置标记为4096)。字号采用相对于文档的其它部分的相对大小表示,占3比特(实际只用7个值,因为111标志是特殊hit)。特殊hit由大小写特征位,字号位为7表示它是特殊hit,用4比特表示特殊hit的类型,8比特表示位置。对于anchor hit八比特位置位分出4比特用来表示在anchor中的位置,4比特用于表明anchor出现的哈希表hash of the docID。短语查询是有限的,对某些词没有足够多的anchor。我们希望更新anchor hit的存储方式,以便解决地址位和docIDhash域位数不足的问题。
因为搜索时,你不会因为文档的字号比别的文档大而特殊对待它,所以采用相对字号。 hit表的长度存储在hit前。为节省空间hit表长度,在正向索引中和wordID结合在一起,在反向索引中和docID结合存储。这就限制它相应地只占8到5比特(用些技巧,可以从wordID中借8bit)如果大于这些比特所能表示的长度,用溢出码填充,其后两字节是真正的长度。

4.2.6正向索引实际上,正向索引已经部分排序。它被存在一定数量的barrel中(我们用64个barrels)。每个barrel装着一定范围的wordID。如果一篇文档中的词落到某个barrel,它的docID将被记录到这个barrel中,紧跟着那些词(文档中所有的词汇,还是落入该barrel中的词汇)对应的hitlist。这种模式需要稍多些的存储空间,因为一个docID被用多次,但是它节省了桶数和时间,最后排序器进行索引时降低编码的复杂度。更进一步的措施是,我们不是存储docID本身,而是存储相对于该桶最小的docID的差。用这种方法,未排序的barrel的docID只需24位,省下8位记录hitlist长。

4.2.7反向索引除了反向索引由sorter加工处理之外,它和正向索引包含相同的桶。对每个有效的docID,字典包含一个指向该词所在桶的指针。它指向由docID和它的相应hitlist组成的doclish,这个doclist代表了所有包含该词的文档。 doclist中docID的顺序是一个重要的问题。最简单的解决办法是用doclish排序。这种方法合并多个词时很快。另一个可选方案是用文档中该词出现的次数排序。这种方法回答单词查询,所用时间微不足道。当多词查询时几乎是从头开始。并且当用其它Rank算法改进索引时,非常困难。我们综合了这两种方法,建立两组反向索引barrel,一组barrels的hitlist只包含标题和anchor hit,另一组barrel包含全部的hitlist。我们首先查第一组索引桶,看有没有匹配的项,然后查较大的那组桶。

4.3抓网页
运行网络爬行机器人是一项具有挑战性的任务。执行的性能和可靠性甚至更重要,还有一些社会焦点。网络爬行是一项非常薄弱的应用,它需要成百上千的web服务器和各种域名服务器的参与,这些服务器不是我们系统所能控制的。为了覆盖几十亿的网页,Google拥有快速的分布式网络爬行系统。一个URL服务器给若干个网络爬行机器人(我们采用3个)提供URL列表。URL服务器和网络爬行机器人都是用Python实现的。每个网络爬行机器人可以同时打开300个链接。抓取网页必须足够快。最快时,用4个网络爬行机器人每秒可以爬行100个网页。速率达每秒600K。执行的重点是找DNS。每个网络爬行机器人有它自己的DNS cache,所以它不必每个网页都查DNS。每一百个连接都有几种不同的状态:查DNS,连接主机,发送请求,接收回答。这些因素使网络爬行机器人成为系统比较复杂的部分。它用异步IO处理事件,若干请求队列从一个网站到另一个网站不停的抓取网页。运行一个链接到500多万台服务器的网页爬行机器人,产生1千多万登陆口,导致了大量的Email和电话。因为网民众多,总有些人不知道网络爬行机器人是何物,这是他们看到的第一个网络爬行机器人。几乎每天我们都会收到这样的Email“哦,你从我们的网站看了太多的网页,你想干什么?”还有一些人不知道网络搜索机器人避免协议(the robots exclusion protocol),以为他们的网页上写着“版权所有,勿被索引”的字样就会被保护不被索引,不必说,这样的话很难被web crawler理解。因为数据量如此之大,还会遇到一些意想不到的事情。例如,我们的系统曾经企图抓一个在线游戏,结果抓到了游戏中的大量垃圾信息。解决这个问题很简单。但是我们下载了几千万网页后才发现了这个问题。因为网页和服务器的种类繁多,实际上不在大部分Internet上运行它就测试一个网页爬行机器人是不可能。总是有几百个隐含的问题发生在整个web的一个网页上,导致网络爬行机器人崩溃,或者更糟,导致不可预测的不正确的行为。能够访问大部分Internet的系统必须精力充沛并精心测试过。由于象crawler这样大型复杂的系统总是产生这样那样的问题,因此花费一些资源读这些Email,当问题发生时解决它,是有必要的。

4.4Web索引分析
任何运行在整个Web上的分析器必须能够处理可能包含错误的大型集合。范围从HTML标记到标记之间几K字节的0,非ASCII字符,几百层HTML标记的嵌套,各种各样令人难以想象的错误。为了获得最大的速度,我们没有采用YACC产生上下文无关文法CFG分析器,而是采用灵活的方式产生词汇分析器,它自己配有堆栈。分析器的改进大大提高了运行速度,它的精力如此充沛完成了大量工作。把文档装入barrel建立索引—分析完一篇文档,之后把该文档装入barrel中,用内存中的hash表—字典,每个词汇被转换成一个wordID。当hash表字典中加入新的项时,笨拙地存入文件。一旦词汇被转换成wordID,它们在当前文档的出现就转换成hitlist,被写进正向barrel。索引阶段并行的主要困难是字典需要共享。
我们采用的方法是,基本字典中有140万个固定词汇,不在基本字典中的词汇写入日志,而不是共享字典。这种方法多个索引器可以并行工作,最后一个索引器只需处理一个较小的额外词汇日志。排序—为了建立反向索引,排序器读取每个正向barrel,以wordID排序,建立只有标题anchor hi t的反向索引barrel和全文反向索引barrel。这个过程一次只处理一个barrel,所以只需要少量暂存空间。排序阶段也是并行的,我们简单地同时运行尽可能多的排序器,不同的排序器处理不同的桶。由于barrel不适合装入主存,排序器进一步依据wordID和docID把它分成若干篮子,以便适合装入主存。然后排序器把每个篮子装入主存进行排序,并把它的内容写回到短反向barrel和全文反向barrel。

4.5搜索搜索的目标是提供有效的高质量的搜索结果。多数大型商业搜索引擎好像在效率方面花费了很大力气。因此我们的研究以搜索质量为重点,相信我们的解决方案也可以用到那些商业系统中。
Google查询评价过程见图4。
1. 分析查询。
2. 把词汇转换成wordID。
3. 在短barrel中查找每个词汇doclist的开头。
4. 扫描doclist直到找到一篇匹配所有关键词的文档
5. 计算该文档的rank
6. 如果我们在短barrel,并且在所有doclist的末尾,开始从全文barrel的doclist的开头查找每个词,goto 第四步
7. 如果不在任何doclist的结尾,返回第四步。
8. 根据rank排序匹配文档,返回前k个。图4 Google查询评价在有限的响应时间内,一旦找到一定数量的匹配文档,搜索引擎自动执行步骤8。这意味着,返回的结果是子优化的。我们现在研究其它方法来解决这个问题。过去根据PageRank排序hit,看来能够改进这种状况。

4.5.1 Ranking系统 Google比典型搜索引擎保存了更多的web信息。每个hitlish包括位置,字号,大小写。另外,我们还考虑了链接描述文字。Rank综合所有这些信息是困难的。ranking函数设计依据是没有某个因素对rank影响重大。首先,考虑最简单的情况—单个词查询。为了单个词查询中一个文档的rank,Goole在文档的hitlist中查找该词。Google认为每个hit是几种不同类型(标题,链接描述文字anchor,URL,普通大字号文本,普通小字号文本,……)之一,每种有它自己的类型权重。类型权重建立了一个类型索引向量。Google计算hitlist中每种hit的数量。然后每个hit数转换成count-weight。Count-weight开始随hit数线性增加,很快逐渐停止,以至于hit数与此不相关。我们计算count-weight向量和type-weight向量的标量积作为文档的IR值。最后IR值结合PageRank作为文档的最后rank 对于多词查询,更复杂些。现在,多词hitlist必须同时扫描,以便关键词出现在同一文档中的权重比分别出现时高。相邻词的hit一起匹配。对每个匹配hit 的集合计算相邻度。相邻度基于hit在文档中的距离,分成10个不同的bin值,范围从短语匹配到根本不相关。不仅计算每类hit数,而且要计算每种类型的相邻度,每个类型相似度对,有一个类型相邻度权type-prox-weight。Count转换成count-weight,计算count-weight type-proc-weight的标量积作为IR值。应用某种debug mode所有这些数和矩阵与查询结果一起显示出来。这些显示有助于改进rank系统。

4.5.2反馈
rank函数有很多参数象type-weight和type-prox-weight。指明这些参数的正确值有点黑色艺术black art。为此,我们的搜索引擎有一个用户反馈机制。值得信任的用户可以随意地评价返回的结果。保存反馈。然后,当修改rank函数时,对比以前搜索的rank,我们可以看到修改带来的的影响。虽然不是十全十美,但是它给出了一些思路,当rank函数改变时对搜索结果的影响。
5执行和结果搜索结果的质量是搜索引擎最重要的度量标准。完全用户评价体系超出了本文的论述范围,对于大多数搜索,我们的经验说明Google的搜索结果比那些主要的商业搜索引擎好。作为一个应用PageRank,链接描述文字,相邻度的例子,图4给出了Google搜索bill Clinton的结果。它说明了Google的一些特点。服务器对结果进行聚类。这对过滤结果集合相当有帮助。这个查询,相当一部分结果来自whitehouse.gov域,这正是我们所需要的。现在大多数商业搜索引擎不会返回任何来自whitehouse.gov的结果,这是相当不对的。注意第一个搜索结果没有标题。因为它不是被抓到的。Google是根据链接描述文字决定它是一个好的查询结果。同样地,第五个结果是一个Email地址,当然是不可能抓到的。也是链接描述文字的结果。所有这些结果质量都很高,最后检查没有死链接。因为它们中的大部分PageRank值较高。PageRank百分比用红色线条表示。没有结果只含Bill没有Clinton或只含Clinton没有Bill。因为词出现的相近性非常重要。当然搜索引擎质量的真实测试包含广泛的用户学习或结果分析,此处篇幅有限,请读者自己去体验Google,http://google.stanford.edu/

5.1
存储需求除了搜索质量,Google的设计可以随着Web规模的增大而有效地增大成本。一方面有效地利用存储空间。表1列出了一些统计数字的明细表和Google存储的需求。由于压缩技术的应用知识库只需53GB的存储空间。是所有要存储数据的三分之一。按当今磁盘价格,知识库相对于有用的数据来说比较便宜。搜索引擎需要的所有数据的存储空间大约55GB。大多数查询请求只需要短反向索引。文件索引应用先进的编码和压缩技术,一个高质量的搜索引擎可以运行在7GB的新PC。

5.2系统执行搜索引擎抓网页和建立索引的效率非常重要。Google的主要操作是抓网页,索引,排序。很难测试抓全部网页需要多少时间,因为磁盘满了,域名服务器崩溃,或者其它问题导致系统停止。总的来说,大约需要9天时间下载26000000网页(包括错误)。然而,一旦系统运行顺利,速度非常快,下载最后11000000网页只需要63小时,平均每天4000000网页,每秒48.5个网页。索引器和网络爬行机器人同步运行。索引器比网络爬行机器人快。因为我们花费了大量时间优化索引器,使它不是瓶颈。这些优化包括批量更新文档索引,本地磁盘数据结构的安排。索引器每秒处理54个网页。排序器完全并行,用4台机器,排序的整个过程大概需要24小时。

5.3搜索执行改进搜索执行不是我们研究的重点。
当前版本的Google可以在1到10秒间回答查询请求。时间大部分花费在NFS磁盘IO上(由于磁盘普遍比机器慢)。进一步说,Google没有做任何优化,例如查询缓冲区,常用词汇子索引,和其它常用的优化技术。我们倾向于通过分布式,硬件,软件,和算法的改进来提高Google的速度。我们的目标是每秒能处理几百个请求。表2有几个现在版本Google响应查询时间的例子。它们说明IO缓冲区对再次搜索速度的影响。 6结论 Google设计成可伸缩的搜索引擎。主要目标是在快速发展的World Wide Web上提供高质量的搜索结果。Google应用了一些技术改进搜索质量包括PageRank,链接描述文字,相邻信息。进一步说,Google是一个收集网页,建立索引,执行搜索请求的完整的体系结构。

6.1未来的工作大型Web搜索引擎是个复杂的系统,还有很多事情要做。
我们直接的目标是提高搜索效率,覆盖大约100000000个网页。一些简单的改进提高了效率包括请求缓冲区,巧妙地分配磁盘空间,子索引。另一个需要研究的领域是更新。我们必须有一个巧妙的算法来决定哪些旧网页需要重新抓取,哪些新网页需要被抓取。这个目标已经由实现了。受需求驱动,用代理cache创建搜索数据库是一个有前途的研究领域。我们计划加一些简单的已经被商业搜索引擎支持的特征,例如布尔算术符号,否定,填充。然而另外一些应用刚刚开始探索,例如相关反馈,聚类(Google现在支持简单的基于主机名的聚类)。我们还计划支持用户上下文(象用户地址),结果摘要。我们正在扩大链接结构和链接文本的应用。简单的实验证明,通过增加用户主页的权重或书签,PageRank可以个性化。对于链接文本,我们正在试验用链接周围的文本加入到链接文本。Web搜索引擎提供了丰富的研究课题。如此之多以至于我们不能在此一一列举,因此在不久的将来,我们希望所做的工作不止本节提到的。

6.2高质量搜索当今Web搜索引擎用户所面临的最大问题是搜索结果的质量。
结果常常是好笑的,并且超出用户的眼界,他们常常灰心丧气浪费了宝贵的时间。例如,一个最流行的商业搜索引擎搜索“Bill Clillton”的结果是the Bill Clinton Joke of the Day: April 14, 1997。Google的 设计目标是随着Web的快速发展提供高质量的搜索结果,容易找到信息。为此,Google大量应用超文本信息包括链接结构和链接文本。Google还用到了相邻性和字号信息。评价搜索引擎是困难的,我们主观地发现Google的搜索质量比当今商业搜索引擎高。通过PageRank分析链接结构使Google能够评价网页的质量。用链接文本描述链接所指向的网页有助于搜索引擎返回相关的结果(某种程度上提高了质量)。最后,利用相邻性信息大大提高了很多搜索的相关性。

6.3可升级的体系结构除了搜索质量,Google设计成可升级的。
空间和时间必须高效,处理整个Web时固定的几个因素非常重要。实现Google系统,CPU、访存、内存容量、磁盘寻道时间、磁盘吞吐量、磁盘容量、网络IO都是瓶颈。在一些操作中,已经改进的Google克服了一些瓶颈。Google的主要数据结构能够有效利用存储空间。进一步,网页爬行,索引,排序已经足够建立大部分web索引,共24000000个网页,用时不到一星期。我们希望能在一个月内建立100000000网页的索引。

6.4研究工具
Google不仅是高质量的搜索引擎,它还是研究工具。Google搜集的数据已经用在许多其它论文中,提交给学术会议和许多其它方式。最近的研究,例如,提出了Web查询的局限性,不需要网络就可以回答。这说明Google不仅是重要的研究工具,而且必不可少,应用广泛。我们希望Google是全世界研究者的资源,带动搜索引擎技术的更新换代。 7致谢 Scott Hassan and Alan Steremberg评价了Google的改进。他们的才智无可替代,作者由衷地感谢他们。感谢Hector Garcia-Molina, Rajeev Motwani, Jeff Ullman, and Terry Winograd和全部WebBase开发组的支持和富有深刻见解的讨论。最后感谢IBM,Intel,Sun和投资者的慷慨支持,为我们提供设备。这里所描述的研究是Stanford综合数字图书馆计划的一部分,由国家科学自然基金支持,合作协议号IRI-9411306。DARPA ,NASA,Interva研究,Stanford数字图书馆计划的工业合作伙伴也为这项合作协议提供了资金。参考文献 ?
Google的设计目标是可升级到10亿网页。我们的磁盘和机器大概能处理这么多网页。系统各个部分耗费的总时间是并行的和线性的。包括网页爬行机器人,索引器和排序器。扩展后我们认为大多数数据结构运行良好。然而10亿网页接近所有常用操作系统的极限(我们目前运行在Solaris和Linux上)。包括主存地址,开放文件描述符的数量,网络socket和带宽,以及其它因素。我们认为当网页数量大大超过10亿网页时,会大大增加系统复杂性。 9.2集中式索引体系的可升级性随着计算机性能的提高,海量文本索引的成本比较公平。当然带宽需求高的其它应用如视频,越来越普遍。但是,与多媒体例如视频相比,文本产品的成本低,因此文本仍然普遍。

图2 Google系统的工作流程图
(注:原图来自Sergey Brin and Lawrence Page, The Anatomy of a Large-Scale Hypertextual. Web Search Engine, 1998.http://www-db.stanford.edu/%7Ebackrub/Google.html)

①Google使用高速的分布式爬行器(Crawler)系统中的漫游遍历器(Googlebot)定时地遍历网页,将遍历到的网页送到存储服务器(Store Server)中。
②存储服务器使用zlib格式压缩软件将这些网页进行无损压缩处理后存入数据库Repository中。Repository获得了每个网页的完全Html代码后,对其压缩后的网页及URL进行分析,记录下网页长度、URL、URL长度和网页内容,并赋予每个网页一个文档号(docID),以便当系统出现故障的时候,可以及时完整地进行网页的数据恢复。
③索引器(Indexer)从Repository中读取数据,以后做以下四步工作:
④(a)将读取的数据解压缩后进行分析,它将网页中每个有意义的词进行统计后,转化为关键词(wordID)的若干索引项(Hits),生成索引项列表,该列表包括关键词、关键词的位置、关键词的大小和大小写状态等。索引项列表被存入到数据桶(Barrels)中,并生成以文档号(docID)部分排序的顺排档索引。
索引项根据其重要程度分为两种:当索引项中的关键词出现在URL、标题、锚文本(Anchor Text)和标签中时,表示该索引项比较重要,称为特殊索引项(Fancy Hits);其余情况则称为普通索引项(Plain Hits)。在系统中每个Hit用两个字节(byte)存储结构表示:特殊索引项用1位(bit)表示大小写,用二进制代码111(占3位)表示是特殊索引项,其余12位有4位表示特殊索引项的类型(即hit是出现在URL、标题、链接结点还是标签中),剩下8位表示hit在网页中的具体位置;普通索引项是用1位表示大小写,3位表示字体大小,其余12位表示在网页中的具体位置。


顺排档索引和Hit的存储结构如图3所示。

图3 顺排档索引和Hit的存储结构

值得注意的是,当特殊索引项来自Anchor Text时,特殊索引项用来表示位置的信息(8位)将分为两部分:4位表示Anchor Text出现的具体位置,另4位则用来与表示Anchor Text所链接网页的docID相连接,这个docID是由URL Resolver经过转化存入顺排档索引的。
(b)索引器除了对网页中有意义的词进行分析外,还分析网页的所有超文本链接,将其Anchor Text、URL指向等关键信息存入到Anchor文档库中。
(c)索引器生成一个索引词表(Lexicon),它包括两个部分:关键词的列表和指针列表,用于倒排档文档相连接(如图3所示)。
(d)索引器还将分析过的网页编排成一个与Repository相连接的文档索引(Document Index),并记录下网页的URL和标题,以便可以准确查找出在Repository中存储的原网页内容。而且把没有分析的网页传给URL Server,以便在下一次工作流程中进行索引分析。
⑤URL分析器(URL Resolver)读取Anchor文档中的信息,然后做⑥中的工作。
⑥(a)将其锚文本(Anchor Text)所指向的URL转换成网页的docID;(b)将该docID与原网页的docID形成“链接对”,存入Link数据库中;(c)将Anchor Text指向的网页的docID与顺排档特殊索引项Anchor Hits相连接。
⑦数据库Link记录了网页的链接关系,用来计算网页的PageRank值。
⑧文档索引(Document Index)把没有进行索引分析的网页传递给URL Server,URL Server则向Crawler提供待遍历的URL,这样,这些未被索引的网页在下一次工作流程中将被索引分析。
⑨排序器(Sorter)对数据桶(Barrels)的顺排档索引重新进行排序,生成以关键词(wordID)为索引的倒排档索引。倒排档索引结构如图4所示:

图4 倒排档索引结构
⑩将生成的倒排档索引与先前由索引器产生的索引词表(Lexicon)相连接产生一个新的索引词表供搜索器(Searcher)使用。搜索器的功能是由网页服务器实现的,根据新产生的索引词表结合上述的文档索引(Document Index)和Link数据库计算的网页PageRank值来匹配检索。


在执行检索时,Google通常遵循以下步骤(以下所指的是单个检索词的情况):
(1)将检索词转化成相应的wordID;
(2)利用Lexicon,检索出包含该wordID的网页的docID;
(3)根据与Lexicon相连的倒排档索引,分析各网页中的相关索引项的情况,计算各网页和检索词的匹配程度,必要时调用顺排档索引;
(4)根据各网页的匹配程度,结合根据Link产生的相应网页的PageRank情况,对检索结果进行排序;
(5)调用Document Index中的docID及其相应的URL,将排序结果生成检索结果的最终列表,提供给检索用户。
用户检索包含多个检索词的情况与以上单个检索词的情况类似:先做单个检索词的检索,然后根据检索式中检索符号的要求进行必要的布尔操作或其他操作。

谢谢 爬虫工作室提供的资料!

你可能感兴趣的:(Lucene)