高效Web搜集系统的结构设计与评价.docx
《高效Web搜集系统的结构设计与评价.docx》由会员分享，可在线阅读，更多相关《高效Web搜集系统的结构设计与评价.docx（15页珍藏版）》请在冰豆网上搜索。
高效Web搜集系统的结构设计与评价
高效Web搜集系统的结构设计与评价
闫宏飞王建勇李晓明郭琳
（北京大学计算机科学与技术系网络与分布式系统研究室，北京，100871）
摘要
快速有效地搜集WWW上的网页，使搜索引擎索引更多的网页，是提供高质量服务的基础。
本文基于“天网”搜索引擎系统1.2版提供了一个采用分布式技术在WWW上搜集网页的实验模型。
在实验模型达到预期效果后，通过对实验产生的数据分析、总结，确定了实际系统开发应该采用的策略方法。
本文论述的系统结构和方法，正用于“天网”2.0版的开发，达到搜集尽中国所有网页的目的。
关键词万维网、搜索引擎、分布式、多点传送
ArchitecturalDesignandEvaluationofanEfficientWeb-crawlingSystem
YanHongfei,WangJianyong,LiXiaomingandGuoLin
Networking&DistributedComputerSystemsLaboratory
DepartmentofComputerScience&Technology
PekingUniversity
AbstractEfficientlycollectingwebpagesplaysanimportantroleinthesearchengineresearcharea,whichcanprovidealargeindextosearchengine,andthenimprovethequalityofsearchingservice.ThispaperpresentsanarchitectureandproposesmethodsofcollectingwebpagesontheWWWusingdistributedsearchenginesystem.Afterthesuccessoftheexperiment,throughanalyzingandsummarizingdatagottenfromtheexperiment,wemadeourstrategiesontheactualsystem.OurfinalgoalistocollectallthewebpagesinChinausingthenewversionofthesearchengine.
KeywordsWorldWideWeb,SearchEngine,DistributionSystem,Multicast
1引言
在互联网不长的历史中，网络资源与日俱增，网页数目迅速增长。
如何能够快速、准确地在纷繁的信息网中定位自己需要的东西？
搜索引擎成为一个越来越重要的技术手段。
要在搜索引擎中尽可能地找到用户所需信息，就要求搜索引擎索引尽可能多的网页。
因此索引网页数量是评价一个搜索引擎好坏的关键因素之一。
要索引更多的网页就要获取更多的网页，因此高效地获取网页是一个好的搜索引擎的基础。
提到“高效”执行某些大数据量的工作，人们容易想到“分布式”、“并行处理”这样的字眼。
事实也是如此。
目前，日访问量已突破3万的北大“天网”中英文搜索引擎系统（WebGather）[1]1.2版采用集中式搜集网页的处理方式（一个主控控制多个搜集程序并行工作），索引网页达到100万量级。
全部网页更新周期为10天，即每天大约要搜集10万网页，达到100万量级。
出自斯坦福大学的Google[2]搜索引擎在2000年7月可以索引560,000,000网页[3]，要达到这个量级，网页的更新是集中式系统在短时间内所不能胜任的。
如果以WebGather的速度，要达到1000万量级需要100天，100天中由于网页的更新，将使搜集到的部分网页失去意义。
因此，采用分布式技术在尽可能短的时间内搜集尽可能多的网页，是研制高效搜索引擎的关键技术。
如何采用分布式方案达到设计目标是本文论述的主要内容。
为此我们提出了应用于搜索引擎的分布式系统结构和方法，并以WebGather1.2版为基础，利用其搜集的网页作为基础数据，编制分布式模拟系统验证我们的提出的系统结构、设计思想和方法。
2相关研究
国际上在搜索引擎中采用分布式方法的研究比较典型的是Harvest系统[4]。
它是1994年美国科罗拉多大学、南加州大学等在Internet信息资源发现服务领域开展的研究工作成果。
Harvest由若干子系统（Broker、Gatherer、Cache和Replicator）组成。
Gatherer从信息资源站点Provider（如FTP，WWW服务器）上提供的资源中收集索引信息（如关键词，作者，标题等）。
Broker从一个或多个Gatherer中取回索引信息、去掉重复的信息、存储下来并提供一个WWW的查询界面。
Replicator用于在Internet上复制Broker的信息。
Cache是为了减少网络流量、加快用户访问Internet信息资源的缓冲。
Harvest为我们提供了广域网资源信息收集、查询的分布式体系结构，有很多地方值得我们借鉴和利用。
然而Harvest系统是一个庞大复杂的系统，其算法复杂，开销比较大，对其推广使用造成了一定影响。
单就WWW上的信息收集而言，Harvest有如下方面不适合搜索引擎系统的设计目标。
●搜索引擎系统对收集信息的速度有一定要求，而Harvest的设计在这一方面没有考虑。
●Harvest的Gatherer在信息提供方的机器上运行时，会有较好的效果。
但是，不可能要求每个信息提供者都这样做。
●一个Gatherer在收集过程中发现的URL本身不能访问时就丢弃，但是别的Gatherer或许可以访问，所以Harvest系统没有能够解决交叉URL的利用问题。
●利用Harvest的Gatherer收集一定范围信息时，对收集缺乏有效的控制。
例如，要求遵守有关“WebRobot”约定，另外，还要对收集有一定的导向。
我们结合搜索引擎的特点，在现有WebGather1.2版的基础上提出了分布式搜集网页的结构和方法，试验表明这种方法效果很好，目前正应用于WebGather2.0版的开发，达到搜集尽中国所有网页的目的。
3分布式搜索引擎试验系统模型
2.1设计目标：
依据CERNET收费政策中定义的国内流量地址列表[5]，WebGather目标是搜集中国所有的网页。
根据中国互联网络发展状况统计报告，我国WWW站点数1997年10月约为1,500个，1998年7月约为3,700个，1999年1月约为5,300个，1999年7月约为9,906个，2000年1月约为15,153个，2000年7月约为27,289个[6]，预计2000年底约为40,000个。
根据Inktomi的统计资料表明10亿个不重复的网页大约分布在4,217,324台主机上[7]，则每台主机大约有238个不重复的网页，这个数字相对固定，所以WebGather需要搜集9，520,000左右的网页。
以10天为周期，仍然按照WebGather现有的速度进行搜集，则需要10台机器分布式协作，并且在单台性能没有降低的条件下才能够完成。
通过模拟试验检验分布式协同工作情况，单台负担任务的下降频度。
达到上述目标的同时，希望分布式系统具有如下特点。
●负载平衡。
●主控通讯量少。
●具有可扩展性，即随着主控的增加性能应有所提高。
●具有动态调度性，即运行过程中添加和删除主控。
2.2系统结构及主要设计思想
分布策略：
为叙述方便，以分布式系统表示整个分布式搜索引擎系统，以主控表示分布式系统中的每台工作站上运行的系统，以调度系统表示分布式系统中协调各个主控的模块，以交叉URL表示当前被搜索的网页中指向其他网页的超链接URL。
因为搜索引擎的瓶颈在于网络的速度和单台机器性能的限制，可以考虑如下的分布策略：
1．主控物理上分散在不同的地方，假如分布式系统包括四个主控，对于中国这个特定的国家，可以将他们分别放置在沈阳，北京，武汉和广州。
2．IP分段，通过哈希函数将每个URL均匀分配给各主控，每个主控负责一定范围内WWW主机网页的搜集。
当主控从其负责的WWW主机上取得的网页中存在交叉URL时，为了达到不丢失发现信息的目地，将交叉URL发送给负责该WWW主机的主控。
各主控通过哈希函数H（URL）=（DNS（URL中主机部分））MODn获得起始URL和后续的URL。
其中n为所有主控数，DNS（URL中主机部分）表示URL通过地址解析获得对应的IP，或者不解析域名直接变换URL字符串。
主控通讯策略：
主要包括以下两种：
1．环形通讯，邻近的主控之间建立连接，形成环状图。
交叉URL的传送可以选定顺时针或逆时针方向。
2．网状通讯，各主控制之间两两建立连接，形成一个交叉网状图。
交叉URL的传送可以直接传递。
从理论和实际应用的角度，解释以上两种策略
整个WWW可以看作是一张有向图G=（V,E）组成，V表示网页的URL，E表示两个网页之间存在的超链接URL，即一个网页中有另一个网页的URL。
对于图中任意两个顶点Vi，VjЄV，如果Vi到Vj有路径，则称Vi与Vj是连通的。
假设存在集合Vs，其中包含的URL称为种子URL，对于G中任意一个ViЄV，存在VsiЄVs，从Vsi到Vi有路径，则认为G是连通的。
所以WWW的搜集过程可以看作是从集合Vs出发，发现有向图G中所有V的过程。
为了尽快的发现有向图G中所有的V，应该采用多个搜集分系统从多个种子URL开始。
考虑到网络速度限制和集中式系统中单台机器性能的限制，应该采用分布式。
分布策略中的方法1的前提是对于分布在全国的WWW主机能够以优化的方式分配给各个主控，即根据每台WWW主机到各个主控的通讯速度来分配。
首先可以尽量多的收集WWW主机，由调度系统先分配给各个主控，分别测量时间后再统一分配，此时可以保证优化状态。
各主控开始工作后，如一台发现新的WWW主机，应该首先传递给调度系统，然后调度系统将主机的IP分发给各主控，各个主控分别测量到该WWW主机的速度，速度最快的主控获得对该WWW主机搜集网页的权利。
但是由于各个主控分布在不同的地方，会带来很多麻烦，如机器的调试、维护，后期数据分析处理等。
分布策略中的方法2虽然在搜集速度上较1稍慢，但系统运行时初始化简单，方法1有的缺点在方法2都不再是问题。
同时通过对负责分配URL的哈希函数的合理调整，使网页的搜集接近分布策略中的方法1带来的好处，而摒弃其带来的不便。
图1.分布式天网结构图
主控通讯策略1系统运行初始化简单，但是因为有多次传送交叉URL可能，存在通讯量大的缺点。
主控通讯策略2有明显优势，速度快，而且由于每两台主控之间都有连接，当有一台主控当机的情况下或增加新主控时，能够迅速的调整URL的分配。
2.3整体结构分析
综上所述，我们使用分布策略中的第2种方法与主控通讯策略中的第2种方法，整体结构如图1所示。
背景环绕的圈表示WWW，WebGatherServerRegistry（WSR）表示主控登记模块，存储分布式系统内所有登记主控的信息，包括各登记主控的IP和端口号。
当任一个主控的信息有所改变时，WSR负责发送新的主控信息给其他主控，便于建立连接和变更连接。
每个主控模块MainCtrl1，MainCtrl2，…MainCtrlN负责收集存储属于自己范围内的网页。
每一个搜集模块Gather1，Gather2，GatherN附属于相应的主控模块，负责接收所属主控发送的URL，抓取该URL指向的网页并传送回给所属主控。
各主控模块之间都建立有双向连接，可以全双工的工作。
当任一主控发现自己的搜集模块发回的网页中包含不属于自己的URL时，将此URL传送给它应属的主控去处理。
为减少通讯量，各主控之间只传送URL。
2.4试验中的关键技术及分析
1．存储大量URL数据的文件采用哈希表数据结构。
WebGather采用Informix数据库存储搜集来的网页，而在试验中，我们为了尝试各种提高效率的途径而使用哈希表数据结构生成文件来模拟数据库，存储大量URL。
这样做的确提高了多个主控在有限的系统资源下存取数据的效率，但缺点是一旦系统掉电，由于内存中的数据不能及时写回硬盘，导致文件中的数据存在不一致，需要大量的程序来更正错误信息。
从数据一致性的角度看，商业数据库是安全的，但如果能够保证系统安全运行（如运行时不掉电等），另外一种省钱又高效的存储办法是直接利用文件模拟数据库功能。
2．为保证试验环境一致性而采用集中解析域名方式。
由于互联网中的域名、网页的URL每天都可能由于人为等原因发生变化，如果模拟程序实时解析域名，在每组测试时，结果必然不会完全相同，而且当URL所对应的主机名不存在时，域名解析速度很慢，所以集中解析一次，产生解析好的数据库文件，以后每一组测试都采用同样的数据，使试验结果具有有可比性。
3．分布式系统中WSR模块的存在，使每个主控都能够保持当前系统中所有主控的最新信息，是系统动态可配置性的前提。
3试验结果
在2000年6月，我们在WebGather正常运行过程中，利用附加程序，产生分布式算法需要使用的模拟数据，对于每个网页保存了URL及其所包含的URL信息，大小为507M。
通过运行程序，产生一有761,129个网页的模拟WWW数据。
以此作为我们的实验对象。
程序运行的机器是一台PC机，配有双Intel550CPU，内存为512M，硬盘36G，运行的操作系统为Solaris8.0。
基于上述实验环境，我们分别试验了主控数n为2，4，8，16四种情况。
四组试验分四次完成，每次运行n个主控时，同时运行一个集中式主控。
每组运行时间至少为三天，获得了大量实验数据。
3.1负载平衡分析
为使系统负载平衡，我们采用哈希函数动态分配URL给每个主控进行搜集，负载平衡的效果可以通过分析每个主控每小时获得网页数获得。
通过分析每组分布式系统前10小时运行结果，可以知道系统的最终运行结果。
设定一组参照序列如表1所示。
如果上面四组试验数据好于参照序列，认为达到负载平衡要求。
其中t表示时间（小时），n表示主控数（个）。
t
表1.参照序列，假设主控数为2
n
1
2
3
4
5
6
7
8
9
10
1
2
4
6
8
10
12
14
16
18
20
2
3
6
9
12
15
18
21
24
27
30
对四组试验数据求方差可以知道它们的分散程度，根据分散程度可以知道负载平衡是否达到要求。
求方差用到下面两个公式。
解释上述两个公式：
X称为离散型随机变量（有限个或可数个值的随机变量），X的分布律为
。
X的可能取值是
。
X取相应各种值的概率是
。
公式
（1）称为X的均值，记为E（X）。
公式
（2）称为X的方差，记为D（X）。
由公式
（1），
（2），四组实验数据和表1，计算出表2。
t
表2.方差
n
1
2
3
4
5
6
7
8
9
10
2
0.000221
0.002907
0.001001
0.000619
0.000164
0.000124
4.28E-07
2.49E-05
5.47E-05
1.65E-05
4
0.001304
0.002361
0.002256
0.0015
0.001259
0.001861
0.002809
0.00269
0.002649
0.002274
8
0.000994
0.000563
0.000488
0.000399
0.000426
0.000334
0.00034
0.000595
0.000473
0.000463
16
0.00017
0.000251
0.000229
0.000178
0.000214
0.000227
0.000237
0.000241
0.000252
0.000291
参照
0.02
0.02
0.02
0.02
0.02
0.02
0.02
0.02
0.02
0.02
从表2的数据可以看出，在主控数分别为2，4，8，16情况下，方差值均小于参照方差值，说明各个主控搜集的网页数基本相等，因此搜索引擎分布式系统负载平衡达到预期目标。
3.2主控通讯量
试验中为保证试验环境一致性而采用集中解析域名方式，因此各个主控之间只有交叉URL的通讯量。
各主控之间传递的只是URL,每个URL长度不会超过128字节。
在今后的实际系统中，为提高域名解析的利用率，各主控已经解析出的主机名要互相传送，每个主控都维护一份当前系统已解析出的主机名与IP的对应表。
各个主控中的表要保持一致，这也构成主机通讯的一部分。
每个主机名与IP对应关系的存储长度不会超过147个字节，因此主控之间主控通讯量不大。
另外，为了实现系统的动态调度，需要在增减主控时，将现存主控中维护的相应表进行修改，为了保证表的一致性，需要在各个主控之间互相传递信息。
这种情况并不会经常出现，因此不会过多的增加主控通讯量（祥见下文3.4动态调度）。
考虑在上述后两种情况下的主控通讯中，一个副本要传送给多个主控，在实际系统的运行中我们采用多点传送（multicast）技术。
3.3可扩展性分析
X轴表示时间，时间单位=1小时，Y轴为搜集的网页数。
前10小时运行结果1如表3。
在图2所示中每一组结果由两根同样颜色的线表示，一根表示分布式系统的n个主控叠加结果，另一根表示与前者同时运行的集中式系统运行结果。
表3.当X=10（小时）时四组试验数据
分布系统的主控数N
集中式主控数
图中曲线颜色
两种方式搜取网页数目对比
集中式（个）
分布式（个）
加速率
2
1
黄
56199
96130
1.710529
4
1
紫
52712
177131
3.360354
8
1
青
51055
304854
5.97109
16
1
红
24763
290344
11.72491
图2.n个主控分布式系统及集中式系统随时间的变化
试验结果分析：
由于资源限制，分布式系统和集中式系统在同一台机器上同时运行。
但从图2中可以看出，集中式搜索系统（一个主控程序的系统）在资源分别被两个、四个、八个主控程序抢占时，性能基本不变，当有16个主控程序与之共享同样多的资源时，集中式系统的性能大大下降；当主控数在8以下时，随着主控数的增多，分布式系统的搜集效率就越高，直到主控程序达到16个时，由于系统资源不堪重负而和集中式一样性能下降。
图3.分布式系统效率
在分布式系统的效率图3中。
X轴代表主控数，Y轴表示n个主控协同工作搜集的网页数与单个集中式系统搜集的网页数的比（记为加速率）。
由图中可以看出加速率随着主控数的增加线性增加，因此分布式系统具有良好的可扩展性。
3.4动态调度性
WSR模块（详见图1说明）的存在，使系统动态可配置成为可能，保证了系统具有高可用性。
在保证系统负载平衡的条件下，我们考虑三种方法保证系统具有动态调度性。
●采用哈希函数动态调度URL。
●第二个方案是结合第一种方法，同时每个主控记录着一张WWW主机表，这张表在各个主控中是相同的，其中每一条记录包含一个WWW主机及其所对应的一个主控。
●采用逻辑上二级映射的方法。
首先用哈希函数映射URL到一张逻辑表上，然后将这张表上的相应部分映射到各个主控。
对以上三种方法通过对主控数增减1的情况分析，可以知道动态调度性的好坏，设WWW主机数为m，系统初始主控数为n，ni，nj表示系统中任意两个主控，加1情况记为n->n+1，减1情况记为n->n-1。
第一种方法，系统初始，每个主控负责的主机数为m/n，哈希函数对n取模，可以保证系统负载平衡。
在n->n+1情况下，哈希函数对n+1取模，此时可以保证系统负载平衡，但是由于模数改变使原先分配给主控ni负责的URL可能分配给nj负责，从而导致重复搜集一些已经搜集过的网页；在n->n-1情况下具有同样的缺陷。
第二种方法，为了克服第一种方法存在的缺陷。
每个主控需要附加存储两个表，主机表和本主控已经访问过的URL表，每个主控保存的主机表相同，已经访问过的URL表各自不
图4.URL逻辑二级映射（左：
初始状态；右：
主控增1状态）
同。
WWW主机数目有限，后加进的主控可能没有足够的WWW主机去进行搜集，为达到负载平衡的要求，需要其它主控迁移一部分主机及其所附带的已访问过URL的信息给新加入的主控。
此时URL经过哈希函数处理后，需要额外采取一个步骤：
在一个主控判断得到该URL属于自己负责后，应先根据主机表判断此URL对应主机是否已经被其他主机负责，如果没有，才应该自己处理；同理，在一个主控判断得到一个URL属于另一个主控（不妨设为A）负责后，应先根据主机表判断此URL对应主机是否已经被其他主机负责，如果没有，才将该URL传给A。
这种方法由于需要维护各主控之间主机表一致，主控数目变化时需要传送主机和附属URL信息，较第一种方法增加了主机之间的通讯量，我们决定将每个URL采用MD5算法，用16个字节表示。
第三种方法，采用逻辑二级映射的方法。
其中一级逻辑节点可以用数组形式存储（不妨设这个数组为A），每一个数组元素的下标即是它所代表的逻辑节点号，其中存储该逻辑节点对应的主控序号。
举例说明，设n=10，m=50,000为逻辑节点的数目，系统初始如图4左部所示：
其中A[1]到A[50,000]称为逻辑节点。
URL经过哈希函数处理后首先平均映射到逻辑节点上，再经过第二次映射将第1到第5,000的逻辑节点映射到1主控，第5,001到第10,000的逻辑节点映射到2主控，以此类推将逻辑节点平均分配到10个主控上。
当主控数增1，每个主控都要让出一部分控制的逻辑节点给新的主控，即对A作部分修改。
如图4右部所示，n11是由n1，n2，…，n10匀出部分组成，其逻辑数组中对应的项被置为11。
当主控数减1，减掉的主控要让出自己控制的主机，平均分配给其他主控，同样要修改逻辑数组中的值。
同第二中方法比较，这种方法多一次映射，同样每个主控需要保存自己访问过的URL，随主机迁移时需要转给新的主控。
但是这种方法可以不必存储主机表，每个主控中只要保存一份同样的数组A就可以了；这样就减少了主控之间的通讯量，并且系统配置改变后，不必象第二种方法一样在哈希函数处理后作附加的判断步骤。
现在，由于第一种方法实现简单，在模拟系统中我们采用这种方法。
第三种方法较前两种方法优越，在WebGather2.0版的开发中，我们采用第三种方法，保证系统具有良好的可动态配置性。
4结论
本文提出的分布式系统体系结构提供了一种搜集不断增长的网页的方法。
通过实际测试，搜索引擎分布式系统模型达到预期目标。
现在我们正在把这种体系结构及方法用于WebGather2.0版的开发，在实际系统中，我们暂时启动了两个主控，同样达到了预期的效果。
同时我们意识到分布式搜集系统的成功也带来了大量的后期工作：
如镜像网页的消除，后台的分布式索引和面向客户的分布式检索等。
5参考文献
[1]J.Liu,M.Lei,J.Wang,andB.Chen.
升级会员 