大型超文本网络搜索引擎的剖析.docx
《大型超文本网络搜索引擎的剖析.docx》由会员分享，可在线阅读，更多相关《大型超文本网络搜索引擎的剖析.docx（17页珍藏版）》请在冰豆网上搜索。
大型超文本网络搜索引擎的剖析
大型超文本网络搜索引擎的剖析
SergeyBrin和LawrencePage
ComputerScienceDepartment
StanfordUnversity,Stanford,CA94305,USA
sergey@cs.stanford.edu和page@cs.stanford.edu
摘要：
本文介绍了一个在超文本中广泛应用的大型搜索引擎Google的原型。
Google的设计使之能够高效地抓取网络信息并为之建立索引，它的查询结果比现存的其它系统都要更令人满意。
这个原型的全文和至少含有2千4百万个页面的超链接数据库可以从http:
//google.stanford.edu/下载。
设计一个搜索引擎是一项富有挑战性的工作。
搜索引擎要为上百亿包含等量的不同词汇的网页建立索引。
它们每天要接受上亿次的查询。
尽管大型的搜索引擎在网络上是非常重要的，但是在学术上却没有多少对它的研究。
另外，由于技术的突飞猛进和网页量的剧增，在今天要搭建一个网络搜索引擎比起三年前是大有不同的。
本文对我们的大型网络搜索引擎提供了一份深层次的介绍──据我们所知，这是公开发表的论文中第一篇描述得如此详尽的。
除了在把传统搜索技术应用到如此数量级的数据中遇到的问题以外，还有一些新的技术上的挑战，比如利用超文本中的附加信息来改善搜索结果。
本文将着手解决这个问题，如何搭建一个实用的大型系统来发掘超文本中的附加信息。
我们还将要关注如何有效地处理无组织的任何人都能随意发布任何信息的超文本数据集。
关键词
万维网，搜索引擎，信息检索，PageRank算法，Google
1绪论
（注意：
这篇论文有两个版本──一个长一些的全文版本，一个精简一些的打印版本（http:
//infolab.stanford.edu/~backrub/google.html）。
全文版本可以在网上下载，也可以在研讨会的CD-ROM上找到。
）
万维网给信息检索带来了新的挑战。
万维网上的信息量在飞速增长，同时网络研究艺术中一些缺乏经验的新用户的数量也在激增。
人们一般利用网络上的超链接来网上冲浪，一般都是从高质量人工维护的索引开始，比如Yahoo！
或者搜索引擎。
人工维护的目录虽然有效地包含了流行的话题，但是它具有主观性、搭建和维护的代价高、升级缓慢，并且无法涵盖所有严肃深奥的主题。
基于关键词匹配的自动搜索引擎有经常返回一些低质量结果。
更糟的是，有些广告商专门设法误导自动搜索引擎来吸引人们的注意。
我们已经建立了一个大型搜索引擎能解决现存系统中的很多问题。
它专门利用了超文本中的附加信息来提高搜索结果的质量。
我们选择Google作为我们系统的名字，取自一个俗语googol的谐音，意思是10的100次方，这和我们建立一个大型搜索引擎的目标是相当吻合的。
1.1网络搜索引擎——升级：
1994—2000
搜索引擎技术不得不经常调整以跟上网络的增长。
1994年，第一批网络搜索引擎中的WorldWideWebWorm（WWWW）索引了110′000篇网页和有效的网络文件。
到了1997年11月，顶级搜索引擎声称索引了两百万（WebCrawler）至十亿篇网络文件（来自SearchEngineWatch）。
可以预见到2000年，一个全面的网络索引将会包含一百亿个文件。
与此同时，搜索引擎处理的查询量也在爆增。
1994年3月和4月，WorldWideWebWorm平均每天要接受1500次查询。
1997年11月，Altavista声称它每天要处理大约两亿次查询。
随着网络用户和查询搜索引擎的自动系统数量的增长，估计到2000年顶级的搜索引擎每天要处理上十亿次的查询。
我们的系统的目标就是要着手解决这些问题，无论是质量还是在将搜索引擎技术扩展到如此程度中引入的可扩展性的概念。
1.2Google：
与网络同步
要搭建一个哪怕是能和现今网络规模相适应的搜索引擎都会遇到很多挑战。
要想搜集网络文件并保持更新就需要快速的抓取技术。
还要有效地利用磁盘空间索引和部分文件本身。
索引系统必须能高效地处理上百G的数据。
还要迅速地处理每秒钟成百上千次的查询。
随着网络的不断增长，这项工作变得越来越困难了。
但是，硬件性能和费用问题的改善也部分地削减了困难度。
然而在这个进度中还有几个明显的例外，比如磁盘的寻道时间和操作系统的健壮性。
在Google的设计中，我们同时考虑到了网络的增长速度和技术的变更。
Google的设计使之能够很好地扩展到能处理极大量的数据。
它有效地利用了存储空间来储存索引文件。
优化的数据结构使之能够支持快速高效的数据访问（见4.2节）。
进一步地，我们希望建立索引和存储文本文件或HTML文档的代价会相对于它们实际的大小而不断减小。
对于象Google这样的集中式系统来说，这些措施换来的是可观的可扩展性。
1.3设计目标
1.3.1提高搜索质量
我们的首要目标是提高网络搜索引擎的质量。
在1994年，有些人认为通过全搜索索引是有可能很容易找到任何东西的。
根据BestofTheWeb1994–Navigators,“最好的导航服务可以在网络中找到几乎任何东西（只要输入所有的数据）。
”然而，1997的网络就大不一样了。
任何最近使用过搜索引擎的人都能轻易地证实索引地完整性并不是影响搜索结果质量的唯一因子。
用户们真正感兴趣的搜索结果经常被“垃圾结果”所湮没。
事实上，到1997年11月为止，在四个顶级的商业搜索引擎中只有一个能搜到自己（在搜索自己名字时前十位结果中返回自己的搜索页面）。
引发这个问题的一个主要原因就是索引中文件的数量已经增长了好几个数量级，相应地，用户能查阅的文档数却没有增加。
人们仍然只愿意看看前几十个结果。
因此，当集合的大小增加时，我们需要具有高精度（比如前几十个结果中的相关文档的数量）的工具。
当然，我们希望我们所说的“相关”只是指恰恰最好的文档，因为很可能还有几万个稍有点相关的文档。
即使与招回率（系统能够返回的相关文档的总数）的代价相比，高精度仍然是很重要的。
近来对利用更多的超文本信息来改进搜索和其它应用软件的方法还是相当乐观的[Marchiori97][Spertus97][Weiss96][Kleinberg98]。
特别是链接结构[Page98]和链接文本能够为相关性判断和质量过滤提供大量的信息。
Google同时利用了链接结构和链接文本（见2.1节和2.2节）。
1.3.2搜索引擎的学术研究
除了迅猛的发展，网络也随着时间增长变得越来越商业化了。
1993年的时候，只有1.5％的网络服务器是在.com域名下的。
到了1997年，这个数字增长到超过60％。
同时，搜索引擎也从学术领域移民到了商业领域中。
到目前为止，大多数搜索引擎的开发工作都是在公司中进行的，几乎不公开任何技术细节。
这就使得搜索技术很大程度上被关在暗箱中操作，并且面向广告了。
我们有强烈的愿望利用Google来推动学术领域中发展和理解。
另一个设计目标是建立一个给相当数量的人们实际使用的系统。
用户的使用对于我们来说十分重要，因为我们认为大多数有意义的研究都离不开现代网络中海量数据的支撑。
例如，每天都会有几千万的查询量。
然而因为这些数据被认为是具有商业价值的，所以我们很难得到这些数据。
我们最后的设计目标就是建立一个能够支持基于海量网络数据的新研究活动的体系结构。
为了提供给新研究的使用，Google以压缩形式存储了所有它抓取的实际文档。
我们设计Google的一个主要目标在于建立一个环境使得其它的研究人员能够快速进入这个领域、处理网络上海量数据、产生一般很难产生的有意义的成果。
系统建立后的不长的时间里，已经有不少论文用到了Google生成的数据库，还有很多正在进行当中。
我们的另外一个目标是建立一个空间站实验室似的环境，在这里研究人员甚至学生都能利用我们的海量网络数据进行设计和做一些有意义的实验。
2系统特性
Google搜索引擎有两个重要的特性，有助于产生高精度结果。
第一，它利用网络的链接结构计算每个网页的排名值。
这个排名值被称为PageRank，在[Page98]中有详细的介绍。
第二，Google利用链接来改进搜索结果。
2.1PageRank：
给网络带来秩序
网络的引用（链接）图是一件很重要的资源，却在很大程度上被现存的网络搜索引擎忽视了。
我们已经建立了一个包含了5亿1千8百万个这样的超链接的图，一个有重要意义的对整体的采样。
通过这些图可以迅速地计算一个网页的“PageRank”，一个对引用重要性的客观评价，很好地与人们对重要度的主观概念保持了一致性。
由于这种一致性，PageRank是一种对网络关键词搜索结果评级的绝好的方法。
对于大多数流行的主题，在对网页标题简单的文本匹配中PageRank对结果评级的表现棒极了（演示可以在google.stanford.edu上得到）。
在Google主系统的全文搜索中，PageRank也帮了不少忙。
2.1.1计算PageRank
在学术文献中的引用理论已经被应用到网络中了，大部分是通过对指向某页的引用或链接计数。
这的确对一个网页的重要性或质量给出了一些近似值。
PageRank扩展了这种思想，对指向网页的链接并非平等地计数，并且将网页上的链接数标准化。
PageRank的定义如下：
我们假设有网页T1…Tn指向（例如：
引用）网页A。
系数d是值在0到1之间的抑制因子。
我们通常将它设为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）可用简单的迭代算法来计算，对应于规格化后的网络链接矩阵的主特征向量。
并且，在一个中等规模的工作站上计算2千6百万网络页面的PageRank只需要几个小时。
还有很多细节问题，但是超出了本文的论述范围。
2.1.2直观理由
PageRank可以被认为是用户行为的模型。
我们假设假设有一个“随机冲浪者”，给他一个随机的网页，他不停地点击链接，从不点“后退”，但是最终会厌烦，然后从另外一个随机网页上再开始。
这个随机冲浪者访问某一网页的概率就是它的PageRank。
而抑制因子d就是随机冲浪者在每一个页面上因厌烦而请求另一随机页面的概率。
一个重要的变体是只将抑制因子d加在一个单一的页面上，或者一组页面上。
这样就带来了可定制性，并且使得故意误导系统而得到较高的排名的行为变得几乎不可能。
我们还有许多其它扩展的PageRank算法，见[Page98]。
另一个直观理由是如果一个网页有很多网页指向它，或者有一些PageRank值很高的页面指向它，这个网页的PageRank值就会很高。
直觉上来讲，一个被网络上到处引用的页面应该是值得一看的。
并且，有一些可能只有一个比如从Yahoo!
主页上来的引用的网页同样也是只得一看的。
如果一个网页质量不高，或者就是个死链，Yahoo!
主页是不太可能会链接它的。
PageRank通过在网络链接结构中递归地传播权重而同时处理了这两个因素和两者之间的所有情况。
2.2链接文本
我们的搜索引擎对链接文本进行了特殊处理。
大多数搜索引擎将一个链接上的文本和链接所在的页面关联起来。
更进一步地，我们把它和这个链接所指向的网页关联起来。
这样做有两点好处。
首先，链接文本往往能比网页本身提供更精确的描述。
其次，对于基于文本的搜索引擎不能索引的文档，比如图像、程序、数据库等，链接文字是有必要存在的。
这样就有可能返回一些并没有实际抓取过的页面。
注意，没有抓取过的页面会引起问题，因为在返回给用户之前它们并没有被检查过可用性。
在这种情况下，搜索引擎甚至会返回一个并不实际存在的页面，但是有一个超链接指向它。
但是，我们可以把结果分类，所以这个特殊问题很少发生。
这种将链接文字传递到它所指向的页面的思想在WorldWideWebWorm[McBryan94]中就实现了，就是由于它能有助于搜索非文本数据，而且能够在少量下载文档的情况的下增加搜索覆盖面。
我们使用链接传递的主要原因是链接文字能够提供高质量的结果。
有效地利用链接文字是有技术困难的，因为要处理的数据量十分巨大。
在我们目前抓取的2千4百万个页面中，我们索引了超过2亿5千9百万个链接文本。
2.3其它特性
除了PageRank和链接文本的使用，Google还有不少其它的特性。
首先，对于所有的点击都有位置信息，这样就能在搜索中充分应用邻近性。
其次，Google注意到了一些可视的表达细节，比如词语的字号。
大号或者黑体字的权重要高于其它的字。
再次，在仓库中能够获取原始完整的HTML页面。
3相关工作
网络中的搜索引擎有一个简短的历史。
WorldWideWebWorm（WWWW）[McBryan94]是最早的搜索引擎之一。
紧跟着又有许多其它的学术搜索引擎，它们有很多现在已经是上市的公司了。
相比网络的增长而言对于搜索引擎的重要性此前只有少量关于现在搜索引擎的文档[Pinkerton94]。
MichaelMauldin（LycosInc的首席科学家）[Mauldin]说，“各式各样的服务（包括Lycos）都紧密地关注这些数据库的细节”。
不过，在搜索引擎的一些特殊细节上也有一定量的工作。
尤其具有代表性的工作有，通过再处理现存的一些商业搜索引擎的结果再得到结果，或者创建小型“个人化的”搜索引擎。
最后，在信息检索系统方面的研究也不少，尤其是在精确控制集合方面。
在接下来的两节里，我们会讨论在一些需要扩展的的领域，以便更好地在网络上工作。
3.1信息检索
在信息检索系统领域的工作可以追述到几年前，并且发展迅速[Witten94]。
但是多数在信息检索系统上的研究都是基于小规模同构的精确控制集合的，比如科学论文或者关于某一主题的新闻故事的集合。
当然，信息检索的主要测评组织：
TextRetrievalConference[TREC96]使用了一个相当小的精确控制集合作为它们的基准。
相比“极大型公司”才20G的基准，我们爬行了2千4百万总共147G的网页。
在TREC上工作良好的东西，拿到网络中来往往就得不到好的结果。
比如，标准向量空间模型应该返回与查询词最相近的文档，它假设查询词和文档都是由它们的词频所定义的向量。
在网络上，这种策略往往返回在查询词后加几个词的很短的文档。
比如，我们在一个主要的搜索引擎上看到，查询“BillClinton”，返回了一个只包含“BillClintonSucks”的页面和查询“BillClinton”得到的图片。
有人争辩说，在网络上用户应该更精确地指定他们想要什么并在查询的时候多用些词。
我们强烈地反对这种立场，如果一个用户提出象“BillClinton”这样的查询，他应该得到理想的结果，因为在这个主题上存在大量高质量的信息。
因为有这样的事例，我们认为标准的信息检索工作需要发展以便高效地处理网络任务。
3.2网络与精确控制集合的区别
网络是一个完全无控制的异构文档的大型集合。
网络中的文档内部极具变化性，外部的元信息也是如此。
例如，文档内部的语言（无论是人类还是编程语言）、词汇（电子邮件地址、链接、邮编、电话号码、产品编号等）、格式的类型（文本、HTML、PDF、图像、声音等），甚至有些是机器产生的（日志文件或者数据库的输出）。
另一方面，我们将外部元信息定义为能够从一个文档中推出的信息，但是它本身并不包括在文档中。
外部元信息的例子如，资料来源的声誉、更新频率、质量、流行度或者访问量，还有引用。
不仅外部元信息资料可能的来源各式各样，被评价的东西本身也是极为多样的。
比如一个重要的主页比如Yahoo!
目前每天要接受上万次的页面浏览，与此相比一篇晦涩的历史文章可能十年才会被浏览一次。
很显然，搜索引擎对这两类信息的处理是大不相同的。
网络与精确控制集合间的另一个巨大的区别在于，在网络上实际上没有对什么人可以上传加任何限制。
这种发布任何信息的灵活性和搜索引擎对路由传输的巨大影响再加上一些公司为牟取利益而故意操纵搜索引擎一起，已经形成了严重的问题。
这些在传统搜索引擎中没有被提出来的问题已经接近信息检索系统了。
另外，有意思的是元数据效应对网络搜索引擎几乎是失败的，因为任何没有向用户直接陈述的页面文本都会被指责为是在操纵搜索引擎。
还存在有大量的公司专门琢磨操纵搜索引擎以牟取利益。
4系统剖析
首先，我们对体系结构做一个整体的讨论。
然后，会对深层次的重要的数据结构做一些描述。
最后，我们会逐个深刻解释主要的应用程序：
爬行器，索引器和搜索器。
4.1Google体系结构概述
在这一节里，我们会对图1中的整个系统是如何工作的做一个整体上的概述。
接下来的章节会讨论本节没有涉及的应用程序和数据结构。
Google的绝大部分为了保证效率的原因是用C或者C++程序实现的，可以在Solaris或者Linux下运行。
【图1：
Google的整体结构】
在Google中，网络爬行（网页的下载）是由很多分布的爬行器来做的。
由一个URL服务器来向爬行器发送URL列表。
被抓取下来的网页就被送到存储服务器上。
存储服务器再把网页压缩并存储在仓库里。
每一篇网页都有唯一一个与之相关联的ID号，称作docID，每当有一个新的URL被分析出来的时候都会被赋予一个docID。
索引函数由索引器和整理器在执行。
索引器会执行若干个函数。
它会读取仓库、解压文档并分析它们。
每一篇文档都被转化为词汇出现情况的集合，被称为hits。
hits记录了词汇、在文档中的位置、对字号的估计和大小写。
索引器将这些hits分发到一些“桶”的集合中，创建部分整理好的前向索引。
索引器还要执行另一个重要的函数。
它要分析出每一篇网页中的链接然后将关于它们的重要信息存储在一个链接文本文件中。
这个文件包含了足够的信息，可以判断每个链接分别是从哪里到哪里，还有链接上的文本。
URL分解器读取链接文件，并将其中相URL转化为绝对URL，然后转化成docID。
它将链接文本放入前向索引中，将链接所指向的docID与之关联起来。
它还要生成一个docID对偶的链接数据库。
链接数据库是用来给所有文档计算PageRank的。
整理器获得以docID整理过的（这是一种简化，见4.2.5节）桶，再根据docID进行整理，生成倒排索引。
为了使这个操作几乎不需要临时空间，这一步要在一个特定的地方执行。
整理器在倒排索引中产生wordID和偏移量的列表。
一个叫DumpingLexicon的程序将这个列表和由索引器生成的词典比较构造出搜索器所用的新词典。
搜索器由网络服务器运行，利用由DumpingLexicon构造的词典和倒排索引还有PageRank来回应查询。
4.2主要的数据结构
Google的数据结构是经过优化的，所以能在少量开销的条件下爬行、索引、搜索大规模的文档集。
虽然几年来CPU和块输入输出的速率都由显著的提高，但是一次磁盘寻道仍然需要10毫秒来完成。
Google的设计尽可能地避免了磁盘寻道开销，这就对数据结构的设计产生了相当大的影响。
4.2.1BigFiles
BigFiles是跨越多个文件系统的虚拟文件，可由64位整数寻址。
在多文件系统之间空间分配是自动处理的。
BigFiles包还可以处理文件描述符的空间分配和回收，因为操作系统提供的功能不够我们用的。
BigFiles还支持基本的压缩选项。
4.2.2仓库
仓库包含了所有的网页的HTML全文。
每一页都用zlib（见RFC1950）压缩。
对压缩技术的选择是在压缩速度和压缩率之间的权衡。
我们选择了zlib的速度而没有选择bzip对压缩率的重要改进。
和bzip大约4：
1的压缩率相比zlib的压缩比为3：
1。
在仓库中，文档一个接一个地存储，用docID、长度和URL做为前缀，如图2。
访问仓库不需要其它的数据结构了。
这样有助于保持数据的一致性并且能显著简化开发工作；我们可以通过仅仓库和一个爬行器错误文件来重建所有其它的数据结构。
【图2：
仓库数据结构】
4.2.3文档索引
文档索引保留了每个文档的信息。
它是一个定宽ISAM（Indexsequentialaccessmode）索引，以docID排序。
其中每一项中的存储的信息包括了当前文档状态、指向仓库的指针、文档的校验和还有各种统计数据。
如果一篇网页被抓取过，那它同时也会包括一个指针，指向一个变长的含有它的URL和标题的文件，这个文件被成为docinfo。
否则这个指针就指向一个只含有URL的URL列表。
这样的设计选择是因为我们希望有一个简洁的数据结构，并且能够在一次查询中只访问一次磁盘就得到一条记录。
另外还有一个文件用来将URL转换为docID。
文件中是URL的校验和与对应docID的列表，并且以校验和排序。
要找到某个特定的URL的docID，先计算出URL的校验和，再在校验和文件中做二分查找就能找到它的docID了。
通过于这个文件的合并可以将URL批量转换成docID。
这种技术被URL分解器用来将URL转换成docID。
而批量转换的改进是至关重要的，因为否则我们就必须对每一个链接进行一次磁盘寻道，这意味着如果只有一个磁盘，要处理我们的3亿2千2百万个链接的数据集会花掉一个月的时间。
4.2.4词典
词典有几种不同的形式。
与以前的系统相比一个重要的变化是词典可以被放在内存中而不会在内存上花费很多。
在现在的实现中我们可以将词典放在一台256M内存的机器上。
目前的词典含有1千4百万词汇（虽然有一些罕见的词汇没有被放进去）。
它的实现分两部分——一个词汇的列表（连接在一起但是用null分隔）和一个指针的散列表。
对不同的函数，词汇列表有一些辅助信息，完整的讨论已经超出了本文的范围。
4.2.5Hit列表
一个hit列表对应于一个特定的词汇在一个特定的文档中出现情况，包括了位置、字号、大小写等信息。
Hit列表在前向索引和倒排索引中占了大部分空间。
因此，使它们的表现形式尽量有效率很重要。
我们考虑了几种可选的方案来对位置、字号和大小写信息进行编码——简单编码（用三个整数），紧凑编码（用手工优化的比特分配），和哈夫曼编码。
最后我们选择了手工优化的紧凑编码，因为它占用的空间远小于简单编码，而对比特的操作也远少于哈夫曼编码。
Hit的细节见图3。
【图3：
前向索引、倒排索引和词典】
我们的紧凑编码每个hit使用两个字节。
有两种类型的hit：
特别hit与普通hit。
特别hit包括了出现在URL、标题、链接文本或者元标签中的hit。
普通hit指所有其它的hit。
普通hit包括了一个大小写位、字号、和12比特的词汇在文档中的位置（位置超过4095的都被标为4096）。
与文档其它部分的相对字号使用3个比特表示（实际上只使用了7个值，因为111表示特别hit）。
特别hit由一个大小写位、字号字段被置为7标志特别hit、4比特编码用来表示特别hit的类型、和8比特的位置组成。
对于链接hit，8比特的位置字段被分为4比特表示在链接中的位置，另外4比特用作对链接出现文档docID的散列。
只要对于一个特定词汇没有那么多的链接，我们就可以进行一些有限的短语查询。
为了能对位置字段和docID的散列字段有更好的解决办法，我们考虑改进链接hit的存储方式。
我们使用的相对于本文档其余部分的相对字号，因为在搜索的时候，你不会因为一篇文档的字号比另一篇大就特殊对它进行特殊排序。
hit列表的长度存储hit本身的前面。
为了节省空间，hit列表的长度和前向索引中的wordID、倒排索引中的docID结合在一起。
这就限制它各自只占8到5个比特（用点技巧可以从wordID中借8个比特）。
升级会员 