分布式信息检索

本科毕业设计(论文)

 

 

题目	分布式信息检索

学生姓名	张凌云	学　号	03111638
教学院系	计算机科学学院
专业年级	软件工程03级
指导教师	豆连军	职　称	工程师
单　　位	北京中和天地信息技术有限公司
辅导教师	李建	职  称	教授
单　　位	西南石油大学计算机科学学院

 

 

完成日期

2007

年

06

月

17

日

Southwest Petroleum University

Graduate Design (Thesis) for

Bachelor’s Degree

 

 

Title	Distributed Information Retrieval

 

Name	Zhang Lingyun			No.		03111638
Coll. (or Dept.)		College of Computer Science
Major&Grade		Software Engineering , 2003
Supervisor	Dou Lianjun		Title		Engineer
Unit	ZHTD  InfoTech  Company  Ltd
Tutor	Li Jian		Title		Professor
Unit	College of Computer Science

 

June 17, 2007

 

摘  要

信息产业的飞速发展使得信息日益数字化。现在互联网上大概有一百亿张网页，并且每天还有很多新的网页出现。为了人们查找信息的方便，各种各样的搜索引擎应运而生，它们的核心问题都是如何在可以接受的时间范围内在用户需求和海量的数字化文档之间构造一个合理的、有效的匹配，也就是信息定位问题。搜索引擎的集中式体系结构使得面对大信息量时不堪重负。传统的搜索引擎的工作方式基本上是集中式的，它们将搜集来的数据相对集中地存放在某处，在用户进行查询时，由系统对这些信息统一进行检索，并将检索结果返回给用户。随着网络信息的膨胀，系统维护的数据库变得非常庞大，对这样的数据库进行查询操作非常费时，从而造成性能瓶颈。采用分布式的体系结构，以便提高速度，减轻负载，并使系统易于扩展。本论文就要研究，分布式信息检索的相关理论，通过对分布式中会遇到的问题和相应的解决方法，分布式文件系统,和检索系统的研究，最终能够提供一个比较完整的，稳定高效的解决方案。

关键词：分布式；信息检索；分布式文件系统

Abstract

The development of Information industry number information day by day。In Internet，there are about 10 billion pages，And new pages appear every。In order to facilitate people to search information，a various of Search Engine appear，the core issue which they attend is how to make user find information in a great deal of number document in a reasonable amount of time。Centrality structure of Search Engine in face of a great deal of information make weaker。Working of traditional Search Engine is Centrality，they store centralized data they collect in a place。When user search information，System of Search Engine search data，and return result back to user。 Following information of Web becomes larger，the database which Search Engine maintains grows very huge，and searching in this database will spend a lot of time。Adoption of distributed system can speed up，reduce workload，scale system easily。In this paper，I will research the theory of Distributed Information Retrieval，and make a abstract。

Keywords：Distributed；Information Retrieval；Distributed File System

目 录

1 绪论... 1

1.1 设计的目的和意义... 1

1.2 分布式系统定义... 1

1.3 分布式系统流行的原因... 1

1.4 分布式存在的问题... 1

1.5 信息检索采用分布式的好处... 2

2 分布式信息检索系统初步研究... 3

2.1 简单模型... 3

2.1.1 体系结构... 3

2.1.2 具体结构: 3

2.1.3 模型缺陷... 4

2.1.4 缺陷改进... 4

3 模型的改进... 6

3.1 性能瓶颈... 6

3.1.1 代理服务器瓶颈及解决方案... 6

3.1.2 搜索服务器瓶颈及解决方案... 8

3.2 机器失效... 10

3.2.1 搜索服务器失效及解决方案... 10

3.2.2 代理服务器失效及解决方案... 12

3.3 数据的相关性和结果数量限制... 15

4 分布式信息检索系统模型设计... 17

4.1 分布式文件系统(DFS) 17

4.2 分布式文件系统的特点... 17

4.3 分布式文件系统的体系结构... 18

4.4 系统模型设计... 20

4.4.1 搜索服务设计... 20

4.4.2 代理服务设计... 21

4.4.3 综合设计... 22

5 模型实现... 24

5.1 搜索程序简介... 24

5.2 实现步骤... 25

5.2.1 开发环境... 25

5.2.2 用户接口实现... 25

5.2.3 代理服务器实现... 26

5.2.4 搜索服务器实现... 27

5.2.5 数据索引实现... 28

6 测试... 29

6.1 索引和搜索... 29

6.2 执行过程分析... 31

7 结论... 33

致谢... 34

参考文献... 35

1 绪论

1.1 设计的目的和意义

本文重在理解分布式信息检索的主要组成部分，及各部分的组织结构和相关功能。通过对分布式信息检索系统的深入研究，提供一个比较完整的，稳定高效的分布式信息检索系统解决方案，为以后独立开发一个商用的系统打下基础。

1.2 分布式系统定义

分布式系统(Distributed System)：指通过网络互连，可协作执行某个任务的独立计算机集合。

1.3 分布式系统流行的原因

1.低廉的计算机价格和网络访问的可用性。今天的个人计算机比早期的大型计算机具有更出众的计算能力，体积和价格不断下降。再加上Internet连接越来越普及且价格低廉，大量互连计算机为分布式计算创建了一个理想环境。

2.资源共享。分布式计算体系反映了计算结构的现代组织形成。每个组织在面向网络提供共享资源的同时，独立维护本地组织内的计算机和资源。采用分布式计算，组织可非常有效地汇集资源。

3.可伸缩性。在单机计算中，可用资源受限于单台计算机的能力。相比而言，分布式计算有良好的伸缩性，对资源需要的增加可通过提供额外资源来有效解决。

4.容错性。由于可以通过资源复制(或镜像)维持故障情形下的资源可用性，因此，与单机计算相比，分布式计算提供了容错功能。例如，可将数据库备份拷贝维护到网络的不同系统上，以便在一个系统出现故障时，还有其他拷贝可以访问，从而避免服务瘫痪。尽管不可能构建一个能在故障面前提供完全可靠服务的分布式系统，但在设计和实现系统时最大化系统的容错能力，是开发者的职责。

1.4 分布式存在的问题

1.多点故障。分布式计算存在多点故障情形。由于涉及多个计算机，且都依赖于网络进行通信，因此一台或多台计算机的故障，或一条或多条网络链路的故障，都会导致分布式系统出现问题.

2.安全考虑。分布式系统为非授权用户的攻击提供了更多机会。在集中式系统中，所有计算机和资源通常都只受一个管理者控制，而分布式系统的非集中式管理机制包含许多独立组织。分散式管理使安全策略的实现和增强变得更为困难；因此，分布式计算在安全攻击和非授权访问防护方面较为脆弱，并且可能会非常不幸地影响到系统内的所有参与者。

1.5 信息检索采用分布式的好处    

1.可以对大数据量进行检索，突破了计算机容量的限制。

2.提高了检索的速度。

3.降低由于机器失败，造成对服务的影响。

下文将开始分布式信息检索系统的研究。首先从最简单的模型开始。

2 分布式信息检索系统初步研究

2.1 简单模型

分布式信息检索系统中最简单的模型，如下图2－1所示。

2.1.1 体系结构

1.用户接口。用户通过用户接口输入query，然后用户接口把query传输给搜索服务器，最后搜索服务器把result返回给用户接口。由用户接口把结果呈现给用户。

2.搜索服务器。搜索服务器接收用户接口发过来的query，然后进行检索，检索完毕，把result返回给用户接口。

 

图2-1 一个简单的分布式信息检索模型

2.1.2 具体结构:

这个结构可以用B/S或，C/S结构实现。

如果是B/S结构，具体实现如下：

1.用户接口是一张网页。例如下图2－2所示。通过这个网页，用户输入query，然后网页通过http协议，把query传输到搜索服务器，最后又通过http协议把result返回.

2.搜索服务器只需要提供一个对外服务的接口即可。这个接口实现http协议，接受query，然后调用检索程序，最终把result返回。

如果是C/S结构，原理和上面相同，只是用的具体的技术有些差别。这里就不详细描述了。

图2-2 网页实现一个用户接口

2.1.3 模型缺陷

用户接口要知道所有的搜索服务器的地址。这样就会造成如果添加搜索服务器的时候，必须同时更新用户接口中关于搜索服务器地址的记录。如果是B/S结构，修改起来比较容易，但如果是C/S结构，修改起来将十分困难。这将会造成数据不一致的情况发生。

2.1.4 缺陷改进

针对上述的缺陷，对模型进行改进。改进后的结构如下图2－3所示。

在用户接口和搜索服务器之间加入一个代理服务器。这样，用户接口就只和代理服务器交互。以后对搜索服务器进行更新的时候，只需要更新代理服务器就可以了。其他的过程和前面介绍的相同

图2－3改进后的模型

虽然这个改进后的模型非常简单，但在一般的应用中也足够了。不过，如果继续研究下去，就会发现模型有很多的改进之处

3 模型的改进

3.1 性能瓶颈

瓶颈有可能在两个地方出现。一个在代理服务器。另一个在搜索服务器。

3.1.1 代理服务器瓶颈及解决方案

代理服务器是对外的接口，如果同时请求的用户很多就会出现性能瓶颈。

现在假设，代理服务器把所有收到的请求放到一个队列中，代理服务器每次从队列中取一个请求，进行处理，处理结束并返回结果后，再取下一个请求。

如果有100个不同的用户请求同时到达，每个请求处理的时间为1秒种。这样第一个用户收到结果所用的时间为1秒。第二个用户所用的时间为2秒。第100个用户就为100秒了。这样的处理时间对比较靠后的用户来说是无法忍受的。

改进的方法有，优化代理服务器的程序，让用户的请求并行处理，来减少等待时间。如果程序上的优化完毕之后，还有性能的问题。那么再对这个模型进行改进。改进后的模型如下图3－1所示。

图3－1代理服务器改进后的模型

在这个模型中引入了两种类型的代理服务器。分别叫做一型代理服务器，和二型代理服务器。一型代理服务器的职责是接受用户接口的查询，返回一个二型代理服务器的地址。二型代理服务器和上面开始介绍的代理服务器功能相同，这里就不详细描述了。

下面解释一下图中的步骤：

1.二型代理服务器向一型代理服务器发送一个消息，告诉一型代理服务器，它现在开始对外提供服务了。这个消息在二型代理服务器刚刚加入进来的时候发送给一型代理服务器，并在二型代理服务器提供服务的生命周期中，周期性的发送给一型代理服务器，以告诉一型服务器，自己还在提供服务。

2.一型代理服务周期性向二型代理服务器发送查询请求。一个是查看二型代理服务器是否还在工作。二是根据查询的反馈，来判断这个二型代理服务器工作是否繁忙。

3.用户接口向一型代理服务器发送查询请求，来请求一个二型代理服务器的地址。

4.一型代理服务器返回一个可以的二型代理服务器地址给用户接口。

5.用户接口把query发送给二型代理服务器。

6.二型代理服务器把结果返回给用户接口。

利用这个模型，可以通过增加二型代理服务器的方式，来提高一个请求周期的速度。并且这也可以减少由于带宽的原因，而造成的堵塞。

机器间通信方式的比较

机器之间的通信，分为面向连接的通信和无连接的通信。下表3－1比较了面向连接通信方式和无连接通信方式。

                            表3－1面向连接的通信和无连接的通信的比较

	面向连接	无连接
地址	建立连接时定义,不需要在随后的每个操作(发送或接收)重新定义	在每个操作中都必须定义
连接开销	存在连接建立开销	不适用
地址解析开销	每个操作都不需要地址解析开销	在每个操作中都存在解析开销
数据传输顺序	抽象连接允许IPC机制维护数据报文的传输顺序	缺乏连接使IPC机制很难维护传输顺序
协议	在通信模式适合需要交换大量数据流和/或大量反复交换的协议	在通信模式适合在有限循环交换中交互少量数据的协议

一型代理服务器和二型代理服务器通信方式的选择

根据一型代理服务器和二型代理服务器之间的通信需求，选择的是无连接的通信方式。因为在这两个服务器之间传送的数据量很少，并且不要求数据一定要被传送到，和有效的接收。

一型代理服务器详细描述

一型代理服务器在内存中保存着一个数据结构。这个数据结构包括二型代理服务器的地址信息。这个数据结构，将被周期性的保存到磁盘上，称作一个备份。当一型代理服务器出现问题，重新启动后，它就读取最新的备份。然后向数据结构里面保存的二型代理服务器发送信息，检查是否二型代理服务器还在提供服务。

在一型代理服务器的内存里面还有一个队列。这个队列里面的每一个元素保存着一个指向二型代理服务器地址的指针。这个队列周期性的根据所指向的二型代理服务器的负载程度进行排序。每当有用户接口请求到来的时候，就从队列里面取出一个元素，通过包含的指针找到一个二型代理服务器的地址，并把地址返回给用户接口，最后把指向这个二型代理服务器地址的元素插入到队列的对尾。

在一型代理服务器中，可以存放大量的二型代理服务器的信息。并且由于是保存在内存中的，检索速度非常快，所以它不会是性能的瓶颈所在。并且将来也不会是规模扩展的瓶颈。

由于代理服务器由两层构成，所以会出现这样的情况，一个二型代理服务器突然失效了，但是这个失效的信息，还没有被一型代理服务器所获得。这个时候，如果有用户接口请求，并且一型代理服务器返回了这个二型代理服务器的地址，那么用户接口将无法完成检索，出现一个错误。这样处理这个错误，如果用户接口在和二型代理服务器通信的时候出现错误，它将再次尝试和那个二型代理服务器进行通信，如果还是出现错误，那么它再次请求一型代理服务器，获得一个二型代理服务器的地址。它并不把和二型代理服务器通信出错的信息发送给一型代理服务器。这个失效的二型代理服务器的地址，由一型代理服务器进行周期性的检测的时候，进行删除。

3.1.2 搜索服务器瓶颈及解决方案

搜索服务器是真正进行检索的地方。所以一个用户请求的大部分时间花费在搜索服务器上。所以要对搜索程序进行优化，以提高检索的速度。检索的速度是和数据量有关系的，所以，要尽量把数据平均分配到各个搜索服务器上。这样可以保证检索过程在最短的时间内完成。因为，代理服务器要等待所有的搜索服务器完成后，才返回结果。

在上面的所有模型中，每个请求都将被发送到所有的搜索服务器中，每个请求都将在所有的搜索服务器上执行。可以通过对索引的数据进行分类，分别进行存储，这样每个请求就被分配到相关类别的搜索服务器上。

现在假设，用户搜索的是英文单词的汉语意思。根据这个需求，修改上面的模型，得到这样一个模型。如下图3－2所示。

图3－2索引数据分类后的搜索服务器模型

在这个模型中索引文件根据单词的首字母进行了分类。把分类后的索引文件分别存放到不同的搜索服务器上。这样当用户发送query给代理服务器的时候，代理服务器根据单词的首字母，把请求发送到相应的搜索服务器上。这样能够提高系统整体的性能。但对于每一次查询请求，所花费的时间根据数据量的多少有不同的变化。例如，以字母Z开头的单词，因为数量很少，所以检索的速度就会很快。而以字母A开头的单词，因为数量比较多，检索的速度就会变慢。

可以把这个模型中的搜索服务器，进行一下综合，以减少所用的服务器资源的数量。例如，以字母X，Y，Z开头的单词数量比较少，可把它们存放到一个搜索服务器上。而以A，C开头的单词数量比较多，可以把它们存储到两个或更多的服务器上。

在这个模型中，就需要对代理服务器进行一下改进。使它可以根据单词的首字母进行相关搜索服务器的查询。

在上面的所有模型中，除了在两层代理服务器那个模型中，考虑了一下机器失效，其他的模型中都认为机器和程序不会出现问题。但是，在实际的工作中，机器和程序出现问题是不可避免的。这就要求，必须考虑如果出现问题，应该怎么应对。对于一个商业项目，不能因为问题的出现而影响到对外提供的服务。

3.2 机器失效

3.2.1 搜索服务器失效及解决方案

当有搜索服务器失效了，如果不是所有的搜索服务器都失效了，从用户的角度来看，是看不出来的。因为，部分搜索服务器不对外提供服务了，就会使检索到的数据变少，甚至检索不到数据。但用户会认为确实不存在这样的数据。不过从检索过程的正确性来考虑，如果有部分搜索服务器失效了，就会造成数据的不一致。例如，当一个用户搜索一个query的时候，他得到了100条数据，在这个过程完成之后，有一个搜索服务器出现了问题，不能提供服务了，而这个搜索服务器上正好存储了40条数据，那么在这个服务器没有再次提供服务的时候，用户又用同样的query进行检索，就会只得到60条数据，造成前后检索的不一致。

针对这个问题，有几种解决办法：

1.当发现有搜索服务器出现问题的时候，马上手工换上一台和这台搜索服务器提供同样服务的机器。这样做，实现起来很简单，但是，这存在很多不足：一、如果要在最短的时间内完成这个任务，就必须使每一台搜索服务器都有相对应的备份机。这样为了这个目的，就必须多维护一倍的机器资源。二、因为是手工实现，所以必须保证有人实时在对整个系统的情况进行监控，这也会耗费大量的人力资源。三、如果不对每台搜索服务器进行备份，把全部的索引数据都集中存放，就必须在发现有搜索服务器出现问题的时候，马上把和那台服务器一样的数据复制到一台新机器上。这样就会使问题持续的时间更长。

2.设计一个模型，搜索服务器出现问题的时候可以自动回复。添加一台监控服务器，对搜索服务器进行监控，如果发现有搜索服务器出现问题，监控服务器可以用另一台机器完成相同的服务。如下图3－3所示。监控服务器监控所有的搜索服务器。当发现有搜索服务器出现问题，它马上启动一台备用机，并通知搜索数据服务器把相关的数据发送到备用机上。当数据传送完毕后。监控服务器用这台备份机替换失效的搜索服务器。

图3－3添加监控服务器后的搜索服务器模型

3.再设计一个模型，搜索服务器出现问题的时候可以自动恢复。添加一台监控服务器，对搜索服务器进行监控，如果发现有搜索服务器出现问题，监控服务器可以在搜索服务器上进行调度。如下图3－4所示。这个模型和上面的模型很相似。也是监控服务器，监控所有的搜索服务器。不过，当发现有搜索服务器出现问题，它不是启动一台备用机来解决问题，而是调度正在工作中的搜索服务器来解决问题。因为现在机器的硬盘都比较大，所以，可以在每台搜索服务器上存储冗余的索引数据。这样当有失效的机器出现的时候，监控服务器，寻找存储有失效机器服务数据相同的在工作中的搜索服务器，让这台工作中的搜索服务器，读取相关的数据，提供服务。如果没有找到这样一台搜索服务器，那么监控程序，寻找拥有相关数据最多的搜索服务器，然后把其他的搜索服务器上的相关数据发送过来，数据发送完毕之后让这台搜索服务器，读取相关数据，然后提供服务。

图3－4添加监控服务器后的搜索服务器模型

3.2.2 代理服务器失效及解决方案

当代理服务器失效了，整个系统将无法对外提供服务了。所以保证代理服务器的有效性十分的关键。

代理服务器，会出现下面几种不同的问题：

1.由于程序运行错误或异常，造成的代理服务器无法对外提供服务。但相关的数据和代理服务器机器没有任何问题。

2.由于程序运行错误或异常，造成的代理服务器无法对外提供服务。并且由于错误或异常的出现，导致相关数据出现问题，并且数据无法恢复到可用状态。

3.代理服务器机器硬件出现问题。但是保存相关数据的磁盘，仍然是可用的。

4.代理服务器机器硬件出现问题。并且保存相关数据的磁盘，也出现问题，造成里面数据的不可用。

针对上面代理服务器出现的不同问题，下面给出不同的解决方案。

对于第一种代理服务器问题，可以简单的把机器重新启动一下，当启动完毕后，代理服务器程序加载完，就可以对外提供服务了。整个系统的不可用时间为，从代理服务器出现问题，到代理服务器程序加载完毕。

对于第二种代理服务器问题，也只用简单的把机器重新启动一下，不过当启动完毕后，代理服务器程序并没有正确的数据可以加载。这个时候，根据搜索服务器和代理服务器之间的通信关系的不同，可以有两种方法恢复数据。一、如果搜索服务器的地址是固定的。那么可以把搜索服务器的地址数据直接发送给代理服务器，这样代理服务器就可以正常运行了。这种情况下的整个系统的不可用时间为，从代理服务器出现问题，到把搜索服务器地址数据发送给代理服务器，并由代理服务器加载完毕。二、如果搜索服务器程序的地址不是固定的，而是由每个加入到这个系统的搜索服务器主动发送过来的，那么，等待搜索服务器下一次把地方发送过来的时候，代理服务器就可以对外提供服务了。这种情况下的整个系统的不可用时间为，从代理服务器出现问题，到代理服务器重新启动完毕，并有搜索服务器把地址发送过来之后。

对于第三种代理服务器问题，和第四种代理服务器问题，可以仿照上面的解决方法进行解决。不同的地方就是，需要用一台备份机来替换这台出现问题的代理服务器。

上面列的所有解决方法，虽然可以有效的解决出现的问题，不过，都存在一个问题，就是，整个系统要有一段无法提供服务的时间。对于这个问题，必须重新设计模型。新设计的模型如下图所示。

就是增加一个代理服务器。这样，虽然有可能浪费一些硬件资源，但是对于一个商业项目，或是一个对于系统稳定性要求比较高的项目，这样一些资源的花费是值得的。

通过增加一个代理服务器。这就可以保证当在一个代理服务器出现问题的时候，因为另一个仍然可用，从而保证系统的可用性。假设，每一个代理服务器出现问题的几率是10％，那么两台同时出现问题的几率就只有1％。这就大大增加了系统的稳定性。

图3－5增加代理服务器后的模型

当一个代理服务器出现问题的时候，可以使用上面列出来的解决方法，来解决出现问题的代理服务器。这样做很简单方便。不过，在这个模型的基础上，也可以增加一个监控服务器。这样就可以自动的来恢复系统。如下图3－6所示。

图3－6增加监控服务器后的代理服务器模型

通过这个模型就可以把相关的解决方法交给监控服务器来完成。监控服务器的执行类似于上面搜索服务器的监控服务器的执行过程。这里就不详细描述了。

至此，基本上研究了分布式信息检索中的基础性问题。不过，有一个问题还没考虑。这个问题就是，分布式信息检索返回来的结果，怎么样传送给用户接口。如果，返回来的结果很少，那么可以全部传送给用户接口。如果返回来的结果很多，就不能全部传送给用户接口。例如，当在Baidu，或Google上搜索“分布式信息检索”的时候，它不是返回所有找到的内容，而是按照相关性的顺序，每次返回10个内容。

下面就将讨论一下这些问题。

3.3 数据的相关性和结果数量限制

当用户输入一个查询条件后，搜索程序检索出来的结果，根据检索出来的内容和查询条件之间的相关性，有一个评分，这个相关性规则和评分规则可以自由设定，这里因为主要是研究分布式信息的检索，主要关注的是分布式的实现，所以就不详细描述相关性规则和评分规则了。评分越高相关性越高，反之亦然。根据每个检索出来的内容的评分，搜索程序按照评分从高到低，来排序检索出来的内容。

这里有两个问题要解决：

1.结果要按相关性从高到低的顺序呈现给用户。

2.呈现给用户的结果的数量要有一定的限制。

首先，不考虑数量限制的问题，只考虑相关性的问题。当代理服务器把用户输入的查询条件发送给搜索服务器以后，它就等待接收返回来的结果。为了按相关性从高到低的顺序，把结果返回给用户接口，从搜索服务器返回来的结果，除了要有内容外，还要有每个内容的评分。当代理服务器把所有的结果都接收完毕以后，它就根据每个内容的评分进行排序。最后把排好序的结果返回给用户接口。

现在，考虑数量限制的问题。对数量限制有一个很简单的解决办法。就是按上面描述的那样进行排序，排序完毕后，每次根据条件返回适当数量的结果给用户接口。这样做很简单。当在数量很少的时候也比较有效，不过，如果数据量很大的情况下就存在效率的问题了。例如，对一个用户输入的查询条件，每个搜索服务器都返回1000个结果，有10台搜索服务器。这样，代理服务器必须对这10000个结果，进行排序。而排序完毕后只给用户接口返回相关性最高的10个结果。这样不仅加重了代理服务器的计算压力，而且在传输大量数据的时候，浪费了大量的带宽资源。

针对这个问题，给出以下解决办法。

当用户接口发送查询条件过来的时候，它还附加一个信息，这个信息描述用户希望按相关性排序后，哪一范围的结果。例如，用户接口发送给代理服务器的信息像这样，“分布式信息检索，30， 20 ” 。这条信息的意思是：检索和分布式信息检索相关的内容，并返回，按相关性排序后，从第30位开始的，20条结果。这样代理服务器就可以根据这个信息，把相关要求发送给搜索服务器。接着上面的例子中的数据。代理服务器给搜索服务器发送如下形式的信息，“代理服务器， 50 ” 。这条信息的意思就是：检索和分布式信息检索相关的内容，并返回，按相关性排序后，前50位的结果。如果有10台搜索服务器，每台上面有1000个相关的结果。这样原本要处理的数据量和发送的数据量就从10000条，减少到500条，减少了95％。这就大大的提高了系统整体的运行效率。

如果，再仔细考虑一下，还会发现有可以改进的地方。在上面的500条数据中，要返回的只是其中20条。所以，可以这样改进代理服务器和搜索服务器之间的通信。当代理服务器发送查询条件给搜索服务器的时候，搜索服务器只返回相关结果的标识和评分。这个标识在每一台搜索服务器上是唯一的。这样，代理服务器按照评分进行排序后，选择出用户要求范围的标识。再根据这些标识，和搜索服务器进行通信，得到相关的内容。如下图3－7所示。

图3－7通过标识获取内容的机器间通信

除了上面的方法外，还有一些其他方法。例如，根据每个搜索服务器返回来的部分结果，进行预测。从而可以进一步提高效率。不过这多少会和精确的结果有些偏差。因为时间和研究方向的原因，这里就不详细描述了。

现在已经基本完成了分布式信息检索的所有相关问题的研究。下面，要根据上面的内容，设计一个比较完整的，稳定高效的模型。

4 分布式信息检索系统模型设计

在开始设计之前，还要介绍一些将要用到的一些技术。

4.1 分布式文件系统(DFS)

一个可扩展的分布式文件系统，用于大型的，分布式的，对大量数据进行访问的应用。它运行于廉价的普通硬件上，但可以提供容错功能。它可以给大量的用户提供总体性能较高的服务。这个分布式文件系统主要用在搜索服务器上，来进行索引文件的存储。

4.2 分布式文件系统的特点

1.机器错误不再被当作异常，而是将其作为常见的情况加以处理。因为文件系统是由成百上千个用于存储的机器构成的，而这些机器是由廉价的普通部件组成并被大量的客户机访问。部件的数量和质量使得一些机器随时都有可能无法工作并且有一部分还可能无法恢复。所以实时地监控、错误检测、容错、自动恢复对系统来说必不可少。

2.运行在这个分布式文件系统上的应用程序，以流的方式访问它们的数据。这个分布式文件系统被设计成更适合批量处理，而不是和用户的交互。它关注的是数据访问的吞吐量，而不是数据访问的时间。

3.运行在这个分布式文件系统上的应用程序有一个大的数据集。也就是说一个在这个分布式文件系统中的文件有GB到TB的大小。并且它还要支持在一个机群中存储好几百万的文件。

4.工作量主要由两种”读操作”构成：对大量数据的流方式的读操作和对少量数据的随机方式的读操作。在前一种读操作中，可能要读几百KB，通常达1MB和更多。来自同一个客户的连续操作通常会读文件的一个连续的区域。随机的读操作通常在一个随机的偏移处读几个KB。性能敏感的应用程序通常将对少量数据的读操作进行分类并进行批处理以使得读操作稳定地向前推进，而不要让它来来回回的读。

5.工作量还包含许多对大量数据大量的、连续的、向文件中添加数据的写操作。所写的数据的规模和读相似，一旦写完，文件很少改动。在随机位置对少量数据的写操作也支持，但不必非常高效。

6.如果一个应用程序的计算能在离数据最近的地方执行，那是最好的。尤其是当数据的数量非常大的时候。这可以减少的网络的堵塞。这个方法就是把计算移动到离数据近的地方，而不是把数据移动到应用程序运行的地方。分布式文件系统提供一个接口，使应用程序可以把自己移动到靠近数据的地方。

4.3 分布式文件系统的体系结构

1.一个分布式文件系统集群由一个Master和大量的Chunkserver构成，并被许多客户(Client)访问。如图4－1所示。Master和Chunkserver通常是运行用户层服务进程的Linux机器。只要资源和可靠性允许，Chunkserver和Client可以运行在同一个机器上。

2.文件被分成固定大小的块。每个块由一个不变的、全局唯一的64位的chunk－handle标识，chunk－handle是在块创建时由 Master分配的。Chunkserver将块当作Linux文件存储在本地磁盘并可以读和写由chunk－handle和位区间指定的数据。出于可靠性考虑，每一个块被复制到多个Chunkserver上。默认情况下，保存3个副本，但这可以由用户指定。

3.Master维护文件系统所有的元数据(metadata)，包括名字空间、访问控制信息、从文件到块的映射以及块的当前位置。它也控制系统范围的活动，如块租约(lease)管理，孤儿块的垃圾收集，Chunkserver间的块迁移。Master定期通过HeartBeat消息与每一个 Chunkserver通信，给Chunkserver传递指令并收集它的状态。

4.与每个应用相联的DFS客户代码实现了文件系统的API并与Master和Chunkserver通信以代表应用程序读和写数据。客户与Master的交换只限于对元数据(metadata)的操作，所有数据方面的通信都直接和Chunkserver联系。

5.客户和Chunkserver都不缓存文件数据。因为用户缓存的益处微乎其微，这是由于数据太多或工作集太大而无法缓存。不缓存数据简化了客户程序和整个系统，因为不必考虑缓存的一致性问题。但用户缓存元数据(metadata)。Chunkserver也不必缓存文件，因为块是作为本地文件存储的。

图4－1分布式文件系统结构图

只有一个Master也极大的简化了设计并使得Master可以根据全局情况作出先进的块放置和复制决定。但是必须要将Master对读和写的参与减至最少，这样它才不会成为系统的瓶颈。Client从来不会从Master读和写文件数据。Client只是询问Master它应该和哪个Chunkserver联系。Client在一段限定的时间内将这些信息缓存，在后续的操作中Client直接和Chunkserver交互。

以图4－1解释一下一个简单的读操作的交互：

1.client使用固定的块大小将应用程序指定的文件名和字节偏移转换成文件的一个块索引(chunk index)

2.给Master发送一个包含文件名和块索引的请求。

3.Master回应对应的chunk handle和副本的位置(多个副本)

4.client以文件名和块索引为键缓存这些信息。(handle和副本的位置)

5.client 向其中一个副本发送一个请求，很可能是最近的一个副本。请求指定了chunk handle(Chunkserver以chunk handle标识chunk)和块内的一个字节区间。

6.除非缓存的信息不再有效(cache for a limited time)或文件被重新打开，否则以后对同一个块的读操作不再需要client和Master间的交互。

通常client可以在一个请求中询问多个chunk的地址，而Master也可以很快回应这些请求。

基于这个分布式文件系统，就可以比较容易的建立分布式信息检索系统。

4.4 系统模型设计

这个设计过程根据代理服务器和搜索服务器的不同，而主要分成两个部分来设计，分别是代理服务设计，搜索服务设计。首先是搜索服务的设计过程。

4.4.1 搜索服务设计

搜索服务是由两个逻辑模块组成的。一个是分布式文件系统，另一个是搜索系统。如下图4－2所示。

在搜索服务系统里面，由三种类型的物理主机组成，DFS Master，监控服务器，和工作机器。

在工作机器上运行着三个服务程序：

1.DFS Client。

2.ChunkServer。

3.搜索服务器。

逻辑上，DFS Master和ChunkServer构成分布式文件系统。监控服务器和搜索服务器构成搜索系统。

图4－2搜索服务逻辑模型

DFS Master，监控服务器，和工作机器之间的交互关系，如下图4－3所示。下面解释一个关键步骤：

1.DFS Master根据分布式文件系统的性质，把索引文件存储到不同的工作机器上。

2.监控服务器从DFS Master上获得索引文件的相关信息。包括，都有那些索引文件，和索引文件在哪台工作机器上存储。

3.监控服务器根据所获得的信息，向工作机器发送命令，指示工作机器上的搜索服务程序，读取哪部分索引文件，对外提供服务。

图4－3搜索服务的交互模型

4.4.2 代理服务设计

代理服务采用两层代理服务器模型，并加入监控服务器。如下图4－4所示。

一型代理服务器和二型代理服务器之间的关系，和上面介绍的相同，这里就不详细描述了。

监控服务器对一型代理服务器和二型代理服务器进行监控，如果发现有服务器出现问题，并且无法恢复，就启动备用机进行替换。

当二型代理服务器出现问题，并无法恢复，监控服务器就马上启动一台备用机进行替换。

当一型代理服务器出现问题，并无法恢复，监控服务器也马上启动一台备用机，然后发送命令给仍然在工作中的一型代理服务器，让它把相关的数据发送给刚刚启动的备用机上，当数据发送完毕后，用备用机进行替换。

 

图4－4代理服务交互模型

4.4.3 综合设计

根据上面的研究和设计，现在给出分布式信息检索系统的结构图。如下图4－5所示。

系统各部分之间的交互关系，从上面的内容可以很容易知道，这里就不详细描述。

根据这个模型，就可以构造出一个   比较完整，稳定高效的分布式信息检索系统了。

系统特点如下：

1.不会因为部分机器的失效，而无法对外提供服务。

2.对搜索速度的要求，可以通过添加额外的机器来实现。

3.出现错误以后，系统可以自动恢复。

图中各组成部分之间的通信方式，要根据不同的应用进行不同的设计。但是，一个原则就是尽量减少数据的传输。                                                   

图4－5分布式信息检索系统结构图

5 模型实现

因为最终的设计模型非常复杂和庞大，并且分布式文件系统也没有开发完毕，所以这里只实现了开始的简单模型。

根据改进后的简单模型实现一个简单的分布式检索程序。

在这里先简单的介绍一下，即将使用的一个搜索程序----lucene。因为本次研究分布式是研究的难点，所有为了更多的把注意力集中到分布式上，直接用了一个开源的搜索程序。

5.1 搜索程序简介

Lucene是apache软件基金会 jakarta项目组的一个子项目，是一个开放源代码的全文检索引擎工具包，即它不是一个完整的全文检索引擎，而是一个全文检索引擎的架构，提供了完整的查询引擎和索引引擎，部分文本分析引擎（英文与德文两种西方语言）。Lucene的目的是为软件开发人员提供一个简单易用的工具包，以方便的在目标系统中实现全文检索的功能，或者是以此为基础建立起完整的全文检索引擎。

作为一个开放源代码项目，Lucene从问世之后，引发了开放源代码社群的巨大反响，程序员们不仅使用它构建具体的全文检索应用，而且将之集成到各种系统软件中去，以及构建Web应用，甚至某些商业软件也采用了Lucene作为其内部全文检索子系统的核心。apache软件基金会的网站使用了Lucene作为全文检索的引擎，IBM的开源软件eclipse的2。1版本中也采用了Lucene作为帮助子系统的全文索引引擎，相应的IBM的商业软件Web Sphere中也采用了Lucene。Lucene以其开放源代码的特性、优异的索引结构、良好的系统架构获得了越来越多的应用。

Lucene作为一个全文检索引擎，其具有如下突出的优点：

1.索引文件格式独立于应用平台。Lucene定义了一套以8位字节为基础的索引文件格式，使得兼容系统或者不同平台的应用能够共享建立的索引文件。

2.在传统全文检索引擎的倒排索引的基础上，实现了分块索引，能够针对新的文件建立小文件索引，提升索引速度。然后通过与原有索引的合并，达到优化的目的。

3.优秀的面向对象的系统架构，使得对于Lucene扩展的学习难度降低，方便扩充新功能。

4.设计了独立于语言和文件格式的文本分析接口，索引器通过接受Token流完成索引文件的创立，用户扩展新的语言和文件格式，只需要实现文本分析的接口。

5.已经默认实现了一套强大的查询引擎，用户无需自己编写代码即使系统可获得强大的查询能力，Lucene的查询实现中默认实现了布尔操作、模糊查询（Fuzzy Search）、分组查询等等。

下图5－1展示了一个和lucene相结合的应用程序。

图5－1一个典型的集成了lucene的应用程序结构图

5.2 实现步骤

5.2.1 开发环境

开发语言：Java

操作系统：Windows Xp

Web服务器：tomcat

5.2.2 用户接口实现

用网页实现一个用户接口。把查询提交给代理服务器。如下图5－2所示。关键代码action=ProxyServer

图5－2 用户接口

5.2.3 代理服务器实现

代理服务器由两部分组成。一个是接受用户的输入，并把结果返回的服务程序。另一个是把用户的输入发送到所有搜索服务器上，存储从搜索服务器上返回的结果的程序。如下图5－3所示。

解释一下图中的步骤：

1.用户接口发送query给ProxyServer中的Server。

2.ProxyServer中的Server接受query,并调用Searcher进行检索.

3.Searcher被调用以后，根据SearchServer的数量N，创建N个和SearchServer交互的子线程。由这N个子线程把query传送给SearchServer

4.接收返回结果。子线程把接收到的结果存储在Searcher中

5.当这N个子线程全部结束之后，Searcher把结果返回到Server中。

6.最后，由Server把结果返回给用户.

图5－3代理服务器

5.2.4 搜索服务器实现

搜索服务器也是由两部分组成。一个是接受用户的输入，并把结果返回的服务程序。另一个是调用lucene搜索接口的搜索程序。如下图5－4所示。

这个图显示了搜索服务器的结构。其中有些步骤很容易理解，下面解释一下关键步骤：

1.Searcher调用lucene的搜索接口，把query传送给lucene。

2.Lucene打开数据索引文件。

3.Lucene读取索引文件中的数据。

4.在lucene中执行搜索运算，最后把结果返回给Searcher。

图5－4搜索服务器

5.2.5 数据索引实现

因为直接用的是开源的索引程序，所有实现起来比较简单。关键代码如下：

1.IndexWriter writer = new IndexWriter(indexDir,new StandardAnalyzer(), true);

2.Document doc = new Document();

3.doc.add(new Field("contents", new FileReader(f)));

4.doc.add(new    Field("filename", f.getCanonicalPath(),Field.Store.YES,Field.Index.NO));

5.writer.addDocument(doc);

这里首先创建一个写索引的writer，然后创建一个Lucene里索引的基本单位doc,向doc里面添加要索引的文件内容和文件的名字，最后把索引的基本单位doc添加到writer里面。

6 测试

6.1 索引和搜索

索引过程截图。如下图6－1。

指定一个要被索引的文件夹，然后运行程序。这里是对一个“法律语料库”进行的索引。

图6－1索引过程

搜索过程截图。如下图6－2和6－3所示。

用户在用户接口页面里输入“诉讼法”检索关键词，然后点击搜索按钮，最后返回显示的结果。

图6－2用户接口页面

图6－3返回结果后的用户接口页面

6.2 执行过程分析

下面是四次执行过程内部程序花费时间的截图。如图6－4所示。

图6－4内部程序的花费时间

Search took指在搜索服务器上检索程序对一个检索条件进行检索的时间。

SearchServer指搜索服务器从收到请求，到返回结果的时间。

Proxy指代理服务器上，把请求转发给搜索服务器，到从搜索服务器接收完结果的时间。

ProxyServer指代理服务器从收到请求，到返回结果的时间。

通过观察可以发现，如果数据量不大，那么在数据通信上所花费的时间是可以忽略不计的。但是，代理程序把请求转发给搜索服务器，到从搜索服务器接收完结果的时间，要比搜索服务器从收到请求，到返回结果的时间长。通过研究程序发现，原因存在于代理服务器上，因为每次都要创建新的线程和搜索服务器通信。在程序中实现线程池之后，这个时间花费的问题就解决了。如下图6－5所示。

图6－5实现线程池之后内部程序的花费时间

7 结论

本文首先对一个简单的分布式信息检索模型进行了介绍，然后提出了这个简单模型中存在的不足和缺陷，并给出了相应的解决方案，最后，设计出了一个比较完整的，稳定高效的模型。

不过，分布式信息检索还处于初步研究的阶段，有很多问题还需要进行一步的研究，才能使系统更加完善。

虽然本文关注的是检索过程的实现，但是，在分布式信息检索系统中，索引过程也是非常重要的。

在以后的研究中，要对检索过程和索引过程进行更深入的研究，使这两个过程更加完善，并且有效的结合在一起。

致  谢

本次毕业设计能够顺利完成，是很多人辛勤工作的结果，凝聚很多人的汗水，在此笔者对他们致以最诚挚的谢意。

首先要感谢笔者的导师李建老师。本次的论文虽然是在实习公司完成的，但是李建老师给予了笔者莫大的支持，从论文的取材、切入点、论述的重点等方面都给予了笔者很大的启示。他渊博的知识、严谨的治学态度、精益求精的工作作风，是笔者一生学习的榜样，并将成为笔者今后献身软件工程事业的动力。

其次要感谢在北京中和天地实习期间的项目经理豆连军工程师。感谢他一直以来的关心和照料，以及在技术上的支持和指导，使笔者在短短的一个月时间就完全溶入了公司的开发团队，并在这两个月的时间飞速的成长。他兢兢业业的工作作风，渊博的知识，和蔼的态度，平易近人的性格都是笔者日后努力的方向。

最后，还要感谢我的父母和大学四年以来所有关心过笔者和教育过笔者的老师，谢谢你们的关心和支持。

参考文献

[1] M.L.Liu.分布式计算原理与应用.北京:清华大学出版社,2004.1-73

[2] Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung.The Google File System

[3] Jeffrey Dean and Sanjay Ghemawat.MapReduce: Simplified Data Processing on Large Clusters

[4]Jie Wu.分布式系统设计.北京:机械工业出版社,2001.263-281

[5]冯玉琳,黄涛,金蓓弘.网络分布式计算和软件工程.北京:科学出版社,2003.93-153

[6]Erik Hatcher.Lucene IN Action. America :Manning Publications Co.,2005.1-220

[7] 王斌，张刚，孙健. 大规模分布式并行信息检索技术

[8] Doug Cutting. MapReduce in Nutch

[9]Java Message Service Tutorial, http://java.sun.com/products/ jms/tutorial

[10]IBM Aglet.http://www.trl.ibm.com/aglets/

[11]王亮.基于DNS的网页搜索引擎

[12]王斌，张刚，孙健.大规模分布式并行信息检索技术

[13]Nutch.http://lucene.apache.org/nutch/

[14]Lucene.http://lucene.apache.org/lucene/

[15] 薛云皎.分布式构件

[16]罗杰文.移动主体综述

[17] Hongfei Yan. SE4Topic掀起你的盖头来

[18] 叶绍志. 分布式搜索引擎链接模型与网页重要度快速算法

[19] 赵江华，闫宏飞，王建勇，李晓明. “天网”中的并行与分布处理

[20] 方馨馨，熊齐邦. Peer2Peer网络中的分布式搜索