看了一遍，很多知识点没大看懂，先放在这里~
大型超文本Web搜索引擎的剖析
摘要：在本文中，我们介绍了Google，这是大规模使用超文本中存在的结构的大型搜索引擎的原型。Google旨在有效地对Web进行爬网和编制索引，并产生比现有系统更令人满意的搜索结果。可在http://google.stanford.edu/上获得具有至少2400万页的全文和超链接数据库的原型。设计搜索引擎是一项艰巨的任务。搜索引擎索引数以千万计的网页，涉及相当数量的不同术语。他们每天都会回答数千万条查询。
尽管大型搜索引擎在网络上很重要，但对它们的学术研究却很少。此外，由于技术和网络的迅速发展，今天创建一个网络搜索引擎与三年前大不相同。
本文对我们的大型网络搜索引擎进行了深入的描述，这是迄今为止我们所知道的第一个如此详细的公开描述。
除了将传统搜索技术扩展为如此庞大的数据的问题之外，
使用超文本中存在的附加信息来产生更好的搜索结果还涉及新的技术挑战。
本文解决了有关如何构建可以利用超文本中存在的附加信息的大型系统的问题。
我们还将研究如何有效处理不受控制的超文本集合的问题，任何人都可以发布他们想要的任何东西。
关键字：万维网，搜索引擎，信息检索，PageRank，Google
- 简介（注意：本文有两个版本-较长的完整版和较短的印刷版。完整版可从Web和会议CD-ROM上获得。）
Web带来了信息检索的新挑战。网络上的信息量正在迅速增长，并且网络研究领域的新用户数量也越来越少。人们可能会使用其链接图来上网，通常是从高质量的人工维护索引（例如Yahoo!）开始。或使用搜索引擎。人工维护的清单有效地涵盖了热门话题，但主观，建立和维护成本高，改进缓慢且无法涵盖所有深奥的话题。依赖关键字匹配的自动搜索引擎通常会返回太多低质量的匹配项。更糟糕的是，一些广告商试图采取旨在误导自动搜索引擎的措施来引起人们的关注。我们已经建立了一个大型搜索引擎，可以解决现有系统的许多问题。它特别大量地使用了超文本中存在的附加结构，以提供更高质量的搜索结果。我们选择系统名称Google，因为它是googol的常见拼写或10100，非常适合我们建立超大规模搜索的目标。
-
- Web搜索引擎-扩大规模：1994年-2000年
搜索引擎技术必须进行大规模扩展以跟上Web的发展。
1994年，最早的网络搜索引擎之一，万维网蠕虫（WWWW）[McBryan 94]拥有110,000个网页和可访问网络文档的索引。
截至1997年11月，顶级搜索引擎声称可以将200万个（WebCrawler）索引到1亿个Web文档（来自Search Engine Watch）。可以预见，到2000年，Web的综合索引将包含超过十亿个文档。 同时，搜索引擎处理的查询数量也异常增长。
1994年3月和4月，万维网蠕虫每天平均收到约1500个查询。1997年11月，Altavista声称每天处理大约2000万个查询。随着网络上用户数量的增加以及查询引擎的自动系统，到2000年，顶级搜索引擎每天可能会处理数亿个查询。
我们系统的目标是解决许多通过将搜索引擎技术扩展到如此众多的数量而引入的质量和可扩展性问题。
-
- Google：通过网络进行扩展
创建一个搜索引擎，甚至可以扩展到当今的网络，这带来了许多挑战。需要快速爬网技术来收集Web文档并使其保持最新状态。必须有效地使用存储空间来存储索引以及文档本身（可选）。 索引系统必须有效地处理数百GB的数据。 查询必须以每秒数百到数千的速度快速处理。
随着Web的发展，这些任务变得越来越困难。但是，硬件性能和成本已得到显着提高，部分抵消了这一困难。但是，此进度有几个显着的例外，例如磁盘查找时间和操作系统健壮性。在设计Google时，我们既考虑了网络的增长速度，又考虑了技术变化。Google旨在很好地扩展到超大型数据集。它有效地利用了存储空间来存储索引。其数据结构经过优化，可实现快速有效的访问（请参阅第4.2节）。此外，我们希望索引和存储文本或HTML的成本最终将相对于可用的数量下降（请参阅附录B）。这将为集中式系统（如Google）带来有利的缩放属性。
1.3设计目标
1.3.1改善搜索质量
我们的主要目标是提高Web搜索引擎的质量。1994年，有些人认为，完整的搜索索引将使轻松查找任何内容成为可能。根据1994年Best of the Web Navigators的介绍，“最好的导航服务应该使在网络上几乎可以找到几乎所有内容（一旦输入所有数据）。” 但是，1997年的Web完全不同。最近使用过搜索引擎的任何人都可以很容易地证明索引的完整性不是搜索结果质量的唯一因素。“垃圾结果”通常会清除用户感兴趣的任何结果。实际上，截至1997年11月，排名前四的商业搜索引擎中只有一个能找到自己（返回前十名中的名称返回其自己的搜索页面 结果）。 造成此问题的主要原因之一是索引中的文档数量已经增加了多个数量级，但是用户查看文档的能力却没有。 人们仍然只愿意看前几十个结果。
因此，随着馆藏规模的增长，我们需要具有非常高的精度的工具（返回的相关文档数，例如前几十个结果）。 确实，我们希望我们的“相关”概念仅包括最好的文档，因为可能存在成千上万个稍有相关的文档。 即使以召回（系统能够返回的相关文档总数）为代价，这种非常高的精度也很重要。 最近有相当乐观的看法是，使用更多的超文本信息可以帮助改善搜索和其他应用程序[Marchiori 97] [Spertus 97] [Weiss 96] [Kleinberg 98]。 特别是，链接结构[页98]和链接文本为做出相关性判断和质量过滤提供了很多信息。 Google同时使用链接结构和锚文本（请参阅第2.1和2.2节）。
1.3.2学术搜索引擎
研究除了巨大的增长之外，随着时间的流逝，Web也变得越来越商业化。 1993年，有1.5％的Web服务器位于.com域。 这个数字在1997年增长到60％以上。与此同时，搜索引擎已经从学术领域迁移到商业领域。 到目前为止，大多数搜索引擎的开发都在很少公开技术细节的公司进行。 这导致搜索引擎技术在很大程度上仍然是一种妖术，并且以广告为导向（请参阅附录A）。 使用Google，我们有一个强大的目标，那就是将更多的发展和理解带入学术领域。
另一个重要的设计目标是构建合理数量的人可以实际使用的系统。 使用对于我们很重要，因为我们认为一些最有趣的研究将涉及利用可从现代Web系统获得的大量使用数据。 例如，每天执行数千万次搜索。 但是，很难获得此数据，主要是因为它被认为具有商业价值。
我们的最终设计目标是构建一种架构，以支持对大规模Web数据的新颖研究活动。 为了支持新颖的研究用途，Google以压缩形式存储了其抓取的所有实际文档。 设计Google的主要目标之一是建立一个环境，其他研究人员可以快速进入该环境，处理大量的网络内容，并产生本来很难产生的有趣结果。 在系统启动的短时间内，已经有几篇使用Google生成的数据库的论文，还有许多其他论文正在进行中。 我们的另一个目标是建立一个类似于Spacelab的环境，研究人员甚至学生都可以对我们的大型Web数据提出建议并进行有趣的实验。
- 系统功能
Google搜索引擎具有两项重要功能，可帮助它产生高精度结果。 首先，它利用Web的链接结构来计算每个网页的质量等级。 该排名称为PageRank，在[页98]中有详细描述。 其次，Google利用链接来改善搜索结果。
-
- PageRank：将信息发布到Web上
Web的引文（链接）图是重要的资源，在现有的Web搜索引擎中已大量使用。 我们创建了包含多达5.18亿个此类超链接的地图，这是总数的重要示例。 这些地图可以快速计算网页的“ PageRank”，对其引用重要性的客观衡量，与人们对重要性的主观观念相吻合。 由于这种对应关系，PageRank是确定Web关键字搜索结果优先级的绝佳方法。 对于大多数热门主题，当PageRank对结果进行优先排序时，仅限于网页标题的简单文本匹配搜索就可以表现出色（可在google.stanford.edu上找到示例）。 对于Google主系统中的全文搜索类型，PageRank也有很大帮助。
2.1.1PageRank计算的说明
学术引用文献已应用于网络，主要是通过计算给定页面的引文或反向链接。 这样可以大致估算出页面的重要性或质量。PageRank通过不对所有页面的链接进行平均计数，并通过页面上的链接数进行标准化来扩展此思想。PageRank的定义如下：
我们假设页面A的页面T1 ... Tn指向该页面（即引文）。参数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））
注意，PageRanks在网页上形成概率分布，因此所有网页的PageRanks之和为1。
可以使用简单的迭代算法来计算PageRank或PR（A），它们对应于Web标准化链接矩阵的主要特征向量。 同样，在中等大小的工作站上，可以在几个小时内计算出2600万个网页的PageRank。 还有许多其他细节超出了本文的范围。
2.1.2直观的理由
PageRank可以被视为用户行为的模型。我们假设有一个“随机冲浪者”，他被随机分配一个网页，并不断点击链接，从不点击“后退”，但最终感到无聊，然后从另一个随机页面开始。 随机浏览者访问页面的概率就是其PageRank。并且，d阻尼因子是“随机冲浪者”在每一页上感到无聊并请求另一个随机页的概率。一个重要的变化是仅将阻尼系数d添加到单个页面或一组页面中。 这可以进行个性化设置，并且几乎不可能故意误导系统以获取更高的排名。 我们还有PageRank的其他几个扩展，再次参见[Page 98]。
另一个直观的理由是，如果有许多页面指向该页面，或者有一些页面指向该页面并且具有较高的页面等级，则该页面可以具有较高的页面等级。 直观地讲，在网络上许多地方都被引用得很好的页面值得一看。 另外，某些网页可能仅受到Yahoo!之类的引用。主页通常也值得一看。如果页面质量不高或链接损坏，则雅虎的首页很可能不会链接到该页面。PageRank通过网络的链接结构递归传播权重来处理这些情况以及介于两者之间的所有情况。
2.2锚文本
链接的文本在我们的搜索引擎中以特殊的方式处理。 大多数搜索引擎将链接的文本与链接所在的页面相关联。 此外，我们将其与链接指向的页面相关联。 这有几个优点。 首先，锚通常提供比网页本身更准确的网页描述。 其次，对于无法由基于文本的搜索引擎索引的文档（例如图像，程序和数据库），可能存在锚点。 这样就可以返回尚未实际爬网的网页。 请注意，尚未爬网的页面可能会导致问题，因为在返回给用户之前，从未对它们进行过有效性检查。 在这种情况下，搜索引擎甚至可以返回一个页面，该页面实际上从未存在过，但是具有指向该页面的超链接。 但是，可以对结果进行排序，因此很少发生此特定问题。
在互联网蠕虫[McBryan 94]中实现了将锚文本传播到其引用的页面的想法，特别是因为它有助于搜索非文本信息，并以较少的下载文档扩展搜索范围。 我们使用锚点传播主要是因为锚点文本可以帮助提供更好的质量结果。 由于必须处理大量数据，因此有效地使用锚文本在技术上很困难。 在当前的2400万页面抓取中，我们索引的锚点超过2.59亿。
2.3其他功能
除了PageRank和锚文本的使用以外，Google还有其他一些功能。 首先，它具有所有匹配的位置信息，因此在搜索中广泛使用了邻近性。 其次，Google会跟踪一些视觉演示细节，例如单词的字体大小。 较大或较粗字体的单词的权重高于其他单词。 第三，存储库中提供了完整的页面原始HTML。
3相关工作
网络上的搜索研究历史简短。 万维网蠕虫（WWWW）[McBryan 94]是最早的网络搜索引擎之一。 随后是其他几个学术搜索引擎，其中许多现在是上市公司。 与Web的增长和搜索引擎的重要性相比，很少有关于最近的搜索引擎的文档[Pinkerton 94]。 根据Michael Mauldin（Lycos Inc.首席科学家）[Mauldin]的说法，“各种服务（包括Lycos）都密切保护着这些数据库的细节”。 但是，关于搜索引擎的特定功能已经进行了大量工作。 可以很好地代表工作的是，可以通过对现有商业搜索引擎的结果进行后处理来获得结果，或者生成小规模的“个性化”搜索引擎。 最后，关于信息检索系统，尤其是对受控集合的研究很多。 在接下来的两节中，我们讨论了一些需要扩展此研究才能在网络上更好地工作的领域。
3.1信息检索
信息检索系统中的工作可以追溯到很多年前，并且已经发展成熟[Witten 94]。 但是，有关信息检索系统的大多数研究都集中在小型受控良好的同质收藏上，例如有关相关主题的科学论文或新闻报道的收藏。 确实，信息检索的主要基准，即文本检索会议[TREC 96]，使用了相当小的，受控良好的基准作为其基准。 “非常大的语料库” 基准仅为20GB，而我们从2400万个网页中抓取的147GB则为。 在TREC上运行良好的事情通常不会在网络上产生良好的结果。 例如，假设查询和文档都是通过单词出现定义的矢量，则标准矢量空间模型会尝试返回最接近查询的文档。 在网络上，此策略通常返回非常短的文档，即查询和一些单词。 例如，我们看到一个主要的搜索引擎返回的页面仅包含“比尔·克林顿吮吸”和来自“比尔·克林顿”查询的图片。 有人认为，在网络上，用户应更准确地指定所需内容，并在查询中添加更多单词。 我们强烈不同意这个立场。 如果用户发出诸如“比尔·克林顿”之类的查询，他们应该得到合理的结果，因为有关此主题有大量高质量的信息。 给定这样的示例，我们认为标准信息检索工作需要扩展以有效地处理Web。
3.2 Web和控制良好的集合之间的区别
Web是大量完全不受控制的异构文档的集合。 网络上的文档在文档内部以及可能可用的外部元信息中都有极大的差异。 例如，文档在内部在语言（人工语言和编程语言），词汇表（电子邮件地址，链接，邮政编码，电话号码，产品编号），类型或格式（文本，HTML，PDF，图像，声音）方面存在差异。 甚至可以由机器生成（日志文件或数据库输出）。 另一方面，我们将外部元信息定义为可以推断出有关文档的信息，但并不包含在其中。 外部元信息的示例包括来源信誉，更新频率，质量，受欢迎程度或使用情况以及引用情况。 不仅外部元信息的可能来源有所不同，而且被测量的事物也变化了许多数量级。 例如，将主要网页的使用情况信息进行比较，例如Yahoo的当前每天会收到数百万次的页面浏览量与晦涩的历史文章可能每十年就会收到一次浏览量。 显然，搜索引擎必须对这两项进行非常不同的处理。
网络与传统的受控馆藏之间的另一个巨大区别是，人们对网络上的内容几乎无法控制。 加上这种灵活性，发布具有搜索引擎巨大影响力的任何东西来路由流量，而故意操纵搜索引擎以获取利润的公司则成为一个严重的问题。 传统的封闭式信息检索系统尚未解决此问题。 另外，有趣的是，元数据的工作在Web搜索引擎上已大为失败，因为页面上任何未直接呈现给用户的文本都被滥用来操纵搜索引擎。 甚至还有许多公司专门从事操纵搜索引擎以牟利的公司。
4．系统解剖
首先，我们将对体系结构进行高层讨论。 然后，有一些重要数据结构的深入描述。 最后，将深入研究主要应用程序：爬网，索引编制和搜索。
4.1 Google体系结构概述
在本节中，我们将对整个系统的工作原理进行高层次的概述，如图1所示。其他部分将讨论本节中未提到的应用程序和数据结构。 为了提高效率，大多数Google都使用C或C ++实现，并且可以在Solaris或Linux上运行。
在Google中，网络爬网（下载网页）是由多个分布式爬网程序完成的。
有一个URL服务器，它将要获取的URL列表发送给搜寻器。
然后将获取的网页发送到存储服务器。
然后，存储服务器压缩网页并将其存储到存储库中。
每个网页都有一个关联的ID号，称为docID，每当从网页中解析出一个新URL时，该ID号就会分配。
索引功能由索引器和分类器执行。 索引器执行许多功能。 它读取存储库，解压缩文档并对其进行解析。 每个文档都转换为一组单词，称为hits。 命中记录单词，文档中的位置，字体大小的近似值和大写。 索引器将这些命中分布到一组“桶”中，从而创建了部分排序的前向索引。 索引器执行另一个重要功能。 它解析每个网页中的所有链接，并将有关它们的重要信息存储在锚文件中。 该文件包含足够的信息来确定每个链接指向和指向的位置以及链接的文本。
URLresolver读取锚文件，并将相对URL转换为绝对URL，然后转换为docID。 它将锚文本放入与索引指向的docID相关联的前向索引中。 它还会生成一个链接数据库，该链接是docID对。 链接数据库用于计算所有文档的PageRanks。
排序器采用按docID排序的桶（这是一种简化，请参见第4.2.5节），然后使用wordID对它们进行排序以生成倒排索引。 这是就地完成的，因此此操作只需要很少的临时空间。 排序器还会生成wordID和偏移量索引的列表。 名为DumpLexicon的程序将这个列表与索引器生成的词典一起使用，并生成供搜索者使用的新词典。 搜索器由Web服务器运行，并使用DumpLexicon构建的词典以及反向索引和PageRanks来回答查询。
4.2主要数据结构
Google的数据结构已经过优化，因此可以以很少的成本对大型文档集进行爬网，索引和搜索。 尽管多年来，CPU和大容量输入输出速率已得到显着提高，但磁盘搜索仍需要大约10毫秒才能完成。 Google旨在尽可能避免磁盘寻道，这对数据结构的设计产生了很大影响。
4.2.1 BigFiles
BigFiles是跨越多个文件系统的虚拟文件，并且可以通过64位整数寻址。 多个文件系统之间的分配是自动处理的。 BigFiles程序包还处理文件描述符的分配和释放，因为操作系统不能满足我们的需求。 BigFiles还支持基本的压缩选项。
4.2.2资源库
资源库包含每个网页的完整HTML。 每个页面都使用zlib压缩（请参阅RFC1950）。 压缩技术的选择是速度和压缩比之间的折衷。 我们选择zlib的速度，而不是bzip所提供的压缩方面的重大改进。 与zlib的3：1压缩相比，存储库中bzip的压缩率约为4：1。 在存储库中，文档一个接一个地存储，并以docID，长度和URL为前缀，如图2所示。该存储库不需要使用其他数据结构即可访问它。 这有助于提高数据一致性，并使开发更加容易。 我们可以仅从存储库和列出爬网程序错误的文件中重建所有其他数据结构。
4.2.3文档索引
文档索引保留有关每个文档的信息。 它是固定宽度的ISAM（索引顺序访问模式）索引，按docID排序。 存储在每个条目中的信息包括当前文档状态，存储库的指针，文档校验和以及各种统计信息。 如果文档已被爬网，它还将包含一个指向docinfo的可变宽度文件的指针，该文件包含其URL和标题。 否则，指针将指向仅包含URL的URLlist。 这种设计决定是由对具有合理紧凑的数据结构的渴望以及在搜索过程中能够在一个磁盘搜索中获取记录的能力所驱动的。
此外，还有一个用于将URL转换为docID的文件。 它是URL校验和及其相应docID的列表，并按校验和排序。 为了找到特定URL的docID，需要计算URL的校验和，并对校验和文件执行二进制搜索以找到其docID。 通过与此文件合并，可以将URL批量转换为docID。 这是URLresolver用来将URL转换为docID的技术。 这种批处理更新的方式至关重要，因为否则我们必须对每个链接执行一次搜索，假设对于我们的3.22亿个链接数据集，一个磁盘将花费一个多月的时间。
4.2.4词典
词典具有几种不同的形式。 与早期系统相比，一个重要的变化是词典可以以合理的价格放入内存。 在当前的实现中，我们可以将词典保存在具有256 MB主内存的计算机上的内存中。 当前的词典包含1400万个单词（尽管一些稀有单词未添加到词典中）。 它分为两部分实现-单词列表（连接在一起但由空值分隔）和指针的哈希表。 对于各种功能，单词表具有一些辅助信息，这些信息超出了本文的范围，无法完全解释。
4.2.5命中列表
命中列表对应于特定文档中特定单词出现的列表，包括位置，字体和大写信息。 命中列表占据了前向和反向索引中使用的大部分空间。 因此，尽可能高效地表示它们很重要。 我们考虑了几种编码位置，字体和大写字母的方法-简单编码（整数的三倍），紧凑编码（手动优化的位分配）和霍夫曼编码。 最后，我们选择了一种手动优化的紧凑编码，因为它比简单编码所需的空间少得多，比霍夫曼编码所需的位处理少得多。 命中的详细信息如图3所示。
我们的紧凑编码每次命中使用两个字节。 命中分为两种：花式命中和普通命中。 热门匹配包括出现在URL，标题，锚文本或元标记中的匹配。 普通命中包括其他所有内容。 普通命中由大写位，字体大小和文档中单词位置的12位组成（所有高于4095的位置都标记为4096）。 相对于文档的其余部分，字体大小使用3位表示（实际上仅使用7个值，因为111是表示花哨的信号的标志）。 花式匹配包含一个大写位，字体大小设置为7（表示它是花式匹配），4位（用于编码花样匹配的类型）和8位位置。 对于定位符命中，位置的8位被分为4位定位符和4位哈希值，用于出现定位符的docID。这为我们提供了一些有限的词组搜索，只要没有太多的定位符即可 特定的词。 我们希望更新锚定命中的存储方式，以便在position和docIDhash字段中获得更大的分辨率。 我们使用相对于文档其余部分的字体大小，因为在搜索时，您不希望仅由于其中一个文档使用较大的字体而对其他相同文档进行不同的排名。
命中列表的长度存储在命中本身之前。 为了节省空间，将命中列表的长度与前向索引中的wordID和反向索引中的docID组合在一起。 这分别将其限制为8位和5位（有一些技巧可以从wordID借用8位）。 如果该长度长于该位数，则在这些位中使用转义码，随后的两个字节包含实际长度。
4.2.6前向索引
前向索引实际上已经部分排序。 它存储在许多桶中（我们使用了64个）。 每个桶都装有一定范围的wordID。 如果文档中包含落入特定桶中的单词，则docID会记录在桶中，然后是单词ID的列表，以及与这些单词相对应的命中列表。 由于重复的docID，该方案需要更多的存储空间，但是对于合理数量的存储桶而言，差异很小，并且在分拣器完成的最后索引阶段中节省了可观的时间和编码复杂性。 此外，我们不存储实际的wordID，而是将每个wordID存储为与落入wordID所在桶中的最小wordID的相对差。这样，我们可以仅将24位用于未排序桶中的wordID，剩下8位 匹配列表的长度。
4.2.7反向索引
反向索引由与正向索引相同的桶组成，除了它们已由分拣器处理过。 对于每个有效的wordID，词典都包含一个指向wordID所属桶的指针。 它指向docID的文档列表及其相应的命中列表。 此文档列表表示该单词在所有文档中的所有出现。
一个重要的问题是docID应该以什么顺序出现在doclist中。 一种简单的解决方案是存储按docID排序的它们。 这样可以快速合并不同文档列表以进行多个单词查询。 另一种选择是按每个文档中单词出现的顺序对它们进行存储。 这使得回答一个单词查询变得微不足道，并可能使多个单词查询的答案接近开始。 但是，合并要困难得多。 而且，这使开发变得更加困难，因为对排名函数的更改要求重建索引。 我们在这些选项之间做出了折衷选择，保留了两组倒置的发条盒-一组用于命中列表，包括标题或锚定命中，另一组用于所有命中列表。 这样，我们首先检查第一个桶，如果这些桶中没有足够的匹配项，我们将检查较大的桶。
4.3
运行网络搜寻器是一项艰巨的任务。 存在棘手的性能和可靠性问题，更重要的是，存在社会问题。 爬网是最脆弱的应用程序，因为它涉及与成千上万的Web服务器以及各种超出系统控制范围的名称服务器进行交互。
为了扩展到数亿个网页，Google提供了一个快速的分布式爬网系统。 单个URL服务器为多个爬虫提供URL列表（我们通常运行大约3个）。 URLserver和搜寻器均以Python实现。 每个搜寻器一次大约保持300个连接打开。 要以足够快的速度检索网页，这是必需的。 以最高速度，系统可以使用四个搜寻器每秒爬行100个以上的网页。 这相当于每秒大约60万个数据。 主要的性能压力是DNS查找。 每个搜寻器都维护自己的DNS缓存，因此在搜寻每个文档之前不需要进行DNS查找。 数百个连接中的每个连接都可以处于多种不同的状态：查找DNS，连接到主机，发送请求和接收响应。 这些因素使搜寻器成为系统的复杂组件。 它使用异步IO来管理事件，并使用多个队列将页面获取从一个状态移到另一个状态。
事实证明，运行连接到超过一百万台服务器的爬虫并生成数以千万计的日志条目会产生大量的电子邮件和电话。 由于人数众多，总有一些人不知道什么是履带车，因为这是他们所见到的第一个。 几乎每天，我们都会收到一封电子邮件，例如：“哇，您在我的网站上浏览了很多页面。您感觉如何？” 还有一些人不了解机器人排除协议，并认为应该通过诸如“此页面已受版权保护，不应被索引”之类的语句保护其页面免遭索引，这对于网络爬虫而言无疑是困难的 了解。 另外，由于涉及大量数据，所以会发生意外情况。 例如，我们的系统尝试抓取在线游戏。 这导致了游戏过程中出现大量垃圾信息！ 事实证明，这是一个容易解决的问题。 但是直到我们下载了数以千万计的页面之后，这个问题才出现。 由于网页和服务器的巨大差异，如果不在Internet的大部分上运行爬虫，则几乎不可能对其进行测试。 总是有数百个晦涩的问题，它们可能只出现在整个Web的一页上，并导致搜寻器崩溃，或更糟糕的是，导致无法预测或错误的行为。 访问Internet大部分的系统需要设计得非常健壮并经过仔细测试。 由于大型复杂系统（例如爬网程序）总是会引起问题，因此需要大量的资源专门用于阅读电子邮件并解决这些问题。
4.4为Web解析
建立索引-任何旨在在整个Web上运行的解析器都必须处理大量可能的错误。 这些错误的范围从HTML标签的错别字到标签中间的千字节零，非ASCII字符，HTML标签嵌套了数百个深处，以及其他各种各样的错误，这些错误挑战着任何人的想象力，他们都想出同样有创意的错误。 为了获得最大速度，我们没有使用YACC生成CFG解析器，而是使用flex生成了词法分析器，并为其配备了自己的堆栈。 开发以合理的速度运行并且非常健壮的解析器需要大量的工作。
将文档索引到桶中-解析每个文档后，将其编码到多个桶中。 通过使用内存中的哈希表（词典）将每个单词转换为wordID。 词典哈希表的新添加内容将记录到文件中。 一旦将单词转换为wordID，这些单词在当前文档中的出现就会转换为命中列表，并写入前滚桶。 索引阶段并行化的主要困难是需要共享词典。 我们没有共享词典，而是采取了记录所有不在基本词典中的额外单词的日志的方法，我们将其固定为1400万个单词。 这样，多个索引器可以并行运行，然后一个最终索引器可以处理少量多余单词的日志文件。
排序-为了生成倒排索引，排序器采用每个前向桶并将其按wordID进行排序，以生成用于标题和锚点命中的倒置桶以及全文倒排桶。 此过程一次发生一桶，因此几乎不需要临时存储。 另外，我们通过运行多个分类器来并行化分类阶段，以使用尽可能多的机器，这些分类器可以同时处理不同的存储桶。 由于桶无法放入主存储器中，因此分类器将其进一步细分为篮子，这些篮子会根据wordID和docID放入存储器中。 然后，分类器将每个篮子装入内存，进行分类，然后将其内容写入短反向桶和全反向桶。
4.5搜索
搜索的目的是有效地提供高质量的搜索结果。 在效率方面，许多大型商业搜索引擎似乎已经取得了长足的进步。 因此，尽管我们相信我们的解决方案需要更多的努力才能扩展到商业规模，但我们在研究中更加注重搜索质量。 google查询评估过程如图4所示。
为了限制响应时间，一旦找到一定数量（当前为40,000个）的匹配文档，搜索器将自动转到图4中的步骤8。这意味着有可能返回次优结果。 我们目前正在研究其他方法来解决此问题。 过去，我们是根据PageRank对点击进行排序的，这似乎可以改善这种情况。
4.5.1排名系统Google维护的网络文档信息比典型的搜索引擎多得多。 每个命中列表都包括位置，字体和大写信息。 此外，我们将锚文本和文档的PageRank中的匹配因素考虑在内。 很难将所有这些信息组合在一起。 我们设计了排名函数，以使任何特定因素都不会产生太大影响。 首先，考虑最简单的情况-单个单词查询。 为了使用单个单词查询对文档进行排名，Google会查看该单词在该文档的匹配列表中。 Google认为每次匹配都是几种不同的类型之一（标题，锚点，URL，纯文本大字体，纯文本小字体等），每种类型都有自己的类型权重。 类型权重构成按类型索引的向量。 Google会在命中列表中计算每种类型的命中数。 然后将每个计数转换为计数权重。 首先，计数权重随计数线性增长，但很快逐渐减小，因此超过某个计数将无济于事。 我们将权重向量与类型权重向量的点积用于计算文档的IR分数。 最后，将IR得分与PageRank结合在一起，为文档给出最终排名。
对于多词搜索，情况更为复杂。 现在，必须立即扫描多个匹配列表，以使文档中同时出现的匹配的权重高于相距较远的匹配的权重。 匹配多个匹配列表中的匹配，以便将附近匹配匹配在一起。 对于每个匹配的命中集，都会计算出接近度。 接近度基于匹配项在文档（或锚点）中的距离，但分为10个不同的值“箱”，范围从词组匹配到“甚至不接近”。 不仅会针对每种点击类型计算计数，还会针对每种类型和接近度计算计数。 每个类型和接近对都有一个类型权重。 计数被转换为计数权重，我们采用计数权重和类型近似权重的点积来计算IR得分。 使用特殊的调试模式，所有这些数字和矩阵都可以与搜索结果一起显示。 这些显示对于开发排名系统非常有帮助。
4.5.2反馈排名功能具有许多参数，例如类型权重和类型权重。 弄清楚这些参数的正确值是一件荒诞的事情。 为此，我们在搜索引擎中提供了一种用户反馈机制。 受信任的用户可以选择评估返回的所有结果。 此反馈已保存。 然后，当我们修改排名功能时，我们可以看到此更改对所有先前排名的搜索的影响。 尽管还不完美，但这给了我们一些1.解析查询。 2.将单词转换为wordID。 3.在每个字词的短桶中找到文档列表的开头。 4.扫描文档列表，直到找到与所有搜索词匹配的文档。 5.计算该文档的查询等级。 6.如果我们处于短桶中并且在任何文档列表的末尾，请针对每个单词在完整桶中寻求文档列表的开始，然后转到步骤4。7.如果我们不在任何文档列表的末尾，请转到 到步骤4。按等级对匹配的文档进行排序，然后返回前k个。
图4. Google Query Evaluation关于排名函数的变化如何影响搜索结果的想法。
搜索引擎最重要的衡量标准是其搜索结果的质量。
尽管完整的用户评估不在本文讨论范围之内，但我们在Google上的经验表明，与大多数商用搜索引擎相比，它产生的搜索结果要好于主要的商业搜索引擎。举例说明PageRank，锚文本和邻近度的用法，图4显示了Google在“比尔·克林顿”上进行搜索的结果。
这些结果证明了Google的某些功能。 结果由服务器群集。 在结果集中进行筛选时，这有很大帮助。 许多结果来自whitehouse.gov域，这是从这种搜索中可以合理预期的结果。 当前，大多数主要的商业搜索引擎都不会从whitehouse.gov返回任何结果，更不用说返回正确的结果了。 请注意，第一个结果没有标题。 这是因为它没有被爬网。 取而代之的是，Google依靠锚文本来确定这是查询的一个很好的答案。 同样，第五个结果是一个电子邮件地址，该地址当然不可爬网。 这也是锚文本的结果。
所有结果均为相当高质量的页面，最后检查时，没有损坏的链接。 这主要是因为它们都有很高的PageRank。 PageRanks是红色的百分比以及条形图。 最后，除了克林顿以外，没有关于比尔的任何结果，除了比尔以外，没有关于克林顿的结果。 这是因为我们非常重视单词出现的邻近性。 当然，对搜索引擎质量的真正测试将涉及广泛的用户研究或结果分析，而我们在这里没有余地。 相反，我们邀请读者访问http://google.stanford.edu自己尝试使用Google。
5.1存储要求
除了搜索质量外，Google的目的还在于随着网络的发展有效地将成本有效地扩展到Web的规模。 这样的一方面是有效地使用存储。 表1列出了Google的一些统计信息和存储要求。 由于压缩，存储库的总大小约为53 GB，仅超过其存储的总数据的三分之一。 以当前磁盘价格计，这使存储库成为相对便宜的有用数据源。 更重要的是，搜索引擎使用的所有数据总量需要相当数量的存储，大约为55 GB。 此外，大多数查询可以仅使用短反向索引来回答。 通过对文档索引进行更好的编码和压缩，高质量的Web搜索引擎可以安装在新PC的7GB驱动器上。
5.2系统性能
对于搜索引擎而言，有效地进行爬网和建立索引非常重要。 这样可以使信息保持最新状态，并且可以相对快速地测试系统的主要更改。 对于Google来说，主要操作是爬网，建立索引和排序。 由于磁盘已满，名称服务器崩溃或任何其他导致系统停止的问题，因此很难衡量整个爬网所花费的时间。 总共花费了大约9天的时间下载了2600万页（包括错误）。 但是，一旦系统运行平稳，它就会运行得更快，仅需63个小时即可下载最后的1100万页，平均每天超过400万页或每秒48.5页。 我们同时运行索引器和搜寻器。 索引器的运行速度比搜寻器快。 这主要是因为我们花了足够的时间优化索引器，因此它不会成为瓶颈。 这些优化包括对文档索引的批量更新以及关键数据结构在本地磁盘上的放置。 该索引器的运行速度约为每秒54页。 分类器可以完全并行运行； 使用四台机器，整个分类过程大约需要24小时。
5.3搜索性能
到目前为止，提高搜索性能并不是我们研究的重点。 当前版本的Google会在1到10秒内回答大多数查询。 这段时间主要由NFS上的磁盘IO主导（因为磁盘分散在许多计算机上）。 此外，Google没有任何优化，例如查询缓存，通用术语的子索引和其他通用优化。 我们打算通过发行以及硬件，软件和算法方面的改进来大大提高Google的速度。 我们的目标是能够每秒处理数百个查询。 表2提供了一些有关当前Google版本的查询时间示例。 重复它们以显示由缓存的IO导致的加速。
6.总结
Google被设计为可扩展的搜索引擎。 主要目标是在快速发展的万维网上提供高质量的搜索结果。Google采用了多种技术来提高搜索质量，包括页面排名，锚文本和邻近信息。 此外，Google是用于收集网页，对其进行索引并对其进行搜索查询的完整体系结构。
6.1未来的工作
大型网络搜索引擎是一个复杂的系统，还有很多工作要做。 我们的近期目标是提高搜索效率，并扩展到大约1亿个网页。 一些简单的效率改进包括查询缓存，智能磁盘分配和子索引。 另一个需要大量研究的领域是更新。 我们必须拥有明智的算法来决定应重新爬网哪些旧网页，以及应该对哪些新网页进行爬网。 在[Cho 98]中已经朝着这个目标努力。 一项有前途的研究领域是使用代理缓存来构建搜索数据库，因为它们是需求驱动的。 我们计划添加由商业搜索引擎支持的简单功能，例如布尔运算符，取反和词干。 但是，其他功能（例如相关性反馈和聚类）才刚刚开始探索（Google当前支持基于主机名的简单聚类）。 我们还计划支持用户上下文（例如用户的位置）以及结果汇总。 我们还致力于扩展链接结构和链接文本的使用。 简单的实验表明，可以通过增加用户主页或书签的权重来个性化PageRank。 对于链接文本，除了链接文本本身之外，我们正在尝试使用围绕链接的文本。 Web搜索引擎是研究思想的非常丰富的环境。 我们在这里列出的内容太多了，因此我们不希望“未来工作”部分在不久的将来变得更短。
6.2高质量搜索
当今Web搜索引擎用户面临的最大问题是他们返回的结果的质量。 虽然结果常常很有趣，并且扩大了用户的视野，但结果却令人沮丧并浪费了宝贵的时间。 例如，在最流行的商业搜索引擎之一上搜索“比尔·克林顿”的最高结果是“当日的比尔·克林顿笑话”：1997年4月14日。Google旨在提供更高质量的搜索，因此网络在不断发展 快速增长，就可以轻松找到信息。 为了实现这一目标，Google大量使用了由链接结构和链接（锚定）文本组成的超文本信息。 Google还使用邻近性和字体信息。 尽管很难评估搜索引擎，但我们主观上发现Google返回的搜索结果质量要高于当前的商业搜索引擎。 通过PageRank对链接结构的分析使Google可以评估网页的质量。 使用链接文本作为链接所指向内容的描述可帮助搜索引擎返回相关的（并在某种程度上为高质量）结果。 最后，邻近信息的使用大大提高了许多查询的相关性。
6.3可扩展的体系结构
除了搜索的质量外，Google还具有扩展性。 它在空间和时间上都必须高效，并且在处理整个Web时，恒定因素非常重要。 在实施Google时，我们已经看到了CPU，内存访问，内存容量，磁盘查找，磁盘吞吐量，磁盘容量和网络IO的瓶颈。 Google已发展为克服各种运营过程中的许多瓶颈。 Google的主要数据结构有效利用了可用的存储空间。 此外，爬网，索引和排序操作的效率足够高，能够在不到一周的时间内建立Web的很大一部分（2400万页）的索引。 我们希望能够在不到一个月的时间内建立1亿页的索引。
6.4研究工具
除了成为高质量的搜索引擎之外，Google还是研究工具。 Google收集的数据已经导致许多其他论文提交给会议，并且还在进行中。 最近的研究，例如[Abiteboul 97]，显示了对有关Web的查询的一些限制，这些限制可能会在没有本地可用的Web的情况下得到回答。 这意味着Google（或类似系统）不仅是有价值的研究工具，而且还是广泛应用程序的必要工具。 我们希望Google将成为全球搜索者和研究人员的资源，并激发下一代搜索引擎技术。
没有完全翻译完~先这样~有问题请指正~
