《Web Search Engines》翻译

<@Aattention Content="本Blog原创文章，转载或引用请注明转载" From="Robby.cnblogs.com"@>      
      最近很忙啊，今天抽空上来写点。
      上次的文章中向大家推荐了一篇老外的文章《Web Search Engines》，新手入门看不错，于是将自己的翻译搬上来给不熟鸟语的同志们参考参考（目前只翻译了前半部分），翻译的比较仓促，翻译的好坏就不管了，能让大家看懂而不误导大家就行了，HoHo 。

—————————————————————割—————————————————————————

原文： Web search engines Part_1

我的翻译：

网络搜索引擎

大卫·霍金（David Hawking）

澳大利亚国家科学与工业研究组织 ICT中心

1995年，当互联网上的“有用且可搜”的网页有数千万张时，人们广泛的相信“将整个互联网索引”这个说法将在网页数量指数级的增长下变得不切实际。但仅仅在十几年之后，GYM搜索引擎－Google，Yahoo！和Microsoft却能在一天内索引几千次数据并且为几十亿的查询提供秒级查询反映的服务。

如果这些还不够说明搜索引擎的重要性，那么再来看看现在主要的搜索引擎提供了更好的查询质量。对大多数使用者来说，这些搜索引擎非常好的将查询结果分级、展示，在变更搜索内容的时候反映更加迅速，并且有效的消除死链(Dead Links)、冗余页面、和一些无意义的信息。

在本文的两部分中，我们将透过这些现象来解释这样一个数据处理“神话”是怎样变成现实的。我们的关注点在于对整个互联网的搜索，其实这和一些企业级的搜索工具和搜索接口等用的大多数都是同样的数据结构和算法。

搜索引擎无法也不应该将互联网的每一个页面都索引。毕竟，我们要感谢动态网页生成器，比如自动日历，这使得网页的数量是无限的。

提供一个有用的并且成本效率较高的服务，搜索引擎必须拒绝尽可能多的低价值的自动生成的内容。另外，它可以忽略一些大容量的网上数据，比如海洋温度、天文气象等，以使得数据搜索能更有效率。最后，网络搜索引擎并不能取得受限的内容，如企业内部网的网页数据。

接下来的内容并不是对那些严密保守其商业机密的商业搜索引擎的深入介绍，而是对现今所有的网络搜索引擎所面临的问题的描述和对解决这些问题的方法、技术的解释。

 

基础构造

    （图1）展示了一个一般的搜索引擎的构架。对于冗余和容错，大型的搜索引擎运作于多样的分布式的数据中心。在一个数据中心里，服务是由集群的PC机构成的。这些集群中PC机的类型取决于价格、CPU的速度、内存和硬盘容量、热量散发、可靠性和体型大小。 （http://labs.google.com/papers/googlecluster-ieee.pdf ）。据报道，现在最大的搜索引擎的所有服务器的数量达到了几十万。
     在一个数据中心里，集群的或者单独的服务器都可以用来实现一个专门的功能，比如说抓取、索引、查询处理、产生摘录、链表计算、结果的缓存或者插入广告内容。（表1）提供了网络搜索引擎的专用术语定义。

大比例的复制需要对必须吞吐量的控制。举个例子，如果一套特定的硬件能够每500毫秒响应一次查询，那么搜索引擎公司必须要千倍的复制这个硬件来达到每秒2000次查询的吞吐量。在这些复制的集群中分担负荷就需要高吞吐量，高可靠性的网络环境。

    通常来说，搜索引擎抓取和索引的网络数据量是400TB，即400000GB，这给服务器和网络带来了沉重的负担。一次完整的爬行抓取会填满一个10Gbps的网络连接超过10天。这些数据的索引结构也会达到100TB，导致数据中心的主要挑战成为了维护索引的健全和坚固。从一个数据中心将一整套索引复制至另一个数据中心需要在每秒10GB的网络上传输1天以上。

爬行算法

最简单的爬行算法使用一组要被访问的URL和一个能够快速确定是否浏览过该URL的机制。这需要非常庞大的数据结构－一个1TB以上，包含了200亿URL的目录。

爬行器从一个或者多个“源”URL出发来初始化URL队列。一个高质量的源URL会链接至许多高质量的网站，举个例子，www.dmoz.org或者 wikipedia.org。

爬行进程通过发出HTTP请求来取得URL列表中的第一个URL。当爬行器取得网页后，它扫描网页内容以寻求通向其他URL的链接并把之前没有的URL加入到队列中。最后，爬行器保存网页内容用于索引。爬行器会一直工作，知道URL队列为空。

 

真实的爬行器

实践中，这个爬行器算法的演示必须要扩展以支持以下的功能。

速度。如果每个HTTP请求需要花费1秒钟去完成－毕竟有些会用更长的时间或者响应失败－简单的爬行器每天能抓取86400个网页以上。以这个速度，爬行200亿的网页将会耗去634年的时间。实践中，爬行是由上百个分布式的爬行器来实现的。

一个哈希函数用来明确哪个爬行器来负责哪个特定的URL。如果一个爬行器遇到一个不是它所负责的URL时，它会传递URL给负责这个URL的爬行器。

哪怕是上百倍的平行处理都无法充分满足必须的爬行速率。因此每个爬行器都拓展了更高级别的内部平行处理，即用千百个的线程去发出请求和等待响应。

有礼貌的。除非特殊照顾，平行爬行器会产生单个的网络服务器遭受HTTP请求的轰击而变得负荷过重的风险。爬行算法被设计成要确保对于一个网络服务器同一时间里只有一个请求并且在两个请求间还有一个礼貌性的时间延迟。这同时还必须考虑到互联网的瓶颈；举个例子，搜索引擎爬行器要有充分的带宽去完成对全国网络链接的遍历。

    排除内容。在从网站抓取一个网页前，爬行器必须抓取网站的robots.txt文件用来确认网管是否定义了一些或者所有的内容都可以被抓取。

相同内容。同样的内容频繁的出现在不同的URL中。简单的查询比较就能精确的检测到重复，但是当一个网页包含了自己的URL，用户计数器，或者数据时，就需要更多有效的识别方法。

爬行器能通过识别和尽早的排除重复从而保存大量的资源，因为未识别的重复网页会包含指向其他重复内容的整个家族的相关链接。

连续的爬行。以固定的时间间隔完成完整的爬行意味着对互联网上的重要变动的不敏感。这同样也意味着爬行器会连续的抓取那些低价值的和静态的网页，因此招致实质性的损失而没有有意义的好处。举个例子，企业网站的2002年的媒体很少发布，万一需要爬行。

很有趣的是，当提交“current time New York（翻译：现在纽约的时间）”的查询时，GYM引擎显示出这些引擎每过几天都会去爬行www.timeanddate.com/ worldclock网站。然而，不管搜索引擎多么频繁的去爬行这个网站，搜索的结果总是显示错误的时间。

用一个优先队列来替代简单队列，增加爬行的有效性。处于队列最前部分的URL有最高的被爬行优先级，基于例如变化频繁，引入链接计数，点击频繁等事实。当一个URL被爬行后，它按照它的评估优先级被重新插入到队列中。在这个模型里，爬行不需要停止。

拒绝垃圾信息。原始的垃圾信息技术，像在浏览者可以查看的网页里插入有误导性的关键词－举个例子，在白色的背景上写白色的字，0号大小的字，或者META标签－很容易被检测到。无论如何，现在基于链接内容的排名机制使得它们变得无效（www-db.stanford.edu/pub/papers/google.pdf）。

    时下的垃圾信息制造者在域，服务器，链接和网页上创造人造的网络美景，从而在他们希望得到晋升的目标中获得充足的链接评分。垃圾信息制造者也做掩饰，一个提交给爬行器不同的内容多于给与网站浏览者的过程。

搜索引擎公司用人工和自动的方法分析链接模版和内容，从而判别哪个是垃圾信息网站，进而将其放入一个黑名单中。爬行器能拒绝指向在黑名单中的URL的链接，并且能拒绝或者降低那些链接向、被链接于黑名单网站的网页的优先级。

 

最后关于爬行的思考。

    网络爬行器的全部事情必须包括用JavaScript来解码超链接；从二进制文件，像PDF和微软的WORD文件里抽出可索引的单词或者和链接；转换文字编码，像转换ASCII，Windows代码页和Shift-JIS为Unicode，从而使得索引一致性（www.unicode.org/standard/standard.html）。

设计一个网络级的爬行器不是无技能和胆小的人能做的。爬行器是一个高度复杂的平行系统，和数百万的不同的网络服务器通信，在它们之间能发现每一个可能的失败方式，所有有准备的和意外的爬行器陷阱方式，和每一个发布标准中变化多样的拒绝事件。因此，Mercator爬行器的作者发现写下他们自己低级系统软件的版本号，从而实现必须的性能和可靠性是必须的（www. research. Compaq.com/SRC/mercator/papers/www/paper.html）。

发现一个爬行器被锁上，中断，崩溃，毁坏了整个网络传输的预算，或者不小心攻击了网络服务器造成网络堵塞并且使得那个网络操作员非常愤怒，已经不是稀有的事了。。。。。。。。。

———————————————割———————————————————

第一部分到这里先，以后有空再翻第二部分。

转载于:https://www.cnblogs.com/Robby/archive/2007/04/12/710698.html