CN102201007A - 一种大规模数据搜索系统 - Google Patents

Abstract

本发明公开了一种大规模数据搜索系统，主要包括倒排文件模块、数据接口模块、查询模块、切词模块及记分函数模块以及进程守护模块，倒排文件模块用于搜索系统能够快速找到查询词对应的文档列表；数据接口模块封装了每个要公开的数据的访问方法；查询模块用于利用输入端查询条件进行搜索，将各个关键词对应文档列表求交集；切词模块用于切词并得到各个关键词并形成一棵查询树；记分函数模块负责进行站点聚类，得到聚类好的查询结果；守护进程模块用于接受查询请求并根据查询请求中指定的最大返回结果数。利用该系统，能够减少访问磁盘的开销；并通过一些有效的预处理，减少浮点运算的次数，进一步提高检索效率。

Description

一种大规模数据搜索系统

技术领域

本发明涉及搜索引擎技术，尤其涉及一种大规模数据搜索系统。

背景技术

众所周知，搜索引擎是用于从互联网上搜寻信息的重要工具。随着互联网规模的不断扩大和网上信息量的不断增长，搜索引擎的作用也就越来越重要。

当前，互联网上的搜索引擎虽然大小不同，功能也各异，但它们都包含以下一些基本的功能模块：网页收集模块、页面预处理模块、索引模块、页面检索模块等。其中，可利用上述搜索引擎的索引模块生成倒排文件，被检索模块所使用。

这里，所述倒排文件是从关键词到其出现位置(occurrence)的一种索引。对于搜索引擎来说，关键词的出现位置信息必须包括出现关键词的文档列表，以及关键词在各文档内的位置列表。一般而言，倒排文件由索引文件和记录文件组成，索引文件每个记录包含一个关键词和一个指针，该指针指向记录文件中存放关键词信息的位置。其大致结构如图1所示，利用倒排文件，检索系统可以快速的找到查询词对应的文档列表。对由多个关键词所组成的查询，还可以根据各个词在各个文档中出现的位置，来计算查询与文档的相关度。倒排索引是迄今为止发现的用于搜索引擎最好的索引结构，既方便建立，又很好的支持各种查询操作。在实际应用中的倒排文件远比上图的复杂：为了更好的计算相关度，倒排文件中还要加入其它的一些信息，例如关键词在文档中的属性信息；为了提高检索效率，可能要调整倒排文件的结构，例如先存放出现关键词的所有文档列表，再存放所有的位置信息，把上图中位置信息的形式：

<doc1><pos1pos2pos3...><doc2><pos1’pos2’pos3’...><doc3><pos1”pos2”pos3”...>

变换为：

<doc1doc2doc3...><pos1pos2pos3...pos1’pos2’pos3’...pos1”pos2”pos3”...>

通过这种变换，当我们不关心词在文档中位置列表的时候，就可以一次地读入词对应的文档列表，减少对外存的访问次数。在后面我们还将详细讨论倒排文件的设计，我们会发现倒排文件结构的好坏直接影响检索速度。

现代搜索引擎搜索的网页都数量巨大，目前的北大天网(e.pku.edu.cn/)搜索引擎搜索的网页量就有1.2亿，而一般的商业搜索引擎搜索的网页量至少都有数亿，甚至是达到数十亿。在这种情况下，一个单机的检索系统显然无法处理每秒成百上千的用户查询请求。此时，设计出一个结构良好的分布式检索系统显得尤为重要。一般成言，分布式检索系统至少包括两个部分：一台或多台用于接收入用户查询请求的前台服务器，和多个用于实际数据检索的后台服务器，其结构如图2所示。

当用户在搜索框中填入一个查询项，点击搜索按钮，其查询请求就被随机的发送到任意一台前台服务器上。而前台服务器实际上并不保存网页的索引信息，它将用户的查询通过广播的方式发送到后台的检索机群上。后台检索机群中，每台机器中都存放有部分网页的倒排索引，当它收入到广播过来的查询，便在其索引中查找出与查询其关的网页，并根据一定的相关度算法计算出得分，把相关度最高的若干个网页的文档号与得分一起发送回前台的服务器。前台服务器收集几个检索机器上的结果，按得分归并后把最相关的网页返回给用户。

由于时间的关系本文必没有详细的研究检索系统的分布式结构，而是更多的关注各个检索节点上的效率。可以说，这两方面共同决定了一个检索系统的性能。但是，现在的大型搜索系统，仍然存在一些问题需要我们去改善，主要体现在如下几个方面：

一、检索效率不高。每个检索节点检索的网页量大约在二百多万，每秒只能处理十几个的查询请求。主要原因是没有为倒排文件建立cache，每次查询都要多次访问外存，磁盘成了系统的瓶颈。此外，其分布式结构也不太好，前台服务器与检索节之间基于同步的多进程的交互方式，也影响和整个系统的效率。

二、倒排文件信息量不够。现在的倒排文件中，关键词在文档中的属性信息很少，只用两个bit分别表示词是否在网页title和摘要中，并且不能为关键词在文档中各个位置设立属性信息。由于信息量的缺乏，在计算词与文档相关性的时候，往往不够准确。

三、系统的可扩展性和容错性不足。系统现在运行在由一台前台服务器，19个检索节点构成的分布式环境中。对于增加检索节点可能带来的广播风爆，以及增加前台服务器查询策略的变化，都没有考虑到。此外，数据没有冗余，当系统中部分机器出现故障，则会影响查询结果。

发明内容

有鉴于此，本发明的主要目的在于提供一种大规模数据搜索系统，通过改进倒排文件结构、改进整数的压缩算法，并增加倒排文件的信息量；能够通过有效的cache策略，让索引尽量的在内存中可以找到，减少访问磁盘的开销；并通过一些有效的预处理，减少浮点运算的次数，也进一步的提高检索效率。对于相关度计算，本文也做了一些改进，使得在最后的结果排序上更符合用户需求。

为达到上述目的，本发明的技术方案是这样实现的：

一种大规模数据搜索系统，其主要包括倒排文件模块、数据接口模块、查询模块、切词模块及记分函数模块以及进程守护模块，其中：

所述倒排文件模块，用于搜索系统能够快速找到查询词对应的文档列表；

所述数据接口模块，是一组接口类，封装了每个要公开的数据的访问方法；

所述查询模块，用于利用输入端查询条件进行搜索，将各个关键词对应文档列表求交集；

所述切词模块，用于切词并得到各个关键词并形成一棵查询树；

所述记分函数模块，负责进行站点聚类，得到聚类好的查询结果，排列并返回给守护进程模块；以及，

所述守护进程模块，用于接受查询请求，并根据查询请求中指定的最大返回结果数，将部分结果返回。

其中，所述倒排文件模块，采用新的倒排文件格式，其包含描述文件、索引文件和记录文件，支持程序的快速访问。

所述倒排文件模块的描述文件，包括倒排文件自身的属性信息，包括：

Byte-Order属性：表示倒排文件中使用整数的字节序，包含压缩整数和非压缩整数；

Align-Bits属性：使用了32位的偏移量，Align-bits属性表示移动的位数；

Attr-Size属性：在这个格式中，允许关键词在每个出现它的文档中，有0个或多个字节的属性信息；这个属性信息的意义在本格式中无定义，完全由应用程序决定；该属性信息必须是整字节的，并且所有的属性信息必须等长；这个长度就是倒排文件的Attr-size属性；

Uint-Encoding属性：压缩整数的编码方式。

本发明所提供的大规模数据搜索系统，具有以下优点：通过定义新的倒排文件格式，其支持程序的快速访问。改进了整数压缩算法，使得倒排文件的规模变小，从而也就减少了检索时从磁盘读取的数据量。通过使用文档列表cache，减少对磁盘的访问次数。通过预先计算相关度，完全消除了检索过程中的浮点运算，节省了CPU计算时间，但代价是增大了倒排文件规模。充分的利用关键词在文档中的属性信息，减少不必要的相对位置计算，既节省了CPU时间，又减少了一些磁盘IO。从而改进了站点聚类算法，降低了时间复杂度。

附图说明

图1为现有倒排文件结构示意图；

图2为现有检索系统的分布式结构示意图；

图3为本发明的大规模数据搜索系统的整体结构及数据流示意图；

图4为记录文件和索引文件的示意图；

图5为关键词列表示意图；

图6为文档列表的cache组织结构示意图；

图7为位置信息块组织结构示意图。

具体实施方式

下面结合附图及本发明的实施例对本发明的搜索系统作进一步详细的说明。

本发明的基本思想：搜索引擎的检索效率是评价搜索引擎质量的一个重要指标，面对互联网上信息量的不断增加以及搜索引擎网页库的不断增大，对检索系统性能要求也越来越高。本发明详细介绍一个搜索引擎检索系统即数据搜索系统的设计与实现，针对搜索引擎检索系统的性能进行了描述，讨论了影响检索性能的几个因素，并分别提出改进的方法和途径。这些方法包括设计出结构更加良好的倒排文件结构，改进整数压缩编码，引入倒排文件cache，预先计算关键词与文档相关度，减少关键词相对位置计算开销，改进站点聚类算法等。

图3为本发明的大规模数据搜索系统的整体结构及数据流示意图，如图3所示，该系统主要由如下6个部分构成：倒排文件模块、数据接口模块、查询模块、切词模块及记分函数模块以及进程守护模块。其中，数据接口模块，是一组接口类，封装了每个要公开的数据的访问方法。查询模块，用于利用输入端查询条件进行搜索。切词模块与现有搜索引擎系统相同。记分函数模块，负责进行站点聚类。进程守护模块用于接受查询请求。

该系统的工作流程是，守护进程从internet或本地接收到原始查询，调用切词模块得到各个关键词并形成一棵查询树，再调用查询模块。查询模块简单的把各个关键词对应文档列表求交集，每得到一个结果则调用一次计分函数，最终得到一个聚类好的查询结果，排序并返回给守护进程。守护进程再根据请求中指定的最大返回结果数，将部分结果返回。

下面对本发明的大规模搜索系统的各个部分分别作详细说明。

1、针对倒排文件模块

为了让应用程序进行高效检索，并改进结果的排序，我们设计了新的倒排文件结构。在系统的开发过程中，这个结构被修改了很多次，每个设计都各有利弊，最终确定的结构也不是在各方面都最优。但倒排文件的设计都必须遵循几个基本的原则：

文件必须是没有二义性，可以正确的还原出数据。例如当我们保存记录<doc1><pos1pos2><doc2><pos1’pos2’...>，在读取的时候就无法确定<doc2>处保存的是出现该关键词的新的一个文档号，还是该关键词在doc1中的下一个出现位置。因此必须多保存一个词频信息，例如<doc1><tf1><pos1pos2><doc2><tf2><pos1’pos2’...>。tf1和tf2分别表示词在doc1和doc2中的出现次数。这样才可正确的还原出信息。

文件的规模应当尽量小，记录文件中每条记录应该占用尽可能小的空间，以减少读取记录时传输的数据量。方法是进行索引压缩技术[Scholer，et al.，2002]：使用变长的整数编码，用较少的空间保存较小的整数；整数使用差值存放，例如把文档号按升序排列，第一个文档号保存实际值，之后的都保存与前一个文档号的差值。关键词在文档中的位置也用类似的保存方法。差值表示法的另一个好处就是可以更方便的求多个文档列表的交集，并且更方便的计算多个关键词在同一文档中的相对位置，在后面我们还会介绍。虽然对索引进行压缩会带来额外的数据解压开销，但相对于它带来的好处，这种开销完全是值得的。

索引压缩减少了读取数据时从磁盘传输的数据量，但在检索时平均每个查询对磁盘的访问次数，更大的影响了检索效率。因此，设计倒排文件时，应当支持程序在最少次数内读取到需要的信息。例如在上一章中提到的，把文档列表连续的保存。

倒排文件的设计还必须考虑方便索引模块的建立，以及方便检索模块的操作，因此结构不应该太复杂。例如，在设计过程中参考了现有技术中的倒排文件分块组织技术，把文档根据属性的不同分块保存。表面上看查询时可以先读重要的文档列表，但在实现过程中却发现对于多个关键词组成的查询，操作起来异常的复杂，最终不得不放弃。

2、整数压缩编码方法

变长的整数编码可分为两类，字节对齐整数编码和非字节对齐整数编码。前者优势有较高的压缩比率，后者则有更高的压缩与解压效率。在搜索引擎的应用中，检索效率比索引数据占用的空间更为重要。文中对比了字节对齐编码ByteCode和非字节对齐编码Golomb[Witten，et al.，1994]，其压缩比率分别为0.3359和0.2635，解码时间比为1∶6。目前天网系统中使用的ByteCode编码在现有技术中有描述，它可对数值从0至230-1的正整数进行压缩编码。用第一个字节的最高两位表示整数所占的字节数，则1字节的压缩整数包含6个有效位，可表示整数0至63；2字节的压缩整数包含14个有效位，表示整数范围从64至214-1。3字节可表示从214至222-1，4字节可表示从222至230-1。

在新的系统设计依然使用字节对齐的整数编码方式，用ByteCodeEx表示，但与ByteCode不同，ByteCodeEx使用了可变长的位数来表示压缩整数的所占字节数，并且根据计算机的字节序(Byte Order)使用不相同的编码方式，加快解码速度。以Big Endian的字节序为例，第一字节的最高位开始，如果连续n个位为1，则表示压缩整数长度为n+1个字节，有效位从第一个为0的位开始。例如第一个字节110001101，从最高位开始连续出现2个1，则说明整数占3个字节；又例如第一个字节01100101，最高一位就是0，说明整数占1个字节，该整数为的值为99。由此我们可以得出，m个字节的压缩整数可表示的整数最大值为28×m-(m-2)-1。这种方法比ByteCode的优势是只需一个字节就可表示从0至127，对于小整数占多数的倒排文件来说，压缩率比较高，可以为每个从64至127的整数节省去一个字节的空间。但当整数的范围从221到222-1时，则会多占用一个字节。ByteCodeEx可扩展到无限大的正整数。以下是为2576933个文档建立倒排索引，对整数的使用情况统计：

可以算出，用ByteCodeEx方法节省了倒排文件的空间45763951-206389≈245MB，整数的压缩率为0.3221，比起ByteCode有不小的提高。对于Little Endian的计算机系统，编码方式略有不同，表示压缩整数长度的位从第一个字节的最低位开始，并且也先存放低字节。这样做是为了提高编码和解码的效率。

3、该数据搜索系统使用的倒排文件结构及相关定义

该倒排文件由描述文件、索引文件和记录文件组成，下面分别对它们进行定义。

3.1描述文件

描述文件记录了倒排文件自身的属性信息。可用BNF表示如下：

des-file     ＝(attribute CRLF)*CRLF

attribute    ＝name“：”value

name         ＝1*<any CHAR except CTLs or separators>

CTLs         ＝<octets 0-31 and 127>

separators   ＝

(“|“)”|“<”|“>”|“@”|“，”|“：”|“\”|<”>|“/”|“[“|“]”|“？”|“＝”|”{“|”}”|”“|”\t”

value        ＝*<any octet except CTLs>

CRLF         ＝“\r\n”

也就是说，描述文件包括零个或多个<属性名：属性值>的行，最后以一个空行为结尾。这与HTTP协议RFC2616中消息头的定义类似。现在已定义的属性有：

Byte-Order属性：表示倒排文件中使用整数的字节序，包含压缩整数和非压缩整数。如果我们使用统一的节字序，如Big Endian，那么在Little Endian的机器上使用倒排文件则需要进行字节的交换，影响效率。所以我们允许自定义倒排文件的字节序。Byte-Order的属性值可以是Big-Endian或Little-Endian。默认值为Big-Endian。

Align-Bits属性：前面说过，索引文件中保存的是关键词和其位置信息在记录文件中的偏移量。为了节省空间(主要是节省应用程序内存开销)，我们在这个文件格式中，使用了32位的偏移量。但是32位的偏移量最多可以表示4GB的空间，而当文档的数量比较多，记录文件的大小肯定是要超过4GB的。因此，这个格式中允许让记录文件中每个记录在某个边界上对齐，也就是说，让每个记录偏移量的低若干位总是0，在索引文件中只保存高32位，再通过移位来获得记录的实际偏移量。Align-bits属性就是表示移动的位数，默认为0位。由于要让记录在边界上对齐，势必引起一些空间的浪费。我们假设，Align-bits为n，倒排文件总关键词数为m。则记录文件的大小应该在4G×2n-1到4G×2n之间(如果小于前者，则Align-bits等于n-1就足够了)，平均每条记录的空间浪费是2n-1-1字节，于是，整个倒排文件中，浪费的空间总数为m×(2n-1-1)字节。浪费的空间最大可能比例为m×(2n-1-1)/4G×2n-1＜m/4G。在实际应用中，m一般不超过500万，由此可算出，这个比例不会超过0.125％。

Attr-Size属性：在这个格式中，允许关键词在每个出现它的文档中，有0个或多个字节的属性信息，例如term-><doc1><attr1><doc2><attr2><doc3><attr3>。这个属性信息的意义在本格式中无定义，完全由应用程序决定。但规定属性信息必须是整字节的，并且所有的属性信息必须等长。这个长度就是倒排文件的Attr-size属性。如果未标明，默认为0。

Uint-Encoding属性：压缩整数的编码方式。格式中有规定哪些整数是必须压缩(如文档号)，哪些是整数必须是非压缩(如记录信息偏移量)，但没有规定使用的压缩编码算法，应用程序可自行定义。Uint-Encoding属性默认为上节描述的ByteCodeEx。

3.2索引文件

索引文件的结构比较简单，文件头用4个字节的非压缩整数表示索引文件中总的关键词量，之后连续存放记录。用BNF表示如下：

idx-file    ＝term_cnt term_info*

term_info   ＝term_len term offset doclist_len

term_len    ＝<1字节无符号整数>

term        ＝*<any octet>

offset         ＝<4字节无符号整数>

doclist_len    ＝<压缩整数>

可以看出，每个记录由<term_len><term><offset><doclist_len>组成，分别表示关键词长度，关键词(长度为term_len)，关键词的出现位置信息在记录文件中的偏移量，以及关键词对应文档列表的字节长度。当我们要获得某个关键词的文档列表，首先获得关键词上述索引信息，把记录文件的文件指针移动到对应位置，再调用读操作，例如：

lseeko(fd，(u_int64_t)offset＜＜align_bits，SEEK_SET)；

n＝read(fd，buf，doclist_len)；

记录文件的文档列表信息中，包含了各文档号以及关键词在各文档中的属性信息，但不包含关键词在各文档中的位置列表信息。对于单个关键词的查询来说，位置列表信息没有必要读取，上面的信息已经足够计算相关度了。也就是说，对于单个关键词的查询，一次读操作就足够了。

3.3记录文件

记录文件是整个倒排文件中最重要，也是最复杂的部分。用BNF表示如下：

recd-file  ＝(occur padding)*

occur      ＝doclist posinfo

doclist    ＝df doc*

doc        ＝docid attr poslistlen

posinfo    ＝poslist*

poslist    ＝tf pos*

df，docid，poslistlen，tf，pos   ＝<压缩正整数>

padding    ＝<占位的字节，使记录大小总是2align_bits的整倍数>

attr       ＝<长度为attr-size字节的串>

由BNF可见，每个记录由文档列表信息(doclist)和在文档中的位置信息(posinfo)组成，doclist的开始位置用一个压缩整数保存了doclist中文档的个数，也就是词的文档频率(df)，之后连续保存每个文档(doc)的信息，包括文档号(docid)，关键词在文档中的属性(attr)和关键词在本文档中位置列表的字节长度(poslistlen)，docid使用差值存放。posinfo由df个位置列表(poslist)所组成，依次对应每一个文档。每个poslist开始位置存放了关键词在该文档中的出现次数，即词频(tf)，接下来用差值的形式连续存放各个位置(pos)。记录文件和索引文件的示意图如图2.1所示(align-bits＝3)。

可以看出，记录文件中每个记录里又包含了一级的索引，这个索引是从文档号到位置列表。但是从BNF中发现，我们只保存了每个文档的位置列表的长度，并没有保存位置列表在记录文件中的实现位置，那么我们得到一个docid之后，如何读取到位置列表呢？这就与我们对文档列表的访问方式有关。我们看到，<docid><attr><len>这个记录中，只有attr是定长的，其它两个都是变长整数，因此我们是不可能对文档列表进行随机访问的，只能顺序地读取。在搜索引擎的检索系统中，这种访问模式已经足够了。从图中我们又可以看出，所有的文档列表和位置列表都是连续存放的，所以，当我们读取文档列表的时候，只需把位置列表的长度累加起来，就可以得到下一个位置列表的相对于文档列表末尾的偏移。例如，第n个文档的位置列表，在文件中的实际位置为：

$\mathrm{offset}\&times;2^{\mathrm{align}\_\mathrm{bits}}+\mathrm{doclist}\_\mathrm{len}+\underset{i=1}{\overset{n-1}{\mathrm{\&Sigma;}}}\mathrm{poslist}\_{\mathrm{len}}_i$

其中，offset和doclist_len都是从索引文件中获得。这样的设计使程序在读取倒排文件的过程中，必须多保留一些信息，并增加了一些计算上的开销，但由此带来的好处是减少了对空间的占用，这也就减少了读取磁盘的开销，同时可能减少应用程序cache的空间开销。这个交换完全是值得的。

4、影响检索效率的主要因素

首先，我们有必要先了解一下一个查询被执行的过程。如图1.2所示，当前台服务器通过广播的方式把查询发送到检索节点上，检索节点首先对查询进行预处理，例如切词，如果支持布尔查询还必须对查询表达式进行分析生成一棵查询语法树。得到一系列的关键词之后，检索系统分别从倒排索引中找出各个关键词所对应的文档列表。一般而言，搜索引擎返回的各文档里都包含每个查询关键词，于是我们必须对获得到的文档列表求交集，查询的结果必然就落在这个交集里。接着对交集里的每一个文档，我们首先计算每个关键词与文档的相关度得分，再累加起来。这时候我们还没有利用到词在文档中的位置信息。例如我们的查询是“北京大学”，并且被切为“北京”和“大学”两个关键词，那么，交集中这两个词连续出现的文档显然相关度更高一些。此时我们就要利用到关键词在文档中的位置信息，对于那些连续出现这两个词的文档，再增加一些相对位置的得分。在算得每个文档与查询的相关度得分之后，我们还不能直接把排好序的结果返回给用户，因为结果中很多的文档都是在同一个站点之下的，对用户来说可能每个站点只需一个结果就够了，如果有需要可以再点击站内查询。于是，我们还需要根据站点对结果集进行聚类，每个站点内只保留一个或两个结果，把最重要的一些结果连同相关度得分返回给前台服务器。前台服务器收集到各检索节点发来的结果，进行归并再把得分最高的返回给搜索引擎用户。

本文现在只关心检索节点做的事情，其中切词与检索效率关系不大，我们也不讨论。其它的包含以下五个部分：

4.1获取文档列表

从倒排文件的结构中我们可以看出，要获得给定关键词的文档列表，首先要从索引文件中找到对应的入口，得到offset和doclist_len之后再到记录文件中读取文档列表信息。显然，从索引文件头开始顺序查找关键词是不现实的，与原有天网系统相同，我们把term-><offset，doclist_len>这个索引信息常驻内存。

而对于记录文件中的文档列表信息，要让它们都常驻内存似乎就有一些困难了。但根据现有技术，用户查询词的分布具有很强的局部性，大多数经常被检索的词都是集中在一个很小的范围之内的。另外，用户查询有一定的稳定性，用户在一段时间内发出的查询往往有一些相似。这两方面说明了对倒排文件使用cache的有效性，通过良好的cache结构，让尽可能多的查询词在内存中找到对应的文档列表，减少访问磁盘的开销，正是本系统中提高检索效率的一个重要方法。

4.2文档列表求交集

前面提到，从倒排索引中获得的文档列表一定是按文档号升序排列的，这就为我们求文档列表的交集带来了很多方便。新系统中，求文档交集的算法也有一些改进，由原来的每次两列进行求交，改为多列同时求交。但实验说明这一步操作并非影响检索效率的关键。

4.3计算关键词与文档相关度

对各个关键词和文档求相关度得分是检索过程中使用CPU最多的一个步骤，主要是浮点运算的操作。例如使用传统的tf*idf的计算方法，每个关键词相对于每篇文档，都至少要进行3次的取对数运算。虽然在检索系统中，对外存的访问时间是决定系统性能的关键，但如果可以节省相关度计算的时间，也可以在一定的程度上提高检索效率。

4.4计算相对位置

对于由多个关键词组成的查询，计算它们相对位置应该说是整个检索过程最耗时的部分。特别是当关键词都是高频词的时候，文档列表的交集中的文档个数可能达到上百万个。此时读取每个词在每个文档中的位置信息，如果不进行特别处理，则要进行上百万次的读盘操作。如果对关键词在文档中的位置信息进行cache，其消耗的内存要比文档列表大得多。因此，提高计算相对位置的效率也是改善系统整体性能的关键。

4.5站点聚类

站点聚类不涉及对磁盘的操作，其效率并不会构成系统的瓶颈。但新的系统还是改进了原有的算法，通过先聚类后排序的方式，减少了最终进行排序的文档量，从时间复杂度上对性能进行了优化。

在这里，我们主要讨论的是系统最底层的数据组织。这个模块为上层的模块提供了一个快速的访问索引文件的接口，同时它负责对文档列表和位置列表的cache进行组织。我们将以模块的接口为主线来分析其数据组织。

5、创建索引

要访问索引文件首先必须创建一个索引对象(index)，其接口如下：

index_t*createindex(const char*desfile，const char*idxfile，const char*datafile，size t cache max)；

前三个参数分别是描述文件，索引文件和记录文件的文件名，最后一个参数cache_max为index对象可用的文档列表cache最大值，必须根椐硬件条件来确定。在index.c文件中我们可以看到如下的定义：

当createindex被调用时，描述文件和索引文件中的内容被一次地读入内存，索引文件中的索引信息被保存在term_list域中，按照关键词升存排列，在查找时使用二分查找的方式。与原有系统使用散列查找的方法有所不同。原因是，使用散列将引起太多的内存浪费。可以大致的计算一下，假设总的关键词数为m，散列的空间至少需要3m，则至少浪费2m个指针的空间。而且每个关键词入口还至少需要一个指针来解决散列函数的冲突，于是总的多余指针开销达到3m个。假设m等于500万，则浪费的总字节数为3×500万×系统地址长度，在32位系统下大约为60MB。而由于关键词都已经一次性读入内存，对关键词的查找所占用的时间几乎可以乎略不计，在认真考虑之后系统使用了二分的查找方式。关键词列表在内存中的组织如图5所示。

关键词列表是一个指针的数组，各指针指向的内存块中保存的关键词信息。但从图中我们可以看出，这些内存块的长度并不一样，这是为了尽量节省内存的开销而使用了变长结构，这个结构的定义如下：

最后一个域term为关键词的原文，term_len表示关键词长度。在关键词之后还有一个变长整数记录了关键词所对应的文档列表信息的长度，从结构的定义上看不到。在为每个term_entry分配内存之前都必须精确计算出它所需的字节数。如果最后一个域定义为char*term，则平均每个结构会增加3个指针的额外开销。

offset域保存了关键词文档列表信息在记录文件中的偏移，这个域与doc_list域共用一个内存单元，如果该关键词的文档列表在cache中，则doc_list域指向cache中的文档列表。但我们并没有看到结构中用来标识文档列表是否在cache中的域，这是因为这个标志被存放在term_list指针数组每个指针的最低位。在使用内存分配函数(如malloc)获得内存时，得到的内存至少是与计算机系统的字长对齐的，最低两个位必然是0，这两个位可以被用来保存一些信息。除了最低位用来标识文档列表是否被cache，次低位也被利用，它被用来标识pos_info_size域的计数单位(粒度)。pos_info_size域保存的是关键词所有位置列表信息的总长度，指针次低位用于标识这个长度是以16字节为单位还是以4K字节为单位。由于指针中一些位被程序所利用，因此需要一次转换来获得实际地址，例如：

((struct_term_entry*)(*(unsigned long*)(ptr)&～MASK_ALL))

此外为了避免动态内存管理而引起的平均两个指针额外内存开销，在为term_entry分配内存时并不是直接调用malloc函数，而是通过一个专门设计的类(mbuf)来负责内存分配。该对象可把额外开销降至几乎为零，但必须保证后申请的内存先被释放。

使用完index对象，必须调用destroyindex函数将对象释放。函数原型为：

void destroyindex(index_t*index)

6、获得文件列表

6.1接口与数据组织

创建了index对象，要得到关键词对应的文档列表，首先要获得文档列表对象，其调用是：

doclist_t*getdoclist(const char*term，size_t len，index_t*index)；

第一参数term为关键词，根椐索引文件的格式定义可以包含任意字符；len表示关键词的长度；index参数为createindex函数生成的索引对象。

getdoclist函数首先从index-＞term_list找到对应的term_entry，如果该关键词的文档列表不在cache中，则把它从记录文件读到cache，如果cache已经达到最大值还要淘汰掉那些最久没有被访问到的文档列表。如图6所示，是文档列表在cache中的组织。

每个文档列表cache的结构如下：

所有文档列表cache通过lru域以链表的形式组织，由于这也是一个变长结构，因此我们用struct_size来记录下结构实际占用的空间，用于统计当前总的cache使用量。entry指回term list中对应的位置，以便当cache被淘汰时把最低位清0。offset域取自对应的term entry，因为当文档列表被读入cache时，term entry中的offset域被doc_list指针所覆盖，当cache被换出时要把它恢复。这么做的目也是为了节省内存的占用。

doclist对象内有一个指针，当对象被创建时，它指向了cache中的对应文档列表开始位置。文档列表的cache使用LRU的淘汰策略，当cache被一个doclist对象引用时，还要把它移到链表的最前端。cache中的文档列表数据以压缩的形式存放。此外，在上一节中我们提到，每个term entry中有一个域用于保存关键词位置信息总长度，并且有16字节或4K字节现两种粒度。当把文档列表从外存读到cache中的时候，如果发现其粒度为16字节，也就是说位置列表信息的总长度不超16×255字节，则会把关键词在各文档中的位置列表信息一起读入内存(根据倒排文件的格式，位置信息紧跟着文档列表信息存放)。这样当程序需要读取关键词的在各文档中的位置列表时，无需再进行磁盘的读取操作。

在获得文档列表对象之后，可调用readdoclist函数读取到文档列表中的信息：

size_t readdoclist(struct doc_entry*docs，size_t n，doclist_t*doclist)；

该函数从doclist对象中读出n个文档，并把doclist的内部指针向前移动，这类似于文件系统的read操作。但与文件系统不同，doclist不存在类似lseek的操作，这是因为cache中数据都是压缩的，只能顺序访问。在index.h中有doc_entry结构的定义：

前两个域分别为文档号与关键词在文档中的属性，调用者可直接使用。_len域记录了关键词在文档中位置信息的长度，_offset域是该文档之前所有文档_len域的总和。在2.3.3节中我们提到过，可用于计算位置列表信息在记录文件中的位置。函数的调用者并不需要直接访问这两个域，但它们在获取位置列表的时候有作用。

使用完doclist对象之后，需调用函数freedoclist将对象释放：

void freedoclist(doclist_t*doclist)；

7、获得位置列表

根据doclist对象和从doclist中读出来的某个doc entry，可获得关键词在文档中位置列表对象(poslist)。调用如下：

poslist_t*getposlist(const struct doc_entry*doc，doclist_t*doclist)；

要了解这个调用的执行过程和背后的数据组织，有必要先看看doclist对象的定义：

在上一节我们已经提到，当关键词的所有位置信息不超过16×255字节的时候，位置信息会在读取文档列表信息的时候被一次性的读入内存，并紧跟在文档列表cache之后。此时doclist对象的pos_info_cached域被置为1，pos_info域指向位置信息的起始位置。显然对于某个文档doc，它的位置列表在内存中的位置是doclist-＞pos_info+doc-＞_offset。

如关键词的位置信息超过16×255字节时，pos_info_cached域被置为0，fpos域保存了位置信息在记录文件中的起始位置。pos_info_size保存了位置信息总长度，粒度为4K(若超过255×4K，该域被置为0)。而pos_block_list是一个位置信息块的链表，在内存中的组织如图7所示：

当getposlist被调用时，首先在pos_block_list中顺序查找是否有某个块已经包含了所需的位置列表数据，如果存在则把poslist中的指针指到数据所在位置，并把该位置信息块的引用数加1；如果没有找到，则从外存中读入一个位置信息块，我们会根据总的位置信息大小，该文档位置信息的偏移，以及该文档位置信息的大小决定读入的块大小，代码如下，datasize是最终要读入的块大小：

doclist-＞pos_info_size＜＜SIZE_METRIC2_ORDER是文档列表所有位置信息的总长度，减去doc-＞_offset得到本文档以及之后所有文档的位置信息总长度，这是我们可能读入数据的最大值。如果这个值超过了我们规定的一次读入位置信息块的最大长度(POS_BLOCK_MAX)，则只读入POS_BLOCK_MAX长度的数据；此外，在极小的可能下，本文档的位置列表长度已经大于POS_BLOCK_MAX，则要把它的整个位置列表读入。显然如果POS_BLOCK_MAX的数值太大，很多无用的数据会被读入内存，因为查询的结果可能只是文档列表很小的一个子集，对于大多数文档没有必要读取它的位置列表；如果POS_BLOCK_MAX太小，则一次查询的读盘次数可能会很多。

下图是对5000个查询进行测试的结果，显示了POS_BLOCK_MAX的大小对读盘次数和响应时间的影响。测试中没有去除停用词，总文档数约250万，文档列表cache最大值500MB。

由测试数据可见只要POS_BLOCK_MAX在一个合理的范围内，对性能的影响并不太大，当大小为128K或192K时性能比较好。

对poslist对象的读取和释放分别使用函数readposlist和freeposlist：

size_t readposlist(unsigned int*poses，size_t n，poslist_t*poslist)；

void freeposlist(poslist_t*poslist)；

在释放位置poslist对象时，被它指向的位置信息块引用计数减1。但就算该引用计数已经减到0，也不会马上把该位置信息块从内存中清除，因为它很可能很快又会被新生成的poslist对象引用到。

8、文档列表求交集

对于查询Q＝<term1，term2，...termn>，在分别获得各个关键词的文档列表之后，第一步就是对这些文档列表求交集，并且我们认为查询结果就是这个交集的子集。由倒排文件的格式我们知道，文档号表是按文档号递增排列的，对于若干个有序的整数列，要求它们的交集比较简单。算法的描述如下：

查询Q＝<term1，term2，...termn>，获得doclist[1]-doclist[n]，分别为各个关键词的文档列表。初始化max_docid＝0；

算法最坏情况时间复杂度等于各文档列表长度的总和。新算法对n个文档列表同时求交，而原天网系统的算法是每次选取最短的两个文档求交。相比之下，新算法无需额外空间保存中间结果(也无需空间保存最终结果，直接交给回调函数处理)，但是当交集的结果为空时，新算法可能会慢一些，因为新算法没有先选择短的文档列表求交。总体来说，这一步操作对系统性能的影响不大。

在系统的设计之初，参考现有关于倒排文件分块的组织技术，并设计出了一种把文档列表和位置列表分块保存的倒排文件。其想法是，由于搜索引擎用户一般只关心返回结果中前几页的内容，而对于很多的查询，在一个节点上的结果就达到了几十万甚至上百万个。因此我们考虑到把文档列表根据关键词在文档中的重要性划分成若干块，在每个块中文档号都是升序排列的。再把重要性高的文档列表放在前面，在查询的时候如果这些被认为重要的文档个数已经足够多了，就可以不再读取后面的文档列表了。但这样方法在处理由多个关键词结成的查询时却有很多的麻烦。例如Q＝<tem1，tem2，...termn>，根据前面的想法，先找出各个关键词最重要的文档列表求交，如果结果数已经足够则结束。但如果结果数太少，则必须再读出某一关键词次重要的文档列表，与其它文档列表求交，如此不断直到结果数足够。显然最坏情况下，要对不同关键词的文档列表之间两两求交，总的时间复杂度为O(mⁿ)，其中m是重要性级别的个数，n为查询中总的关键词个数，成了一个指数时间复杂性问题。此时如果关键词个数很多，效率就会非常低。如果先对同一个关键词对应的文档列表先归并成一个升序序列再求交，虽然时间复杂度也达到线性，但也就失去了我们通过分块来减少从磁盘读入数据量的初衷。因此，经过考虑之后没有使用分块的倒排文件组织方式。

9、相关度计算

计算查询与文档的相关度包含两个方面：一方面是查询中各个关键词与文档的相关度，另一方面是各个关键词在文档中出现的相对位置。我们分别对它们进行讨论。

9.1关键词与文档相关度

关键词与文档的相关度也可称为关键词在文档中的权重，直观的感觉，有下面的几个因素影响关键词与文档的相关度。

1)关键词在文档中出现的次数。一般而言，如果关键词在文档中出现次数越多，也就是词频越高，则该关键词与文档的相关度越高。

2)文档集中出现关键词的文档个数。出现关键词的文档个数越多，也就是文档频率越高，则关键词与出现关键词的每个文档之间的相关度越低。例如像“的”，“在”，英文中“the”这样的词，它们与任何一个文档之间都没有什么相关度。相反有一些词只在极少数文档中出现，则它与这些文档的相关度很高。

3)文档的长度。当关键词在文档中出现的次数相同，则文档长度越短，关键词与文档的相关度越高。

4)关键词在文档中的位置。以网页为例，如果关键词出现在网页的title中或出现在正文的标题中，比起出现在网页正文中的关键词，它与网页的相关度应该高一些。

现有技术已证明了上述1)，2)点的正确性，提出了tf*idf的相关度计算方法。tf即关键词在文档中的出现频率，idf＝N/df，N为文档集中总的文档数，df即关键词的文档频率。则：

similarity(Q，D)＝f(tf)·g(idf)

在本系统的实现中，参考了现有技术中的做法，并加入了文档长度以及文档中出现关键词的域这两个量，进一步增强了相关度计算的准确性，实际使用的公式为：

$\mathrm{similarity}(Q,D)=\frac{\log (\mathrm{tf}+1)\&CenterDot;\log \left(\mathrm{idf}\right)\&CenterDot;\log \left(\mathrm{field}\right)}{\log (\mathrm{doclen}+1)}$

其中，doclen是文档长度，简单以文档总的关键词数来表示(更好的是使用文档中各个关键词的tf*idf总和)。field表示文档中出现关键词的域。在页面预处理中，我们将网页划分成了几个域：链入网页anchor text，网页title，网页摘要，网页正文，以及网页向外链接的anchor text。出现在以上几个部分的关键词，与文档的相关性依次降低。field用5个位来分别标识关键词是否在各个域中，例如关键词在网页摘要和网页正文中出现，则attr＝00110。特别的，如果关键词仅在网页的对外链接的anchor text中出现，则attr＝00001，log(attr)＝0，我们认为关键词与网页没有任何的相关度。

由上述的计算公式可以看出对一个关键词，它与文档的相关度计算至少需要4次的取对数操作，还有2次浮点乘法和1次的浮点除法。另外，需要有一块内存空间，用于存储几个文档的长度。在系统初期版本的测试中，发现这个计算时间对查询响应时间的影响非常大。我们又发现，对于文档中的任何一个关键词，根据上面的公式，它与某一文档的相关度得分总是一个固定值，于是想到了在倒排文件的建立过程中就预先计算好这个数值。根据第二章定义的倒排文件格式，允许关键词在每个出现它的文档中保存若干个字节作为属性信息，我们利用2个字节，其中高5位用于保存文档中出现关键词的域，也就是上面提到的field，低11位用于保存预先计算好的关键词与文档的相关性。这样，首先我们就省去了浮点运算的开销；其次，高5位的出现域信息可以帮助我们在多关键词的查询里，判断两个关键词是否在同一个域中出现，只需对一次简单的按位与运算，例如：

对于没有在同一个域中出现的两个关键词，没有必要计算它们在文档中的相对位置，节省了相对位置的计算时间。虽然这两个字节的属性字段增加了获取文档列表时的读磁盘开销，以及文档列表cache的使用量，但相对于这种方式带来的好处，这种开销完全值得。经测试发现这一方法使得平均每个查询节省了约一半的CPU时间。

9.2相对位置得分

原有系统中，对相对位置的计算方法并不是很完善，例如对于查询Q＝<term1，term2，term3>，只要在某个文档中3个关键词连续出现，则在查询结果中它总是排在那些关键词不连续出现的文档之前。这在某些时候就不太合理了，例如某个文档中这3个关键词并不连续出现，但它们却都出现在文档的重要位置，根据原来的算法这个文档必然被排在后面。另外，原有算法只计算从第一个关键词起，文档中最长连续出现的关键词数。这样，对于某些文档中，term1单独出现，而term2，term3连续出现，则term2和term3的相邻关系无法被发现。

另外，现有技术中也有一些相对位置得分计算方法。新的系统实现中，对于查询Q＝<term1，term2，...，termn>中的任意一个关键词termi，定义它在文档D中的最大相邻词个数max_adj(Q，i，D)为关键词termi在文档D中最大的相邻关键词个数。例如对于查询Q＝<北京，大学，图书馆>，若文档D1中出现“大学图书馆”，关键词“北京”单独出现，则max_adj(Q，1，D1)＝0，max_adj(Q，2，D1)＝max_adj(Q，3，D1)＝1；若文档D2中出现了“北京大学图书馆”，则max_adj(Q，1，D2)＝max_adj(Q，2，D2)＝max_adj(Q，3，D2)＝2。对每个关键词，计算出这个max_adj之后，用下面的公式计算查询与文档的最终得分：

$\mathrm{score}(Q,D)=\underset{i=0}{\overset{n}{\mathrm{\&Sigma;}}}\mathrm{similarity}({\mathrm{term}}_i,D)\&CenterDot;(1+\mathrm{ADJ}\_\mathrm{FACTOR}\&CenterDot;\max \_\mathrm{adj}(Q,i,D))$

ADJ_FACTOR是一个相邻因子，它越大则关键词在文档中的邻接关系被看得越重要。经测试，当它为0.8时查询结果的排序比较理想。新的计分算法使系统在最终的排序质量上有了不少的提高，但对max_adj的计算还没有找到特别巧妙的方法，计算上相当从每一个关键词起，用原来的算法计算出从它之后文档中连续出现的最大关键词数，并比较求得最大值。对于关键词数为n的查询，所需时间在最坏情况下是原有算法的n倍，这对性能有一些负面影响。在上一节提到，通过属性信息的高5位我们可以提前判断哪些关键词些不在同一个域中出现，当遇到这样的两个关键词，max_adj的计算就可以中断，节省了一些时间。但总体来说这一步是整个检索过程中最耗时的部分，其性能还有待改进。

10、站点聚类

站点聚类是指把搜索引擎查询结果中，出现在相同站点的网页聚集在一起。用户在使用搜索引擎搜寻信息时，最关心的往往不是返回结果的多少，而是如何在返回结果中最快地找到所需信息。如果搜索引擎动辄返回几十万甚至几百万文档，可能会使用户无从选择。

我们发现，如果不对检索结果进行再加工，会有很多结果都落在同一个网站之内，而落在同一个网站内的文档之间又有很大的相关性，例如往往是同一篇文章的不同部分。此时，一个比较好的解决方法就是对信息进行再组织，以层次式的方式返回给用户。另一个比较简单的方法，就是对返回的文档进行站点聚类，对于每一个站点，只在查询结果中显示得分最高的一个文档或两个文档，如果用户有需要，可再进行站内查询找到该站点内的所有文档。新系统中改进了原有的聚类算法，算法的描述如下：

对于查询Q＝<term1，term2，...，termn>，初始化avl树T。T以站点号为关键码。初始化整数cnt＝0；

假设聚类前，查询的结果数为x，聚类后的结果数为y，则上面算法的时间复杂度不超过O(xlogy)。而原有算法先对所有查询结果进行了排序，再聚类，显然时间复杂度至少为O(xlogx)。对日志中一万个查询进行测试后得出，每一个查询在每个网站内平均约有55.88个结果，因此算法对站点聚类在速度上的提高还是比较明显的。

11、查询模块接口

查询模块的接口很简单，只有一个函数。这个模块的功能只是把各个关键词的文档列表进行求交集的操作，每得到一个结果就调用一次回调函数进行处理。回调函数再进行记分，站点聚类，结果保存等操作。在query.h中定义了查询模块的接口：

int query(struct query_term*terms，size_t term_cnt，index_t*index，

score_t score，void*arg)；

其中struct query_term定义如下：

回调函数score_t的定义如下：

typedef int(*score_t)(struct query_term*，size_t，void*)；

query函数第一个参数terms为一组关键词，term_cnt为关键词个数。每个关键词的类型为struct query_term，其中前两个域分别为关键词的文本和关键词的长度。avail域为用户可利用域，query函数完全忽略它。当每算出一个交集中的结果，score回调函数被调用，它的三个参数就分别为query函数的前两个参数和最后一个参数，其中最后一个参数也为用户自定义。当回调函数被调用时关键词对应的文档列表对象和文档分别保存在doclist域和doc_entry域中，并且必然有terms[0]-＞doc_entry-＞docid＝＝terms[1]-＞doc_entry-＞docid＝...＝terms[n-1]-＞doc_entry-＞docid。如果回调函数有需要可调用getposlist得到关键词在文档中的位置列表，例如：

在实现应用中，每个term_entry结构中的avail域被用来指明该关键词在查询中是否要求与前一个关键词邻接(反映在查询串中即两个关键词之间是否有空格)，arg参数指向一个_score_args的结构，其中保存了avl树等数据。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims (3)

1.一种大规模数据搜索系统，其特征在于，其主要包括倒排文件模块、数据接口模块、查询模块、切词模块及记分函数模块以及进程守护模块，其中：

所述倒排文件模块，用于搜索系统能够快速找到查询词对应的文档列表；

所述数据接口模块，是一组接口类，封装了每个要公开的数据的访问方法；

所述查询模块，用于利用输入端查询条件进行搜索，将各个关键词对应文档列表求交集；

所述切词模块，用于切词并得到各个关键词并形成一棵查询树；

所述记分函数模块，负责进行站点聚类，得到聚类好的查询结果，排列并返回给守护进程模块；以及，

所述守护进程模块，用于接受查询请求，并根据查询请求中指定的最大返回结果数，将部分结果返回。

2.根据权利要求1所述的大规模数据搜索系统，其特征在于，所述倒排文件模块，采用新的倒排文件格式，其包含描述文件、索引文件和记录文件，支持程序的快速访问。

3.根据权利要求1或2所述的大规模数据搜索系统，其特征在于，所述倒排文件模块的描述文件，包括倒排文件自身的属性信息，包括：

Byte-Order属性：表示倒排文件中使用整数的字节序，包含压缩整数和非压缩整数；

Align-Bits属性：使用了32位的偏移量，Align-bits属性表示移动的位数；

Attr-Size属性：在这个格式中，允许关键词在每个出现它的文档中，有0个或多个字节的属性信息；这个属性信息的意义在本格式中无定义，完全由应用程序决定；该属性信息必须是整字节的，并且所有的属性信息必须等长；这个长度就是倒排文件的Attr-size属性；

Uint-Encoding属性：压缩整数的编码方式。

Images