设计搜烦引擎是一富有挑战性的工作。搜索引擎ؓ上亿个网徏立烦引，其中包含大量q然不同的词汇。而且每天要回{成千上万个查询。在|络中，管大型搜烦引擎非常重要Q但是学术界却很研I它。此外由于技术的快速发展和|页的大量增加，现在建立一个搜索引擎和三年前完全不同?BR>
本文详细介绍了我们的大型搜烦引擎Q据我们所知，在公开发表的论文中Q这是第一描q地如此详细。除了把传统数据搜烦技术应用到如此大量U网中所遇到的问题，q有许多新的技术挑战，包括应用文本中的附加信息改q搜索结果。本文将解决q个问题Q描q如何运用超文本中的附加信息Q徏立一个大型实用系l。Q何h都可以在|上随意发布信息Q如何有效地处理q些无组l的文本集合，也是本文要关注的问题?BR>
关键?World Wide WebQ搜索引擎，信息索，PageRank, Google
1 l论 Web l信息检索带来了新的挑战?BR>
Web上的信息量快速增长，同时不断有毫无经验的新用h体验Webq门艺术。h们喜Ƣ用链接来网上冲，通常都以象Yahooq样重要的网|搜烦引擎开始。大家认为List(目录)有效地包含了大家感兴的主题Q但是它h主观性，建立和维护的代h高，升慢，不能包括所有深奥的主题。基于关键词的自动搜索引擎通常q回太多的低质量的匹配。问题更遭的是Q一些广告ؓ了赢得h们的xx设法误导自动搜烦引擎?BR>
我们建立了一个大型搜索引擎解决了现有pȝ中的很多问题。应用超文本l构Q大大提高了查询质量。我们的pȝ命名为googleQ取名自googol的通俗拼法Q即10?00ơ方Q这和我们的目标建立一个大型搜索引擎不谋而合?BR>
1.1|络搜烦引擎—升U换代（scaling upQ：1994-2000 搜烦引擎技术不得不快速升U（scale dramaticallyQ跟上成倍增长的web数量?994q_W一个Web搜烦引擎QWorld Wide Web Worm(WWWW)可以索到110Q?00个网和Web的文件。到1994q?1月，的搜索引擎声U可以检索到2?00?00QWebCrawlerQ至100?00?00个网l文Ӟ来自 Search Engine WatchQ。可以预见到2000q_可检索到的网将过1?00?00?00。同Ӟ搜烦引擎的访问量也会以惊人的速度增长。在1997q的三四月䆾QWorld Wide Web Worm q_每天收到1500个查询?BR>
?997q?1月，Altavista 声称它每天要处理大约20?00?00个查询。随着|络用户的增长，?000q_自动搜烦引擎每天处理上亿个查询。我们系l的设计目标要解册多问题，包括质量和可升性，引入升搜烦引擎技术（scaling search engine technologyQ，把它升到如此大量的数据上?BR>
1.2 GoogleQ跟上Web的步伐（Scaling with the WebQ徏立一个能够和当今web规模盔R应的搜索引擎会面许多挑战。抓|页技术必够快Q才能跟上网变化的速度Qkeep them up to dateQ。存储烦引和文档的空间必够大。烦引系l必能够有效地处理上千亿的数据。处理查询必dQ达到每U能处理成百上千个查询（hundreds to thousands per second.Q。随着Web的不断增长，q些d变得来艰巨。然而硬件的执行效率和成本也在快速增长，可以部分抉|q些困难?BR>q有几个值得注意的因素，如磁盘的寻道旉Qdisk seek timeQ，操作pȝ的效率（operating system robustnessQ。在设计Google的过E中Q我们既考虑了Web的增镉K度Q又考虑了技术的更新。Google的设计能够很好的升处理量数据集。它能够有效地利用存储空间来存储索引。优化的数据l构能够快速有效地存取Q参?.2节）。进一步，我们希望Q相对于所抓取的文本文件和HTML|页的数量而言Q存储和建立索引的代价尽可能的小Q参考附录BQ。对于象Googleq样的集中式pȝQ采取这些措施得C令h满意的系l可升性（scaling propertiesQ?BR>
1. 3设计目标
1.3.1提高搜烦质量我们的主要目标是提高Web搜烦引擎的质量?994q_有h认ؓ建立全搜索烦引（a complete search indexQ可以查找M数据都变得容易。根据Best of the Web 1994 -- Navigators Q“最好的D服务可以使在Web上搜索Q何信息都很容易（当时所有的数据都可以被dQ”。然?997q的WebpE然不同。近来搜索引擎的用户已经证实索引的完整性不是评h索质量的唯一标准。用h兴趣的搜索结果往往湮没在“垃圄果Junk result”中。实际上Q到1997q?1月ؓ止，四大商业搜烦引擎中只有一个能够找到它自己Q搜索自己名字时q回的前十个l果中有它自己）。导致这一问题的主要原因是文档的烦引数目增加了好几个数量Q但是用戯够看的文档数却没有增加。用户仍然只希望看前面几十个搜烦l果。因此，当集合增大时Q我们就需要工具ɾl果_Q在q回的前几十个结果中Q有x档的数量Q。由于是从成千上万个有点相关的文档中选出几十个，实际上，相关的概念就是指最好的文档。高_非常重要Q甚至以响应Q系l能够返回的有关文档的LQؓ代h。o人高兴的是利用超文本链接提供的信息有助于改进搜烦和其它应?。尤其是链接l构和链接文本，为相x的判断和高质量的过滤提供了大量的信息。Google既利用了链接l构又用Canchor文本Q见2.1?.2节）?BR>
1.3.2搜烦引擎的学术研I着旉的流逝，除了发展q速，Web来商业化?993q_只有1.5%的Web服务是来?com域名。到1997q_过?0%。同Ӟ搜烦引擎从学术领域走q商业。到现在大多数搜索引擎被公司所有，很少技公开术细节。这导致搜索引擎技术很大程度上仍然是暗操作，q們做广告（见附录AQ。Google的主要目标是推动学术领域在此斚w的发展，和对它的了解。另一个设计目标是l大家一个实用的pȝ。应用对我们来说非常重要Q因为现代网l系l中存在大量的有用数据（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 systemsQ。例如，每天有几千万个研I。然而，得到q些数据却非常困难，主要因ؓ它们没有商业价倹{我们最后的设计目标是徏立一个体pȝ构能够支持新的关于v量Web数据的研I。ؓ了支持新研究QGoogle以压~的形式保存了实际所抓到的文档。设计google的目标之一是要徏立一个环境其他研究者能够很快进入这个领域，处理量Web数据Q得到满意的l果Q而通过其它Ҏ却很隑־到结果。系l在短时间内被徏立v来，已经有几论文用CGoogle建的数据库，更多的在h中。我们的另一个目标是建立一个宇宙空间实验室似的环境Q在q里研究者甚臛_生都可以Ҏ们的量Web数据设计或做一些实验?BR>
2. pȝ特点 Google搜烦引擎有两个重要特点，有助于得到高_ֺ的搜索结果?BR>
W一点，应用Web的链接结构计每个网늚Rank|UCؓPageRankQ将?8详l描q它?BR>W二点，Google利用链接改q搜索结果?BR>
2.1 PageRank:l网|?Web的引用（链接Q图是重要的资源Q却被当今的搜烦引擎很大E度上忽视了。我们徏立了一个包?18?00?00个超链接的图Q它是一个具有重要意义的h。这些图能够快速地计算|页的PageRank|它是一个客观的标准Q较好的W合Z心目中对一个网重要程度的评hQ徏立的基础是通过引用判断重要性。因此在web中，PageRank能够优化关键词查询的l果。对于大多数的主题，在网|题查询中用PageRank优化单文本匹配，我们得到了o人惊叹的l果Q从http://google.stanford.edu 可以得到演示Q。对于Googleȝl中的全文搜索，PageRank也帮了不忙?BR>
2.1.1计算PageRank 文献索中的引用理论用到Web中，引用|页的链接数Q一定程度上反映了该|页的重要性和质量。PageRank发展了这U思想Q网间的链接是不^{的?BR>
PageRank定义如下: 我们假设T1…Tn指向|页AQ例如，被引用）。参数d是制动因子，使结果在0Q?之间。通常d{于0.85。在下一节将详细介绍d。CQAQ定义ؓ|页A指向其它|页的链接数Q网A的PageRank值由下式l出Q?PR(A) = (1-d) + d (PR(T1)/C(T1) + ... + PR(Tn)/C(Tn)) 注意PageRank的Ş式，分布到各个网中Q因此所有网늚PageRank和是1?PageRank或PRQAQ可以用单的q代法计算Q相应规格化Web链接矩阵的主特征向量。中{规模的|站计算26?00?00|页的PageRankDp几小时。还有一些技术细节超Z本文的范围?BR>
2.1.2直觉判断 PageRank被看作用戯为的模型。我们假讄上冲是随机的，不断点击链接Q从不返回，最l烦了，另外随机选一个网重新开始冲。随问一个网늚可能性就是它的PageRank倹{制动因子d是随问一个网늃了的可能性，随机另选一个网c对单个|页或一l网，一个重要的变量加入到制动因子d中。这允许个h可以故意地误导系l，以得到较高的PageRank倹{我们还有其它的PageRank法Q见98c?BR>
另外的直觉判断是一个网|很多|页指向它，或者一些PageRank值高的网|向它Q则q个|页很重要。直觉地Q在Web中，一个网被很多|页引用Q那么这个网值得一看。一个网被象Yahooq样重要的主引用即使一ơ，也值得一看。如果一个网늚质量不高Q或者是死链接，象Yahooq样的主不会链向它。PageRank处理了这两方面因素，q过|络链接递归C递?BR>
2.2链接描述文字QAnchor TextQ我们的搜烦引擎寚w接文本进行了Ҏ的处理。大多数搜烦引擎把链接文字和它所铑的网（the page that the link is onQ联pv来。另外，把它和链接所指向的网联pv来。这有几点好处?BR>
W一Q通常链接描述文字比网|w更_地描q该|页?BR>
W二Q链接描q文字可能链向的文档不能被文本搜索引擎检索到Q例如图像，E序和数据库。有可能使返回的|页不能被抓到。注意哪些抓不到的网将会带来一些问题。在q回l用户前不了它们的有效性。这U情冉|索引擎可能返回一个根本不存在的网，但是有超U链接指向它。然而这U结果可以被挑出来的Q所以此cȝ问题很少发生。链接描q文字是对被铑|页的宣传，q个思想被用在World Wide Web Worm 中，主要因ؓ它有助于搜烦非文本信息，能够用少量的已下载文档扩大搜索范围。我们大量应用链接描q文字，因ؓ它有助于提高搜烦l果的质量。有效地利用链接描述文字技术上存在一些困难，因ؓ必须处理大量的数据。现在我们能抓到24?00?00个网，已经索到259?00?00多个链接描述文字?BR>
2.3其它特点除了PageRank和应用链接描q文字外QGoogleq有一些其它特炏V?BR>
W一,所有hit都有位置信息Q所以它可以在搜索中q泛应用邻近性（proximityQ?BR>
W二QGoogle跟踪一些可视化外表l节Q例如字受黑体大号字比其它文字更重要?BR>
W三Q知识库存储了原始的全文html|页?3有关工作 Web索研I的历史短。World Wide Web WormQ）是最早的搜烦引擎之一。后来出C一些用于学术研I的搜烦引擎Q现在它们中的大多数被上市公司拥有。与Web的增长和搜烦引擎的重要性相比，有关当今搜烦引擎技术的优秀论文相当。根据Michael MauldinQLycos Inc的首席科学家Q? Q“各U各L服务Q包括LycosQ非常关注这些数据库的细节。”虽然在搜烦引擎的某些特点上做了大量工作。具有代表性的工作有，对现有商业搜索引擎的l果q行传递，或徏立小型的个性化的搜索引擎。最后有关信息检索系l的研究很多Q尤其在有组l机构集合（well controlled collectionsQ方面。在下面两节Q我们将讨论在信息检索系l中的哪些领域需要改q以便更好的工作在Web上?/FONT>
3.1信息索信息检索系l诞生在几年前，q发展迅速。然而大多数信息索系l研I的对象是小规模的单一的有l织l构的集合，例如U学论文集，或相关主题的新闻故事。实际上Q信息检索的主要基准Qthe Text Retrieval ConferenceQ）Q用规模的、有l织l构的集合作为它们的基准?BR>
大型文集基准只有20GBQ相比之下，我们抓到?4000000个网占147GB。在TREC上工作良好的pȝQ在Web上却不一定生好的结果。例如，标准向量I间模型企图q回和查询请求最相近的文档，把查询请求和文档都看作由出现在它们中的词汇组成的向量。在Web环境下，q种{略常常q回非常短的文档Q这些文档往往是查询词再加几个字。例如，查询“Bill Clinton”，q回的网只包含“Bill Clinton Sucks”，q是我们从一个主要搜索引擎中看到的。网l上有些争议Q用户应该更准确地表达他们想查询什么，在他们的查询h中用更多的词。我们强烈反对这U观炏V如果用h“Bill Clinton”这L查询hQ应该得到理想的查询l果Q因个主题有许多高质量的信息。象所l的例子Q我们认Z息检索标准需要发展，以便有效地处理Web数据?BR>
3.2有组l结构的集合QWell Controlled CollectionsQ与Web的不同点 Web是完全无l织的异构的大量文档的集合。Web中的文档无论内在信息q是隐含信息都存在大量的异构性。例如，文档内部q了不同的语言Q既有hc语a又有E序Q，词汇Qemail地址Q链接，邮政~码Q电话号码，产品PQ类型（文本QHTMLQPDFQ图像，声音Q，有些甚至是机器创建的文gQlog文gQ或数据库的输出Q。可以从文档中推断出来，但ƈ不包含在文档中的信息UCؓ隐含信息。隐含信息包括来源的信誉Q更新频率，质量Q访问量和引用。不但隐含信息的可能来源各种各样Q而且被检的信息也大不相同，相差可达好几个数量。例如，一个重要主늚使用量，象Yahoo 每天览数达C百万ơ，于此相比无名的历史文章可能十q才被访问一ơ。很明显Q搜索引擎对q两cM息的处理是不同的?Web与有l织l构集合之间的另外一个明昑别是Q事实上Q向Web上传信息没有M限制。灵zd用这点可以发布Q何对搜烦引擎影响重大的信息，使\由阻塞，加上为牟利故意操U|索引擎，q些已经成ؓ一个严重的问题。这些问题还没有被传l的闭的信息检索系l所提出来。它兛_的是元数据的努力Q这在Web搜烦引擎中却不适用Q因为网中的Q何文本都不会向用户声UC图操U|索引擎。甚x些公ؓ牟利专门操纵搜烦引擎?BR>
4 pȝ分析QSystem AnatomyQ首先，我们提供高水q的有关体系l构的讨论。然后，详细描述重要的数据结构?BR>
最后，主要应用Q抓|页Q烦引，搜烦被严格地检查?Figure 1. High Level Google Architecture 4.1Google体系l构概述q一节，我们看看整个系l是如何工作的（give a high levelQ，见图1。本节不讨论应用和数据结构，在后几节中讨论。ؓ了效率大部分Google是用c或c++实现的，既可以在Solaris也可以在Linux上运行?BR>
Googlepȝ中，抓网（下蝲|页Q是由几个分布式crawlers完成的。一个URL服务器负责向crawlers提供URL列表。抓来的|页交给存储服务器storeserver。然后，由存储服务器压羃|页q把它们存到知识库repository中。每个网都有一个IDQ称作docIDQ当新URL从网中分析出时Q就被分配一个docID。由索引器和排序器负责徏立烦引index function。烦引器从知识库中读取文档，对其解压~和分析。每个文档被转换成一l词的出现情况，UC命中hits。HitsU录了词Q词在文档中的位|，最接近的字P大小写。烦引器把这些hits分配Cl桶barrel中，产生l过部分排序后的索引。烦引器的另一个重要功能是分析|页中所有的链接Q将有关的重要信息存在链接描qanchors文g中。该文g包含了够的信息Q可以用来判断每个链接链出链入节点的信息Q和链接文本?URL分解器resolver阅读链接描述anchors文gQƈ把相对URL转换成绝对URLQ再转换成docID。ؓ链接描述文本~制索引Qƈ与它所指向的docID兌h。同时徏立由docID对组成的链接数据库。用于计所有文档的PageRank倹{用docID分类后的barrelsQ送给排序器sorterQ再ҎwordIDq行分类Q徏立反向烦引inverted index。这个操作要恰到好处Q以便几乎不需要暂存空间。排序器q给出docID和偏U量列表Q徏立反向烦引。一个叫DumpLexicon的程序把q个列表和由索引器生的字典l合在一P建立一个新的字典，供搜索器使用。这个搜索器是利用一个Web服务器，使用由DumpLexicon所生成的字典，利用上述反向索引以及面{PageRank来回{用L提问?
4.2主要数据l构l过优化的Google数据l构Q能够用较小的代h取大量文档，建立索引和查询。虽然近几年CPU和输入输出速率q速提高。磁盘寻道仍焉?0ms。Q何时候Googlepȝ的设计都可能地避免盘寻道。这Ҏ据结构的设计影响很大?BR>
4.2.1大文件大文gBigFiles是指虚拟文g生成的多文gpȝQ用长度?4位的整型数据d。多文gpȝ之间的空间分配是自动完成的。BigFiles包也处理已分配和未分配文件描q符。由于操U늳l不能满x们的需要，BigFiles也支持基本的压羃选项?BR>
4.2.2知识?Figure 2. Repository Data Structure 知识库包含每个网늚全部HTML。每个网는zlibQ见RFC1950Q压~。压~技术的选择既要考虑速度又要考虑压羃率。我们选择zlib的速度而不是压~率很高的bzip。知识库用bzip的压~率接近4Q?。而用zlib的压~率?Q?。文档一个挨着一个的存储在知识库中，前缀是docIDQ长度，URLQ见?。访问知识库不需要其它的数据l构。这有助于数据一致性和升。用其它数据l构重构pȝQ我们只需要修改知识库和crawler错误列表文g?BR>
4.2.3文g索引文g索引保存了有x档的一些信息。烦引以docID的顺序排列，定宽ISAMQIndex sequential access modeQ。每条记录包括当前文件状态，一个指向知识库的指针，文g校验和，各种l计表。如果一个文档已l被抓到Q指针指向docinfo文gQ该文g的宽度可变，包含了URL和标题。否则指针指向包含这个URL的URL列表。这U设计考虑到简z的数据l构Q以及在查询中只需要一个磁盘寻道时间就能够讉K一条记录。还有一个文件用于把URL转换成docID。它是URL校验和与相应docID的列表，按校验和排序。要想知道某个URL的docIDQ需要计URL的校验和Q然后在校验和文件中执行二进制查找，扑ֈ它的docID。通过对这个文件进行合qӞ可以把一批URL转换成对应的docID。URL分析器用q项技术把URL转换成docID。这U成Ҏ新的模式是至关重要的Q否则每个链接都需要一ơ查询，假如用一块磁盘，322?00?00个链接的数据集合花费一个多月的旉?BR>
4.2.4词典词典有几U不同的形式。和以前pȝ的重要不同是Q词典对内存的要求可以在合理的h格内。现在实现的pȝQ一?56M内存的机器就可以把词典装入到内存中。现在的词典包含14000000词汇Q虽然一些很用的词汇没有加入到词典中）。它执行分两部分—词汇表Q用null分隔的连l串Q和指针的哈希表。不同的函数Q词汇表有一些辅助信息，q超Z本文的范围?BR>
4.2.5 hit list hit list是一文档中所出现的词的列表，包括位置Q字P大小写。Hit list占很大空_用在正向和反向烦引中。因此，它的表示形式有效越好。我们考虑了几U方案来~码位置Q字P大小写—简单编码（3个整型数Q，紧凑~码Q支持优化分配比特位Q，哈夫曼编码。Hit的详l信息见?。我们的紧凑~码每个hit?字节。有两种cdhitQ特Dhit和普通hit。特Dhit包含URLQ标题，链接描述文字Qmeta tag。普通hit包含其它每g事。它包括大小写特征位Q字P12比特用于描述词在文档中的位置Q所有超q?095的位|标Cؓ4096Q。字号采用相对于文档的其它部分的相对大小表示Q占3比特(实际只用7个|因ؓ111标志是特Dhit)。特Dhit由大写特征位，字号位ؓ7表示它是ҎhitQ用4比特表示Ҏhit的类型，8比特表示位置。对于anchor hit八比特位|位分出4比特用来表示在anchor中的位置Q?比特用于表明anchor出现的哈希表hash of the docID。短语查询是有限的，Ҏ些词没有_多的anchor。我们希望更新anchor hit的存储方式，以便解决地址位和docIDhash域位C的问题?BR>因ؓ搜烦Ӟ你不会因为文档的字号比别的文档大而特D对待它Q所以采用相对字受?hit表的长度存储在hit前。ؓ节省I间hit表长度，在正向烦引中和wordIDl合在一P在反向烦引中和docIDl合存储。这限制它相应地只??比特Q用些技巧，可以从wordID中?bitQ如果大于这些比Ҏ能表C的长度Q用溢出码填充，其后两字节是真正的长度?Figure 3. Forward and Reverse Indexes and the Lexicon
4.2.6正向索引实际上，正向索引已经部分排序。它被存在一定数量的barrel中（我们?4个barrelsQ。每个barrel装着一定范围的wordID。如果一文档中的词落到某个barrelQ它的docID被记录到这个barrel中，紧跟着那些词（文档中所有的词汇Q还是落入该barrel中的词汇Q对应的hitlist。这U模式需要稍多些的存储空_因ؓ一个docID被用多次Q但是它节省了桶数和旉Q最后排序器q行索引旉低编码的复杂度。更q一步的措施是，我们不是存储docID本nQ而是存储相对于该桶最的docID的差。用q种ҎQ未排序的barrel的docID只需24位，省下8位记录hitlistѝ?BR>
4.2.7反向索引除了反向索引由sorter加工处理之外Q它和正向烦引包含相同的桶。对每个有效的docIDQ字典包含一个指向该词所在桶的指针。它指向由docID和它的相应hitlistl成的doclishQ这个doclist代表了所有包含该词的文档?doclist中docID的顺序是一个重要的问题。最单的解决办法是用doclish排序。这U方法合q多个词时很快。另一个可选方案是用文档中该词出现的次数排序。这U方法回{单词查询，所用时间微不道。当多词查询时几乎是从头开始。ƈ且当用其它Rank法改进索引Ӟ非常困难。我们综合了q两U方法，建立两组反向索引barrelQ一lbarrels的hitlist只包含标题和anchor hitQ另一lbarrel包含全部的hitlist。我们首先查W一l烦引桶Q看有没有匹配的，然后查较大的那组桶?BR>
4.3抓网运行网l爬行机器h是一具有挑战性的d。执行的性能和可靠性甚x重要Q还有一些社会焦炏V网l爬行是一w常薄q应用Q它需要成百上千的web服务器和各种域名服务器的参与Q这些服务器不是我们pȝ所能控制的。ؓ了覆盖几十亿的网，Google拥有快速的分布式网l爬行系l。一个URL服务器给若干个网l爬行机器hQ我们采?个）提供URL列表。URL服务器和|络爬行机器人都是用Python实现的。每个网l爬行机器h可以同时打开300个链接。抓取网必够快。最快时Q用4个网l爬行机器h每秒可以爬行100个网c速率达每U?00K。执行的重点是找DNS。每个网l爬行机器h有它自己的DNS cacheQ所以它不必每个|页都查DNS。每一百个q接都有几种不同的状态：查DNSQ连接主机，发送请求，接收回答。这些因素ɾ|络爬行机器人成为系l比较复杂的部分。它用异步IO处理事gQ若q请求队列从一个网站到另一个网站不停的抓取|页。运行一个链接到500多万台服务器的网늈行机器hQ?千多万登陆口Q导致了大量的Email和电话。因为网民众多，L些h不知道网l爬行机器h是何物，q是他们看到的第一个网l爬行机器h。几乎每天我们都会收到这LEmail“哦Q你从我们的|站看了太多的网，你想q什么？”还有一些h不知道网l搜索机器h避免协议Qthe robots exclusion protocolQ，以ؓ他们的网上写着“版权所有，勿被索引”的字样׃被保护不被烦引，不必_q样的话很难被web crawler理解。因为数据量如此之大Q还会遇C些意想不到的事情。例如，我们的系l曾l企图抓一个在U游戏，l果抓到了游戏中的大量垃圾信息。解册个问题很单。但是我们下载了几千万网后才发Cq个问题。因为网和服务器的U类J多Q实际上不在大部分Internet上运行它测试一个网늈行机器h是不可能。L有几百个隐含的问题发生在整个web的一个网上Q导致网l爬行机器h崩溃Q或者更p，D不可预测的不正确的行为。能够访问大部分Internet的系l必ȝ力充沛ƈ_ֿ试q。由于象crawlerq样大型复杂的系lL产生q样那样的问题，因此p一些资源读q些EmailQ当问题发生时解军_Q是有必要的?
4.4Web索引分析—Q何运行在整个Web上的分析器必能够处理可能包含错误的大型集合。范围从HTML标记到标C间几K字节?Q非ASCII字符Q几癑ֱHTML标记的嵌套，各种各样令h难以惌的错误。ؓ了获得最大的速度Q我们没有采用YACC产生上下文无x法CFG分析器，而是采用灉|的方式生词汇分析器Q它自己配有堆栈。分析器的改q大大提高了q行速度Q它的精力如此充沛完成了大量工作。把文档装入barrel建立索引—分析完一文档，之后把该文档装入barrel中，用内存中的hash表—字典，每个词汇被{换成一个wordID。当hash表字怸加入新的ҎQ笨拙地存入文g。一旦词汇被转换成wordIDQ它们在当前文档的出现就转换成hitlistQ被写进正向barrel。烦引阶Dƈ行的主要困难是字兔R要共享?BR>
我们采用的方法是Q基本字怸?40万个固定词汇Q不在基本字怸的词汇写入日志，而不是共享字典。这U方法多个烦引器可以q行工作Q最后一个烦引器只需处理一个较的额外词汇日志。排序—ؓ了徏立反向烦引，排序器读取每个正向barrelQ以wordID排序Q徏立只有标题anchor hi t的反向烦引barrel和全文反向烦引barrel。这个过E一ơ只处理一个barrelQ所以只需要少量暂存空间。排序阶D也是ƈ行的Q我们简单地同时q行可能多的排序器Q不同的排序器处理不同的桶。由于barrel不适合装入dQ排序器q一步依据wordID和docID把它分成若干子Q以侉K合装入d。然后排序器把每个篮子装入主存进行排序，q把它的内容写回到短反向barrel和全文反向barrel?BR>
4.5搜烦搜烦的目标是提供有效的高质量的搜索结果。多数大型商业搜索引擎好像在效率斚wp了很大力气。因此我们的研究以搜索质量ؓ重点Q相信我们的解决Ҏ也可以用到那些商业系l中?BR>Google查询评hq程见图4?
1. 分析查询?
2. 把词汇{换成wordID?BR>3. 在短barrel中查找每个词汇doclist的开头?BR>4. 扫描doclist直到扑ֈ一匹配所有关键词的文?
5. 计算该文档的rank
6. 如果我们在短barrelQƈ且在所有doclist的末，开始从全文barrel的doclist的开头查找每个词Qgoto W四?BR>7. 如果不在Mdoclist的结，q回W四步?BR>8. Ҏrank排序匚w文档Q返回前k个。图4 Google查询评h在有限的响应旉内，一旦找C定数量的匚w文档Q搜索引擎自动执行步?。这意味着Q返回的l果是子优化的。我们现在研I其它方法来解决q个问题。过L据PageRank排序hitQ看来能够改q这U状c?BR>
4.5.1 Rankingpȝ Google比典型搜索引擎保存了更多的web信息。每个hitlish包括位置Q字P大小写。另外，我们q考虑了链接描q文字。Rankl合所有这些信息是困难的。ranking函数设计依据是没有某个因素对rank影响重大。首先，考虑最单的情况—单个词查询。ؓ了单个词查询中一个文档的rankQGoole在文档的hitlist中查找该词。Google认ؓ每个hit是几U不同类型（标题Q链接描q文字anchorQURLQ普通大字号文本Q普通小字号文本Q……）之一Q每U有它自qcd权重。类型权重徏立了一个类型烦引向量。Google计算hitlist中每Uhit的数量。然后每个hit数{换成count-weight。Count-weight开始随hit数线性增加，很快逐渐停止Q以至于hitC此不相关。我们计count-weight向量和type-weight向量的标量积作ؓ文档的IR倹{最后IR值结合PageRank作ؓ文档的最后rank 对于多词查询Q更复杂些。现在，多词hitlist必须同时扫描Q以便关键词出现在同一文档中的权重比分别出现时高。相邻词的hit一起匹配。对每个匚whit 的集合计相d。相dZhit在文档中的距，分成10个不同的bin|范围从短语匹配到Ҏ不相兟뀂不仅计每chit敎ͼ而且要计每U类型的盔R度，每个cd怼度对Q有一个类型相d权type-prox-weight。Count转换成count-weightQ计count-weight type-proc-weight的标量积作ؓIR倹{应用某Udebug mode所有这些数和矩阵与查询l果一hC出来。这些显C有助于改进rankpȝ?BR>
4.5.2反馈 rank函数有很多参数象type-weight和type-prox-weight。指明这些参数的正确值有炚w色艺术black art。ؓ此，我们的搜索引擎有一个用户反馈机制。值得信Q的用户可以随意地评hq回的结果。保存反馈。然后，当修改rank函数ӞҎ以前搜烦的rankQ我们可以看C改带来的的媄响。虽然不是十全十，但是它给Z一些思\Q当rank函数改变时对搜烦l果的媄响?BR>
5执行和结果搜索结果的质量是搜索引擎最重要的度量标准。完全用戯价体p超Z本文的论q范_对于大多数搜索，我们的经验说明Google的搜索结果比那些主要的商业搜索引擎好。作Z个应用PageRankQ链接描q文字，盔R度的例子Q图4l出了Google搜烦bill Clinton的结果。它说明了Google的一些特炏V服务器对结果进行聚cR这对过滤结果集合相当有帮助。这个查询，相当一部分l果来自whitehouse.gov域，q正是我们所需要的。现在大多数商业搜烦引擎不会q回M来自whitehouse.gov的结果，q是相当不对的。注意第一个搜索结果没有标题。因为它不是被抓到的。Google是根据链接描q文字决定它是一个好的查询结果。同样地Q第五个l果是一个Email地址Q当然是不可能抓到的。也是链接描q文字的l果。所有这些结果质量都很高Q最后检查没有死链接。因为它们中的大部分PageRankD高。PageRank癑ֈ比用U色U条表示。没有结果只含Bill没有Clinton或只含Clinton没有Bill。因出现的相q性非帔R要。当然搜索引擎质量的真实试包含q泛的用户学习或l果分析Q此处篇q有限，误者自己去体验GoogleQhttp://google.stanford.edu/ ?
5.1存储需求除了搜索质量，Google的设计可以随着Web规模的增大而有效地增大成本。一斚w有效地利用存储空间。表1列出了一些统计数字的明细表和Google存储的需求。由于压~技术的应用知识库只需53GB的存储空间。是所有要存储数据的三分之一。按当今盘hQ知识库相对于有用的数据来说比较便宜。搜索引擎需要的所有数据的存储I间大约55GB。大多数查询h只需要短反向索引。文件烦引应用先q的~码和压~技术，一个高质量的搜索引擎可以运行在7GB的新PC?
5.2pȝ执行搜烦引擎抓网和建立索引的效率非帔R要。Google的主要操作是抓网，索引Q排序。很难测试抓全部|页需要多时_因ؓ盘满了Q域名服务器崩溃Q或者其它问题导致系l停止。ȝ来说Q大U需?天时间下?6000000|页Q包括错误）。然而，一旦系l运行顺利，速度非常快，下蝲最?1000000|页只需?3时Q^均每?000000|页Q每U?8.5个网c烦引器和网l爬行机器h同步q行。烦引器比网l爬行机器h快。因为我们花费了大量旉优化索引器，使它不是瓉。这些优化包括批量更新文档烦引，本地盘数据l构的安排。烦引器每秒处理54个网c排序器完全q行Q用4台机器，排序的整个过E大概需?4时?BR>
5.3搜烦执行改进搜烦执行不是我们研究的重炏V当前版本的Google可以??0U间回答查询h。时间大部分p在NFS盘IO上（׃盘普遍比机器慢Q。进一步说QGoogle没有做Q何优化，例如查询~冲区，常用词汇子烦引，和其它常用的优化技术。我们們于通过分布式，gQYӞ和算法的改进来提高Google的速度。我们的目标是每U能处理几百个请求。表2有几个现在版本Google响应查询旉的例子。它们说明IO~冲区对再次搜烦速度的媄响?6l论 Google设计成可伸羃的搜索引擎。主要目标是在快速发展的World Wide Web上提供高质量的搜索结果。Google应用了一些技术改q搜索质量包括PageRankQ链接描q文字，盔R信息。进一步说QGoogle是一个收集网，建立索引Q执行搜索请求的完整的体pȝ构?
6.1未来的工作大型Web搜烦引擎是个复杂的系l，q有很多事情要做。我们直接的目标是提高搜索效率，覆盖大约100000000个网c一些简单的改进提高了效率包括请求缓冲区Qy妙地分配盘I间Q子索引。另一个需要研I的领域是更新。我们必L一个y妙的法来决定哪些旧|页需要重新抓取，哪些新网需要被抓取。这个目标已l由实现了。受需求驱动，用代理cache创徏搜烦数据库是一个有前途的研究领域。我们计划加一些简单的已经被商业搜索引擎支持的特征Q例如布算术符P否定Q填充。然而另外一些应用刚刚开始探索，例如相关反馈Q聚c（Google现在支持单的ZL名的聚类Q。我们还计划支持用户上下文（象用户地址Q，l果摘要。我们正在扩大链接结构和链接文本的应用。简单的实验证明Q通过增加用户主页的权重或书签QPageRank可以个性化。对于链接文本，我们正在试验用链接周围的文本加入到链接文本。Web搜烦引擎提供了丰富的研究N。如此之多以至于我们不能在此一一列DQ因此在不久的将来，我们希望所做的工作不止本节提到的?BR>
6.2高质量搜索当今Web搜烦引擎用户所面的最大问题是搜烦l果的质量。结果常常是好笑的，q且出用户的眼界，他们常常灰心丧气费了宝늚旉。例如，一个最行的商业搜索引擎搜索“Bill Clillton”的l果是the Bill Clinton Joke of the Day: April 14, 1997。Google?设计目标是随着Web的快速发展提供高质量的搜索结果，Ҏ扑ֈ信息。ؓ此，Google大量应用文本信息包括链接结构和链接文本。Googleq用C盔R性和字号信息。评h索引擎是困难的，我们主观地发现Google的搜索质量比当今商业搜烦引擎高。通过PageRank分析链接l构使Google能够评h|页的质量。用链接文本描述链接所指向的网|助于搜烦引擎q回相关的结果（某种E度上提高了质量Q。最后，利用盔R性信息大大提高了很多搜烦的相x?
6.3可升U的体系l构除了搜烦质量QGoogle设计成可升的。空间和旉必须高效Q处理整个Web时固定的几个因素非常重要。实现GooglepȝQCPU、访存、内存容量、磁盘寻道时间、磁盘吞吐量、磁盘容量、网lIO都是瓉。在一些操作中Q已l改q的Google克服了一些瓶颈。Google的主要数据结构能够有效利用存储空间。进一步，|页爬行Q烦引，排序已经_建立大部分web索引Q共24000000个网，用时不到一星期。我们希望能在一个月内徏?00000000|页的烦引?
6.4研究工具 Google不仅是高质量的搜索引擎，它还是研I工兗Google搜集的数据已l用在许多其它论文中Q提交给学术会议和许多其它方式。最q的研究Q例如，提出了Web查询的局限性，不需要网l就可以回答。这说明Google不仅是重要的研究工具Q而且必不可少Q应用广泛。我们希望Google是全世界研究者的资源Q带动搜索引擎技术的更新换代?7致谢 Scott Hassan and Alan Steremberg评h了Google的改q。他们的才智无可替代Q作者由衷地感谢他们。感谢Hector Garcia-Molina, Rajeev Motwani, Jeff Ullman, and Terry Winograd和全部WebBase开发组的支持和富有深刻见解的讨论。最后感谢IBMQIntelQSun和投资者的h支持Qؓ我们提供讑֤。这里所描述的研I是Stanfordl合数字图书馆计划的一部分Q由国家U学自然基金支持Q合作协议号IRI-9411306。DARPA QNASAQInterva研究QStanford数字图书馆计划的工业合作伙伴也ؓq项合作协议提供了资金。参考文??
Google的设计目标是可升U到10亿网c我们的盘和机器大概能处理q么多网c系l各个部分耗费的L间是q行的和U性的。包括网늈行机器hQ烦引器和排序器。扩展后我们认ؓ大多数数据结构运行良好。然?0亿网|q所有常用操作系l的极限Q我们目前运行在Solaris和Linux上）。包括主存地址Q开放文件描q符的数量，|络socket和带宽，以及其它因素。我们认为当|页数量大大过10亿网|Q会大大增加pȝ复杂性?9.2集中式烦引体pȝ可升U性随着计算机性能的提高，量文本索引的成本比较公q뀂当然带宽需求高的其它应用如视频Q越来越普遍。但是，与多媒体例如视频相比Q文本品的成本低，因此文本仍然普遍?
]]>