Board 版 (精华区)

发信人: WeskitKeeper (马甲守护神), 信区: Board
标  题: [范文]高级文件搜索引擎核心功能的实现技术
发信站: 哈工大紫丁香 (Sat Nov 12 10:25:27 2005), 转信

 

高级文件搜索引擎核心功能的实现技术

 

陈华 李晓明

北京大学计算机科学技术系 100871

 

摘要

            基于Web的FTP文件搜索引擎作为专门查找文件的工具越来越受到人们的关注。虽然Ftp搜索引擎技术上没有象WWW搜索引擎那样完善，但一些FTP搜索引擎已经提出了许多方便实用的新兴功能。这些功能的实现使得Ftp搜索引擎使用上越来越方便，查全率和查准率大大提高，促使了Ftp搜索引擎从专业性比较高的工具变成了大众化的获得网络文件资源的入口，为更有效的利用网络共享资源提供方便。本文参考北大“天网文件搜索引擎”的各种新兴功能实现策略，提出了从简单FTP搜索列擎改进成具有强大功能的高级文件搜索引擎的方法与技术要点。

关键字 Ftp搜索引擎  文件搜索 天网搜索 新兴功能

 

1 引言

在因特网上存在着、流动着各种各样的信息，例如email信息、BBS信息、OICQ信息、被HTTP服务器管理的HTML网页，还有被FTP服务器管理的各种类型的文件。后者是本文关心的对象，它们的典型代表是各种学术和技术文件、计算机软件、多媒体数据。多数FTP服务器都开辟有一个公共访问区，称为“匿名FTP”，对公众提供免费的文件信息服务。FTP搜索引擎的功能是搜集匿名FTP服务器提供的目录列表，对用户提供文件信息的查询服务。由于FTP搜索引擎是专门针对各种文件的，因而相对WWW搜索引擎，寻找软件、图像、电影和音乐等文件使用FTP搜索引擎将更加方便直接。

      北京大学网络与分布式系统实验室开发的“天网文件搜索引擎”，作为国内外Ftp搜索引擎中的佼佼者，从1999年最初的简陋的百万级FTP搜索引擎进化成今天的实现了许多新兴的方便而强大功能的千万级文件搜索引擎，促进了Ftp搜索引擎大众化的发展。今天，平均每日访问“天网文件搜索引擎”的人数已经超过40万人次，月访问量超过一千三百万人次。“天网文件搜索引擎”已经成为国内查找文件资源的最主要的门户网站。以下我们将介绍文件搜索引擎的各种新兴功能并详细解说这些新兴功能的实现策略。

 

2 文件搜索引擎的新兴功能

搜索引擎是否吸引用户，光看数据量是不够的，因为即使在同样的数据量下，各个搜索引擎可以实现的数据挖掘结果各有区别，而这个就很大程度上影响了用户找到需要的文件。

早期的Archie就已经提供了很多搜索功能和选项，后来的FTP搜索引擎很大程度上都是模仿了Archie,这些功能或选项包括：

a、支持*,?等与或操作符

b、支持多种查询模式，如是否大小写区分，是否子串匹配或精确查询等

c、支持文件大小、最后修改时间等过滤选项

d、支持多页面显示查询结果，常见的换页方式有索引式和下一页式

这些功能或选项是各种文件查询系统都应该支持的基本功能，我们称之为Ftp搜索引擎的基本功能选项。

当今的Ftp搜索引擎技术在发展，其功能也日新月异。我们考查许多Ftp搜索引擎，列出下列区别于基本功能选项的新功能，这些功能选项以其简单方便成为一些Ftp搜索引擎的亮点，我们称之为“新兴功能”：

            支持指定站点的站内文件查询

            结果排序，例如按时间、大小、站点等的排序

            查询结果中的再查询

            支持分类目录，例如提供许多常用的查询供用户选择

            支持查询系统的文件分类，指在一个扩展名集内的查询，如查电影

            提供FTP站点在线与否的状况显示

            支持在线的站点登记

 

“天网文件搜索引擎”很好地实现了上述大部分新兴功能，这些功能成为“天网文件搜索引擎”吸引用户的关键。在以下叙述中,我们将从一个最简陋的系统出发,来叙述如何实现一个强大功能的文件搜索引擎。

 

3  最简陋的文件搜索引擎

   最简陋的文件搜索引擎是指能够实现当输入一个查询串时,系统给出文件名符合字符串匹配的所有文件的信息。参考“天网文件搜索引擎”的在1999年最初的结构，我们给出如下系统原型:

1）  基本的系统数据：索引、属性表和文字信息表。

将搜集到的Ftp文件数据分解成三类：一是索引，用于字符串匹配，在用数据库实现的字符串匹配算法里，索引可能是不可见的；二是文件属性表，包含文件的全局唯一ID和文件的时间大小等结构化的各种属性；三是文字信息表如文件名和所在路径等非结构化的数据，在数据库实现的系统里，可能和文件属性表混合在一起。

2）输入输出界面

       包抬从Web页面的表单获得查询请求并转换成中心查询服务器可以认识的内部结构和以及输出结果页面。

3）字符串的匹配算法

      字符串的匹配是指如何获得文件名匹配查询字符串的文件列表的算法。在使用现成数据库实现的系统里，字符串匹配可以使用SQL语言的LIKE实现，如果是使用倒排索引的系统，可以采用倒排表的归并获得查询结果。具体算法请参考[1]或者其他相关搜索引擎技术文档。

4）中心查询服务器    

    协调多个并发查询请求,利用字符串匹配算法计算匹配结果，并把匹配中的文件的字符串信息和文件属性传给输出程序格式化成美观的WWW页面输出给用户。

 

4 字符串匹配的扩展－Cache的妙用与结果中再查询的实现策略

在最简陋的文件搜索引擎里，已经实现了字符串匹配的算法，在这里我们对其进行一些扩展以便加快搜索的速度并增加新的功能。由于字符串的匹配需要大量的时间，因而把字符串匹配的结果保存起来以便下次再使用是十分必要的。究竟是仅仅把字符串匹配的结果保存起来还是把限制了时间大小等查询选项以后的查询结果保存起来作为cache呢？我们认为由于大部分用户查询时都是使用没有任何限制条件的单纯文件名匹配，同时对于常见查询可能有的用户限制了条件，有的用户没有，如果把限制条件也作为Cache标签的一部分则会导致Cache过多同时命中率下降Cache的利用率也下降，因而仅仅把字符串匹配命中的结果保存起来是比较好的办法。

这样我们可以用用户的查询串作为标签，把字符串匹配的结果索引表保存起来。在“天网文件搜索引擎”里，我们使用文件来实现Cache，把用户的查询串转换成16进制表示的字符串作为文件名（因为查询串中可能存在各种非法的不能做为文件名的字符），把命中的索引表保存在Cache文件里面。另外，启动一个单独的进程每隔十分钟检测一次所有Cache的最后访问时间，如果30分钟内某个Cache文件没有被访问，则说明这个Cache已经没有存在价值，可以删除。

使用了Cache后，对于新来的查询，就没有必要都重新做一次字符串的匹配，首先要做的就是查看Cache是否命中，如果命中，直接返回Cache中的已知结果索引表，否则再按原来的字符串匹配算法进行匹配。

当使用了Cache后，实现结果中再查询就十分简便了。结果中再查询的功能在很多WWW搜索引擎都有实现，而在Ftp搜索引擎里实现这个功能的只有北大“天网文件搜索引擎”。我们实现结果中再查询主要就是依靠父查询中的Cache。首先在查询结果的WWW页面里，如果当前查询结果数不为0，则生成一个“结果中再查询”的表单，这个表单把当前查询作为结果中查询的父查询，把一个输入框的内容作为子查询。当用户提交这个“结果中查询”的表单后，服务器首先把父查询的查询串去命中Cache，如果没有命中，说明父查询结果为0，则直接返回空查询结果，否则提取父查询结果，并计算子查询的结果，将两个查询结果做并操作（就是合并两个结果索引表中ID相同的项），生成了结果中再查询的结果，把这个结果以“子查询字符串＋父查询字符串”作为标签保持在Cache里，以便下次使用。

支持Cache和结果中再查询的字符串匹配逻辑如下：

 

        
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

图【1】使用Cache并支持结果中再查询的字符串匹配逻辑

 

 

5、属性过滤的扩展－实现文件分类和指定站点的站内查询

      在传统的Ftp搜索引擎里，就支持各种属性过滤，比如文件大小和文件最后修改时间的过滤。属性过滤需要对每个文件名匹配中查询字符串的文件比较其文件属性是否符合查询要求。把属性过滤的功能进一步发展，我们就可以实现文件分类与站内查询。

      每个文件都有很多属性，我们把文件名和它所在的路径算作字符串信息而不是文件属性，因为文件名和路径信息等非结构化的数据在搜索引擎里因为索引的存在实际匹配过程中并没有使用到，如果作为文件属性与时间大小等结构化大小确定的属性混合放在一起会导致文件属性表所占空间巨大，扫描整个文件属性表时间就会下降，从而导致搜索速度的下降。而如果文件属性表仅仅包含一些确定长度的结构化短数据，则计算上更为简洁，甚至可以把整个文件属性表放到内存里以加快搜索速度。在“天网文件搜索引擎”里，我们在文件属性表里保存以下信息：文件大小、文件的最后修改时间、文件所在站点的IP、文件名（不包含扩展名）的长度、文件分类的编号、该文件的文字信息所在地址。

为什么要使用文件分类呢？这是我们对用户查询行为的一个分析结果。我们统计了FTP搜索引擎的84万次用户输入的查询串，得到查询串类型分布图图【2】。图中 I 表示仅仅输入关键字查询的类型比例，II 表示仅仅输入扩展名查询的类型比例，III表示输入了全文件名类型比例。

图【2】查询匹配串的类型分布

由图【2】可见，大部分的用户查询时都是仅仅输入一个关键字，而无法提供具体的扩展名。对于普通用户而言，扩展名是一个比较难理解的东西，例如电影文件，可能的扩展名为“.rm”、“.mpeg”、“.dat” 等等，为了查找电影而要求用户提供扩展名会使得普通用户对查询系统望而却步。但是，用户不提供扩展名而在整个数据库里查询就有很多不符合用户需要的查询结果，比如查询某个程序的下载地址确得到了该程序的源代码下载地址，从而使得查准率不高。因而普通用户查询文件的时候他（她）可能需要的是某种类型的文件，而不是特定扩展名的文件，例如用户可能希望查询到音乐文件，但他（她）并没有限定是“.mp3”文件还是“.au”文件。即使用户知道扩展名的情况下，为了查到一首歌的所有的下载地址，他（她）必须为这首歌指定多个扩展名，否则就可能漏掉许多的下载地址，而这往往很麻烦，实现上也不容易。

为了解决记忆扩展名对普通用户的负担以及实现在一个大类别里的文件查询，可以将所有文件分为几种简单的文件格式类型，用户查询时只需指定他需要的文件格式类型而不用指定具体的扩展名就可查询。为了进行文件按扩展名分类，建立了文件类型库。它对每类文件给于一个编号以及属于该类型的所有扩展名。在“天网文件搜索引擎”里，各分类的扩展名包括：

1)图象：jpg,  gif,  bmp,  jpeg,  pcx,  tif,  tiff,  wmf,  psd,  tga,  pic,  png,  pcd,  dib,  rle,  iff,  lbm,  ilbm,  jpe,  jif,  dcx,  ico

2)声音：mp3,  wav,  cda,  mid,  au,  mp1,  m3u,  mjf,  as,  voc,  xm,  s3m,  stm,  mod,  dsm,  far, ult, mtm, mp2, mpa, mpga, 669, aac, mp4, vqf, pls, xpl, lrc, rmi, midi, snd, aif, aifc, wma, wax, aiff, rms

3)视频：mpeg, mpg, avi, rm, swf, ram, rmm, ra, rmj, vob, asf, asx, wvx, wmv, wm, m1v, wmp, ivf, smi, mpv2, mp2v, smil, rp, mpv, ssm, rv, mpe, rf, rt

4)压缩：zip, arj, gz, tar, tgz, cab, z, arc, b64, bhx, hqx, lzh, mim, taz, tz, uu, uue, xxe

5)文档：txt, doc, htm, html, ppt, exl, mdb, asp, asa, php, js, rtf, wri

6)程序：exe, com, bat, dll, class, out, ocx

7)源代码：cpp, c, h, hpp, pas, bas, java, asm, perl, inc, cxx, tli, tlh, hxx, inl, def, odl, idl

100)目录。目录类型由文件条目属性决定。

0)      其它。所有不在上述范围内的文件归类到其它中。

当我们建立文件属性表时，如果非目录，则提取文件的扩展名，用二分法在所有有编号的扩展名里查找，如果找到返回对应编号，否则返回0。文件分类示意图如图【3】

 

图【3】文件分类示意图

 

      完成文件分类后，就可以进行按类别的文件查询。由于文件类别只是作为文件属性的一项，我们可以把文件类别过滤作为普通的属性过滤来处理。同理，由于文件所在站点IP也作为文件的属性，因而也把指定站点的站内文件搜索作为普通的属性过滤来处理，只要文件属性中的站点IP与用户要求的站点IP相同则属性过滤通过。

但是，分析Ftp搜索引擎的查询日志，我们发现文件类别过滤的使用率远远高于时间和大小过滤，而且当站内查询被其他站点引用之后站内查询的使用率也十分之高，对于每个查询如果都对所有的属性进行过滤将对搜索速度影响很大。在“天网文件搜索引擎”里，我们区分两种搜索模式：简单搜索模式和复杂搜索模式。在简单搜索模式里面，属性过滤仅仅过滤文件类型和站点IP，而在复杂搜索模式里，属性过滤就包含了文件大小，文件最后修改时间，精确匹配等等比较少用的操作。

      另外，属性过滤应该把需要输出给用户的结果单独过滤出来，因为一般查询结果只显示几十项，并用分页来处理大量的查询结果。这个需要起始显示结果号和当前页面的最大显示结果项数。这样，经过属性过滤后的查询结果就可以直接输出，而且由于只剩下可以显示的几十个项，因而输出速度大大加快了。经过扩展后的属性过滤流程如下：

 

                                        
                
                
        
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

图【4】一个结果项的属性过滤和所有字串匹配结果的属性过滤

 

6    查询结果的多种排序方式与优化

结果的排序是十分重要的，比如找电影，可能需要文件大小最大的，找软件，可能需要最新版本的。许多Ftp搜索引擎都实现了结果排序，比如文件大小和文件最后修改时间以及站点IP的排序。“天网文件搜索引擎”还实现了独具特色的相关度排序，这样短查询也可以十分精确地找到查询结果。另外“天网文件搜索引擎”的排序是放在结果页面里面的，用户可以象切换频道一样随意切换排序方式，十分方便。

排序算法可以采用各种现成的排序算法，如快速排序、堆排序等等，堆排序对任何数据都有lg(n)的速度，因而是比较合适的排序算法。把排序算法加一个参数，以便用同一个算法可以对各个不同属性进行排序。

在文件搜索里面，相关度的概念与WWW搜索有所区别，我们把结果的文件名与用户查询串的相似度作为相关度，由于查询结果肯定符合了查询串，因而查询结果里面文件名越短相关度就越高。考虑大部分用户查询时只输入关键字而不输入扩展名，我们在计算文件名长度时只计算排除了扩展名后的长度。这样用户输入一个短的查询串，可以在不考虑扩展名的情况下进行相关度的排序，十分方便查询短文件名的文件。

在上述的属性过滤策略里，由于我们对于属性过滤不成功的结果项直接抛弃，因而排序的工作就必须放在属性过滤之前。

在实现上述扩展后，对于一个查询，它的流程如图【5】：

        
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

图【5】 服务器流程图

 

7．  结果输出的智能换页方式

由于大部分情况下搜索结果在一个页面内显示不了，因而要采用换页机制。即CGI程序向服务器提供起始显示结果号和每页的最大显示项数，由服务器过滤，将可显示的结果信息返回给CGI程序，这样可以大大减少网络流量，降低运算代价。CGI程序由起始显示结果号和服务器给出的结果总数生成换页链接。在北大“天网文件搜索引擎”里，我们采用了一种智能的换页方案：将当前的起始显示项号对应的链接放在链接表的中间，以最大显示项数为间距生成有限个向后和向前的链接。这样用户可以保持鼠标不动的情况下，以相同的间距向前或向后翻页。如图6所示为最大显示数为20时的一种情况：

 

 

 0  20   50   70   90   110  130  150  170  190  210  230  250  270  290  310 

50  70   90   110  130  150  170  190  210  230  250  270  290  310  330  350

90  110  130  150  170  190  210  230  250  270  290  310  330  350  370  390

                                                       ▲鼠标不动,每次跳过40个

图【6】一种智能的换页方案

 

为了使得界面更为灵活，将算法和界面分离的模板技术是十分方便有用的。模板技术的使用，使得多语言版本实现成为可能，也为以后可能的应用服务提供基础。简单的模板可以采用Html语法里的注释作为模板插入点，<!--  -->这个注释是不可见的，因而很方便编辑模板。当CGI要显示结果的时候，它逐行读入模板文件，如果找到特定注释，则用CGI里的特定信息字串代替它，否则直接输出。

在结果页面使用模板技术后，搜索引擎就可以提供多语言的版本了。一方面，静态页面比如查询输入页面可以用手工的方法制作各个语言版本的页面，另一方面，查询结果显示的页面，制作特定语言的模板即可。但CGI也许要做些改动，因为“结果中再查询”的表单和翻页索引里可能存在语言相关的字符。目前“天网文件搜索引擎”提供简体中文和英文两个语言版本，并在CGI里已经实现里繁体中文的支持。

 

8.              分布式搜索引擎与Ftp搜索引擎到通用文件搜索引擎的进化

当搜索引擎搜集的站点数目越来越大，数据量也同步很大时，单部PC机完成所有的搜集建库工作就显得比较艰辛。一方面内存成为瓶颈，因为按目前的情况，一千万的文件条目需要700M的空间存放索引和数百兆的空间存放文件属性，而属性由于基本每个查询都需要过滤扫描，因而一般放在内存里，由于搜索引擎的搜集范围的扩大，所需内存马上就会超过数千兆，这是普通服务器所难于承受的。另一方面，站点数目的增多使得重新刷新一次数据库所需的时间增大，如果都放在一台服务器上刷新周期太长，不能更快的体现ftp站点的变化。所以使用多个服务器进行分布搜集数据和分布搜索是未来发展得方向。

“天网文件搜索引擎”支持了分布搜集和分布搜索，这为系统的未来扩展垫下基础。在上述Ftp搜索引擎原有结构上实现多服务器的分布数据搜集和分布搜索并不难，因为在系统的Server/Client结构为系统的分布提供基础，CGI与服务器之间用标准的TCP/IP协议通讯使得系统甚至可以分布在不同的操作系统平台上。将多个独立的搜集服务器分别搜集不同网段的ftp站点并为这些站点数据的搜索提供独立的查询服务，令CGI分别连接到各个查询服务器，将各个服务器得搜索结果合并后输出给用户。这样，我们并没有改动服务器端的任何代码，在服务器的所作改动就是限制其站点列表数据库，使得各个服务器的站点列表数据库没有交集。而在CGI客户端，通过系统配置可以知道各个服务器的地址，CGI将搜索请求发给各个服务器，计算总的结果数，并确定可以显示的结果范围，最后输出给用户。在用户看来，多个服务器的存在一点没有改变查询的过程与结果，也就是说，系统的分布式是对用户透明的。

在实现分布式支持之后，搜索引擎就可以做进一步扩展。

            将搜集数据与查询服务分离：

当查询服务请求量很大时，由于搜集数据耗费很大的网络带宽，往往导致查询服务的速度下降，因而应该分离搜集数据与查询服务。图【7】a是“天网文件搜索引擎”早期为了处理大用户量请求和搜集范围扩大的冲突而采用的系统分布方案：

        
 

 

 

 

 

图【7】a分离数据搜集与查询服务

 

            多个查询服务器实现负载均衡

当用户量十分大的时候，单个查询服务器就显得繁忙，由于搜索引擎数据的更新频率不是很高（最多一天更新一次就足够了），因而可以考虑配置多个查询服务器来均衡查询的负载，而使用单一数据搜集服务器来为两个查询服务器更新数据。图【7】b是“天网文件搜索引擎”在用户量超过每日30万且服务器配置比较低的情况下的系统分布方案：

 

 

        
 

 

 

 

 

 

 

 

 

 

 

 

图【7】b多个查询服务器负载均衡

 

            Ftp搜索引擎到通用文件搜索引擎的进化

由于WWW网页上共享的软件越来越多，许多非专业用户根本就不知道FTP是什么，他们下载软件都是直接到Web网站上点击下载地址直接下载。如果能够把WWW上的文件URL也融合到Ftp搜索引擎里，则用户可以找到的资源将增加许多，而且由于WWW网站的稳定性一般比FTP网站高，软件下载的成功率也大大增加。如果已经有了大量的WWW文件URL，转换成Ftp搜索引擎本身的系统数据并不是很难，只需要对每个URL用HTTP的HEAD请求获得它的最后修改时间和文件大小等属性就可以如同处理FTP文件一样为它建立索引，提供查询了。如果在查询服务器端不直接输出协议标志字串如“http”、“ftp”，仅仅输出查询命中文件的路径和属性，则可以在CGI端依靠配置文件来判断一个查询服务器提供的是“http”文件还是“ftp”文件然后生成正确的下载链接。这样就可以在不修改查询服务器任何代码的情况下实现了多种协议文件的支持。北京大学“天网搜索”包含了WWW搜索引擎和FTP搜索引擎，因此我们从WWW搜索引擎的数据里提取我们感兴趣的文件链接（排除html文件和部分图片，因为WWW里面图片和网页太多，而仅仅从文件名基本上无法分析得到可以用的信息），转换成FTP搜索引擎里面的文件数据格式，并建立索引。这样，FTP搜索引擎就进化成为通用的文件搜索引擎，而不仅仅是FTP的文件搜索了。图【7】c是北大“天网文件搜索引擎”（从“天网文件搜索引擎”进化而来）同时提供国内FTP文件查询、国外FTP文件查询、国内WWW文件查询后的系统分布方案（由于国外FTP文件和国内WWW文件的更新比较慢，所以没有提供专门的数据搜集服务器，只是一次性搜集数据建库然后提供查询服务）。在这个方案里，由于查询的入口没有改变，在用户看来，使用查询的方式并没有任何变化，变化的仅仅是多了许多可以用的查询结果。

 

        
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

图【7】c包含国外FTP文件和国内WWW文件后的文件搜索引擎

 

 

9.   外挂的站点在线状况分析系统

      由于Ftp站点具有一个特性就是不稳定，如何使得用户在查询的时候就知道站点是否是可以连接的呢？还是把无法连接的查询结果直接去掉不显示给用户呢？ 由于站点是否可以连接具有地域相关性和时间相关性，就是从搜索引擎的角度看该站点可能无法登陆但是从用户的角度却可能可以登陆，因而如果把从搜索引擎角度看到的无法连接的查询结果全部去掉是不合理的。

      为了保证搜索引擎的速度，不可能在用户查询的时候实时的去检测查询结果所在站点是否可以连接，因而可以考虑一个外挂的检测系统来产生一个站点是否在线的列表。由于站点是否在线只有“是”与“否”两种状态，因而站点是否在线的列表可以只是不在线站点的列表或者在线站点的列表。由于判断站点是否在线是不精确的、存在地域相关和时间相关性，因而在“天网文件搜索引擎”里，我们采用了不在线站点列表，即我们可以给出站点可能不在线信息，但是无法保证站点对用户而言是在线的，因为可能搜索引擎可以连接，但用户可能无法连接。

      外挂的在线状况分析系统获得系统已经建有索引的所有站点地址后，每隔5分钟扫描所有站点一次，并记录站点是否可以连接。查询服务器每隔10分钟连接到外挂的已经按IP排序的在线状况分析系统，获得不在线站点列表。当查询服务器输出查询结果是，对于每个结果从其属性里获得它的IP，并用二分法在“不在线站点列表”里查找，如果找到，则显示连接可能不通。由于查询结果经常是同一站点的堆在一起，因而可以对在判断某个IP是否在线上加一个Cache，如果IP和上次判断的IP相同，则使用上次判断的站点是否在线状态，这样可以减少使用二分法扫描“不在线站点列表”的次数，加快了搜索速度。

 

10．外挂的分类目录列表

没有搜索常识的菜鸟用户，他们经常使用糟糕的无法返回所需信息的搜索请求，但是他们占了网民的绝大多数，这种情况永远不会改变。经过对用户查询的日志分析，可以得到的结论是大部分用户都是：我不能表达我想要找什么，但是当我看到它时我就会知道我找的就是它("I don't know what I want, but I'll know when I find it")。搜索引擎如果只提供一个输入框和一大堆复杂的表单对于普通用户而言可能会不知所措。由于FTP搜索引擎具有一个特性就是用户搜索的关键词范围比较有限，在我们统计的9万多个查询中，只有5000多个查询是互不相同的。如果把比较流行的查询做成快捷方式并进行分类，用户一点击就可以得到该软件的查询结果，则用户到搜索引擎要做的就不再是指明自己要什么，而是搜索引擎告诉他（她）可以要什么。

当搜索引擎具有了文件分类功能之后，建立查询的分类目录系统就可行了。这是因为在分类目录里，充分利用文件分类能力，分类目录对应的查询的查询结果可以十分准确而全面。在每个分类里面，保存常用的查询的快捷方式，用户只需点击快捷方式就可以获得查询结果。

当快捷方式增多的时候，如果找到一个快捷方式将十分麻烦。制定一个两级的查询分类类别是比较恰当的，第一级分类与文件格式分类的类别相似，例如：电影、音乐、程序、文档等；第二级分类为该类别内的按内容的分类，比如电影下有动作、爱情类型等，程序下有系统、压缩、游戏等。这些按内容的分类都无法用程序的方法简单实现，只能用手工的方式添加各个分类里的快捷方式。建立起这个两级的快捷方式系统后，由用户和管理员在每个类别里添加查询频率比较高的查询作为快捷方式。利用CGI程序记录每个快捷方式的点击次数，在显示一个类别的所有快捷方式条目时按点击数排序输出，则用户可以知道当前这个类别的软件排行。将部分类别下的快捷方式默认为一个特定的文件格式，比如电影类别的快捷方式默认为视频文件格式类型，这样就可以自动的将快捷方式与文件分类功能结合，确保快捷方式的精确性。

“天网文件搜索引擎”建立分类目录以后，用户使用分类目录进行查询已经占了所有查询中的一半，由于分类目录的快捷方式对应的查询比较固定，Cache的利用率大大增强，查询速度也加快许多。在Google的分类目录World > Chinese Simplified > 计算机 > 互联网络 > 搜寻 > 分类目录 里，天网文件搜索以其特有的文件分类目录功能排在国内著名的“新浪搜索”和“百渡搜索”之前，这也是“天网文件搜索引擎”最为吸引用户的一个方面。

 

11 包含外挂系统的高级文件搜索引擎系统结构

 

 

           

        
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

12 总结

   文件搜索引擎作为越来越受重视的网络资源门户，其技术发展也日新月异，“天网文件搜索引擎”实现了以上新兴的强大方便的功能，为天网用户提供了更好的服务。“天网文件搜索引擎”的强大功能创意是来源广大天网用户的建议与反馈，并得到了北京大学计算机系网络与分布式系统研究室各位老师与同学的关心与支持，在此一并表示感谢。

 

主要作者简介：

陈华  1978年出生，籍贯广东，正在北京大学计算机科学技术系攻读硕士学位

李晓明 工作于北大计算机系，教授，博导，计算机系系主任

参考文献：

[1] 陈华,罗昶,段晖,薛明,王建勇。基于Web的百万级FTP搜索引擎的设计与实现。发表于《计算机应用》2000年第9期

[2 ] 雷鸣，刘建国，王建勇，陈葆珏。一种基于词典的搜索引擎系统动态更新模型。已被《计算机研究与发展》录用。

[3] Jianguo Liu, Ming Lei, Jianyong Wang, and Baojue Chen. Digging for gold on the Web: Experience with the WebGather. Accepted by the HPC/Asia 2000 Conference., IEEE Computer Society Press, May 2000, Beijing, P.R.China.

 

--

※ 修改:·WeskitKeeper 于 Nov 12 10:25:38 修改本文·[FROM: 202.118.236.206]
※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: 202.118.236.206]