CN101136016A - 一种全文检索系统的索引在线更新方法 - Google Patents

Abstract

本发明公开了一种新的全文检索系统的索引在线更新方法。该方法通过辅助索引实现全文检索系统的索引在线更新。将新增文档加入到辅助索引中，将被删除文档采用布尔向量标识，从而实现索引的实时更新并保证索引的一致性，并通过与主索引的合并避免系统长期更新操作导致的系统性能下降。该发明方法实现了在不影响全文检索系统的检索功能的情况下，保证索引更新的实时性和一致性。

Description

一种全文检索系统的索引在线更新方法

技术领域

本发明属于智能信息处理技术，具体涉及的是一种全文检索系统的索引在线更新方法。

背景技术

随着计算机技术及网络技术的迅速发展，电子文档数目急剧增长。如何在这海量的信息里面快速、全面、准确地查找所需要的资料信息已经成为人们普遍关注的问题，也成了研究领域内的一个热门课题。大部分电子文档是用自然语言写成的非结构化的文本数据，全文检索技术是目前处理文本数据的重要手段。

全文检索有多种实现方式，包括倒排索引，后缀数组和签名文件等。

一般索引的对应关系是从“文档号”到“文档中所有的词”的对应。倒排索引把这种关系倒转过来，变成从“词”到“出现该词的所有文档号”，从而能快速地通过词检索到出现这些词的所有文档。实际应用中，倒排索引中通常还会包括词在文档中出现的次数以及具体位置等信息。为了方便检索，倒排表通常是有序的。

以下是倒排索引的举例：

设有两篇文章1和2：

文章1的内容为：Tom lives in Guangzhou，I live in Guangzhou too。

文章2的内容为：He once lived in Shanghai。

1)首先我们要取得这两篇文章的关键词，通常我们需要采取如下处理措施：

a.我们现在有的是文章内容，即一个字符串，我们先要找出字符串中的所有单词，即分词。英文单词由于用空格分隔，比较好处理。中文单词间是连在一起的需要特殊的分词处理。

b.文章中的”in”，“once”“too”等词没有什么实际意义，中文中的“的”“是”等字通常也无具体含义，这些不代表概念的词可以过滤掉。

c.用户通常希望查“He”时能把含“he”，“HE”的文章也找出来，所以所有单词需要统一大小写。

d.用户通常希望查“live”时能把含“lives”，“lived”的文章也找出来，所以需要把“lives”，“lived”还原成“live”。

e.文章中的标点符号通常不表示某种概念，也可以过滤掉。

经过上面处理后，文章1的所有关键词为：[tom][live][guangzhou][i][live][guangzhou]。

文章2的所有关键词为：[he][live][shanghai]。

2)有了关键词后，我们就可以建立倒排索引了。上面的对应关系是：“文章号”对“文章中所有关键词”。倒排索引把这个关系倒过来，变成：“关键词”对“拥有该关键词的所有文章号”。文章1，2经过倒排后变成：

关键词文章号

guangzhou 1

he 2

i 1

live 1，2

shanghai 2

tom 1

通常仅知道关键词在哪些文章中出现还不够，我们还需要知道关键词在文章中出现次数和出现的位置，通常有两种位置：a)字符位置，即记录该词是文章中第几个字符(优点是关键词亮显时定位快)；b)关键词位置，即记录该词是文章中第几个关键词(优点是节约索引空间、词组(phase)查询快)。

加上“出现频率”和“出现位置”信息后，我们的索引结构变为：

关键词文章号[出现频率]出现位置：

guangzhou 1[2]3，6

he 2[1]1

i 1[1]4

live 1[2]，2[1]2，5，2

shanghai 2[1]3

tom 1[1]1

以live这行为例我们说明一下该结构：live在文章1中出现了2次，文章2中出现了一次，它的出现位置为“2，5，2”这表示什么呢？我们需要结合文章号和出现频率来分析，文章1中出现了2次，那么“2，5”就表示live在文章1中出现的两个位置，文章2中出现了一次，剩下的“2”就表示live是文章2中第2个关键字。

后缀数组索引是由Manber和Myers在1993年提出的一个空间效率非常高的文本索引结构，这种结构记录了文本中各后缀的字典序索引，它把文本中的所有后缀按照词典序存放其在文本中起始位置的一个列表。

签名文档是指把文档中的关键词散列成F位的位串，顺序访问原文档的关键词，把散列所得的位串依次存入文件。

以下是其匹配思想：假设我们现在要判断字符串A和字符串B是否匹配，首先把A和B分别散列成数字hash(A)和hash(B)，如果hash(A)！＝hash(B)则A！＝B；然而hash(A)＝hash(B)不能说明A＝B。

下面是具体的匹配例子：

关键词x[0..5]：AACTCT Hash(x[0..5])＝17579；

文本y[0..9]：GCAACTCTCA Hash(y[0..5])＝17819；

文本y[0..9]：GCAACTCTCA Hash(y[1..6])＝17533；

文本y[0..9]：GCAACTCTCA Hash(y[2..7])＝17579。

签名文件具有以下优点：

1)文件组织简单，基本和原文档顺序一致；

2)维护容易，生成，插入，删除都很方便；

3)所需空间小，特别是采用重叠编码之后。

其中倒排索引是应用最广泛的方式，它对于以单词为基础的查询具有很好的性能。

在实际应用中，文档集合通常是在不断变化的，新的内容会被添加进来，过时的内容会被删除或更新。如果随着文档集合的变化，不对索引及时进行更新，检索结果的质量将会不断下降，检索不到新加入的文档，或者检索到已经不存在或者内容已经改变的文档。因此，索引必须持续更新，以便及时反映文档集合的变化。

索引更新最简单的方式是离线重建索引，即：抛弃过时的索引库，用最新的数据完全重建索引。Web检索引擎由于更新数据量大，对检索效率要求高，早期多采取这种方式。

索引更新的另一类常用的方式是在线更新。典型的在线更新方法是Clarke等人在全文检索系统MultiText中采用的更新策略。MultiText的索引结构在磁盘上以一个首尾相连的环形文件的方式存放。(通常的文件系统并不直接支持环形的文件，但可以通过一个抽象层用普通文件模拟环形文件。)在任何时候，这个文件都由3个连续的部分组成：待更新的索引、已更新的索引和空闲空间。

检索时，首先需要确定检索条件在索引的哪一部分中。由于索引在磁盘上按字典顺序排列，只需要记住这两部分索引的边界，无需访问磁盘。因为两部分索引(待更新和已更新的)都具有完整的倒排索引结构，可以使用通常的方法找到索引项，理想情况下只需要一次磁盘访问就可以取得所需的posting list(位置数组)。

更新时，新添加的文档经过处理生成的posting暂存在内存缓冲区中。一个后台进程不断地读取索引的待更新部分，与内存中的posting合并后，附加到已更新部分的末尾。在此过程中，待更新部分不断缩短，而已更新部分不断增长，直至待更新部分全部转变为已更新部分为止。

MultiText的在线更新策略虽然实现了索引的持续更新，并且具有较好的检索效率，但还存在多项不足：

只适用于添加新文档，不适用于频繁删除和修改文档的应用；

不能保证实时性，新增文档要保证能被用户检索到，至少要等待一个完整的更新周期；

不能保证一致性，在合并过程中，词典始终分为已更新和未更新两部分，在检索新增文档时，会出现有时能检索到而有时又检索不到的情况。

由前面的分析可以看出，索引更新的困难在于为了更新少数文档，往往需要改写大部分索引库，虽然索引库中绝大多数文档与这次更新无关。以MultiText为例，即使为了更新一篇文档，也需要重写整个索引库。

发明内容

本发明的目的在于提出一种新的全文检索系统的索引在线更新方法，使得在不影响全文检索系统的检索功能的情况下，保证索引更新的实时性和一致性。

本发明的具体实现方法为：一种新的全文检索系统的索引在线更新方法，包括以下步骤：

1)将索引库分成两部分：主索引库和辅助索引库；

2)读取待更新索引的内容；

3)判断待更新索引的操作类型是新增还是删除操作，分别进行如下处理：

A：如是新增操作，在辅助索引库中加入待更新索引的内容，

B：如是删除操作，在辅助索引库中保存文档删除信息。

所述主索引库和辅助索引库的分类标准为：所述主索引库由占绝大多数的很少改变的文档组成，辅助索引由经常改变的少数文档组成。

进一步，判断辅助索引是否需要合并到主索引中，如果需要合并，将需合并的辅助索引以及文档删除信息合并到主索引中，并清空已合并的辅助索引和文档删除信息。

进一步，判断是否还有待更新索引的内容，如果有则跳转到步骤2)，否则，判断是否有终止更新索引的请求，如有，结束操作，否则，等待一段时间后继续进行判断操作。

判断辅助索引是否需要合并到主索引中，按照以下A、B或C的标准执行：

A：预先设置辅助索引的文件大小或容纳的文档个数，当超过设置的文件大小或文档个数时，则进行合并；

B：系统的繁忙程度低于预设的参数时，则进行合并；

C：A、B两者的结合。

辅助索引与主索引结构相同，同时完整存储于内存和磁盘上，负责暂存最近新增文档。

主索引和辅助索引可以是倒排索引，后缀数组和签名文件等索引结构形式。

主索引库和辅助索引库的具体分类需根据具体应用环境来决定，包括应用的数据总量、每天/每小时新增数据量、硬件配置情况。

文档删除信息采用布尔向量进行保存，每个文档对应于布尔向量的一位；文档删除信息也可采用文档标号列表方式保存。

本发明的效果在于：本发明中通过利用辅助索引实现全文检索系统的索引在线更新，从而达到在不影响全文检索系统的检索功能的情况下保证索引更新的实时性和一致性的索引在线更新的目的。实验表明，在普通PC环境下(CPU为P4 2.0G，内存为1.0GB)，本发明实现的全文检索达到的索引实时在线更新和保证完整性的目的。实验中当辅助索引文档数小于10,000时，新增操作具有很快的速度(均在0.3秒以下)，删除操作速度不受辅助索引影响，而修改操作是删除操作和添加操作的组合，耗时约为两者之和。

附图说明

图1是本发明所述方法的流程图。

具体实施方式

下面结合附图对本发明的具体实施方式进行详细阐述。

实际应用中发现索引库的更新操作通常具有局部性。根据这一特点，本发明方法中将索引库分成两部分：占绝大多数的很少改变的文档组成的主索引和最近经常改变的文档组成小的辅助索引。

这里的绝大多数、很少改变，需根据具体应用环境来决定，包括应用的数据总量、每天或每小时新增数据量、硬件配置情况等来决定。例如：在应用中，将每天更新的内容放在辅助索引库中，在半夜系统空闲时将辅助索引合并到主索引中。

由于辅助索引容量小，在其上的更新操作可以很快完成，保证了实时性；而且更新操作所需时间、临时空间和计算资源都较小，从而避开了分步更新带来的一致性问题。

如果辅助索引象主索引那样放在磁盘上，则会引入性能问题。因为检索的性能取决于磁盘访问次数，如果辅助索引放在磁盘上的话，那么原本一次磁盘访问就可以完成的检索，该方法中至少需要两次磁盘访问，开销大了近一倍。既然辅助索引尺寸远小于主索引，完全可以全部放在内存中。但考虑到一致性问题，辅助索引不能只放在内存，否则一旦系统发生故障，辅助索引的全部内容将丢失，索引库就不完整了。因此，磁盘上也需要一个备份。

本发明中的辅助索引是：与主索引结构相同，但同时完整存储于内存和磁盘上，负责暂存最近新增文档的索引。

下面对本发明的具体实现方法进行举例。

本发明在普通PC环境下(CPU为P4 2.0G，内存为1.0GB)进行实验，按照本发明的方法实现全文检索的索引在线更新。

如图1所示，具体包括以下步骤：

1)读取待建索引的内容；

2)如果待建索引的操作类型是修改文档则将该修改操作分解成删除操作和新增操作；

3)如果操作类型是新增文档则执行步骤4，如果操作类型是删除文档则执行步骤8；

4)在辅助索引上加入新增文档内容的索引；

5)判断辅助索引是否需要合并到主索引中，如果需要合并，则执行步骤6，否则跳转到步骤9；

6)将辅助索引和文档删除信息合并到主索引中；

7)清空辅助索引和用于保存文档删除信息的布尔向量，跳转到步骤9；

8)对于删除文档操作，将保存文档删除信息的布尔向量的相应位设置为1；

9)判断是否还有待建索引的内容，如果有则跳转到步骤1，否则执行步骤10：

10)判断是否有终止建索引的请求，如果有则退出，否则等待一段时间后跳转到步骤9。

对于上述步骤中的删除操作，使用一个布尔向量处理删除操作。该布尔向量的每一位对应一篇文档。删除一篇文档时就把对应的位设置为”1”。检索和索引合并算法都会跳过对应为”1”的文档，从应用角度来看达到了删除的效果，在进行索引合并时，这些被标为”1”的文档由于被合并算法跳过，将真正从主索引中消失。

由于本发明既可采用倒排索引结构的方式，也可采用充后缀数组和签名文件检索的方式，在操作方法上并没有不同。本实验中采用倒排索引结构作为主索引和辅助索引的索引结构，通过判断辅助索引中包含的文档数量和系统繁忙程度决定是否进行索引的合并。

实验选用的数据是从因特网上抓取的新闻类中文网页，提取出网页的新闻内容作为文本文件，每个文件为一篇新闻稿件，共100万篇，共2.68GB。

实验主要考察如下两个问题：

使用辅助索引后更新一篇文档需要多长时间，能否满足实时性要求？

使用辅助索引对检索效率影响如何？

实验中使用不同的辅助索引大小(以容纳的文档个数为单位)测量了增量新增、删除、更新一篇文档所需平均时间。实验结果如表1所示，当辅助索引文档数小于10,000时，新增和删除操作具有很快的速度(均在0.3秒以下)。也就是说，只要将辅助索引文档数限制在10,000以下，本发明方法有很好的实时性。同时，从实验结果还可以看出删除操作速度不受辅助索引影响，而修改操作是删除操作和添加操作的组合，耗时约为两者之和。实验说明本发明方法具有很好的实时性。

表1：主索引文档数为1百万时，增量索引时间开销随辅助索引文档数变化情况

辅助索引文档数	添加耗时(秒)	删除耗时(秒)	修改耗时(秒)
				1	0.010	0.205	0.220
10	0.042	0.213	0.292
				100	0.051	0.204	0.271
1,000	0.070	0.244	0.306
				10,000	0.223	0.200	0.439
100,000	3.31	0.376	4.05

表2的实验结果表明，索引的更新时间与主索引的大小没有关系，因为索引的更新过程完全是在辅助索引上进行了。

表2：辅助索引文档数为1万时，增量索引时间开销随主索引文档数变化情况

主索引文档数	添加耗时(秒)	删除耗时(秒)	修改耗时(秒)
				1,000	0.223	0.200	0.439
10,000	0.223	0.200	0.439
				100,000	0.223	0.200	0.439
1,000,000	0.223	0.200	0.439

为了考察辅助索引对检索速度的影响，实验中用100个检索词进行检索，计算检索平均时间。实验结果见表3。以无辅助索引的时间为基准，增加的部分可以看作辅助索引的开销。辅助索引大小在10000以下时，开销都小于5％，可以说是用户无法感知的。

表3：主索引文档数为1百万时，检索速度随辅助索引文档数变化情况

辅助索引大小	检索耗时(秒)	辅助索引开销
			0	0.422	0％
1	0.430	1.8％
			10	0.429	1.7％
100	0.431	2.1％
			1,000	0.433	2.6％
10,000	0.439	4.1％
			100,000	0.981	132％

综合以上实验结果，本发明提出的方法实现了全文检索系统的索引在线更新，在具有很好的检索性能的情况下，保证索引更新的实时性和一致性。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (10)

1.一种全文检索系统的索引在线更新方法，包括以下步骤：

1)将索引库分成两部分：主索引库和辅助索引库；

2)读取待更新索引的内容；

3)判断待更新索引的操作类型是新增还是删除操作，分别进行如下处理：

A：如是新增操作，在辅助索引库中加入待更新索引的内容，

B：如是删除操作，在辅助索引库中保存文档删除信息。

2.如权利要求1所述的全文检索系统的索引在线更新方法，其特征在于，所述主索引库和辅助索引库的分类标准为：所述主索引库由占绝大多数的很少改变的文档组成，辅助索引由经常改变的少数文档组成。

3.如权利要求2所述的全文检索系统的索引在线更新方法，其特征在于，所述步骤3)进一步包括以下操作：

4)判断辅助索引是否需要合并到主索引中，如果需要合并，将需合并的辅助索引以及文档删除信息合并到主索引中，并清空已合并的辅助索引和文档删除信息。

4.如权利要求3所述的全文检索系统的索引在线更新方法，其特征在于，所述步骤4)进一步包括以下操作：

5)判断是否还有待更新索引的内容，如果有则跳转到步骤2)，否则，判断是否有终止更新索引的请求，如有，结束操作，否则，等待一段时间后继续进行判断。

5.如权利要求4所述的全文检索系统的索引在线更新方法，其特征在于，判断辅助索引是否需要合并到主索引中，按照以下A、B或C的标准执行：

A：预先设置辅助索引的文件大小或容纳的文档个数，当超过设置的文件大小或文档个数时，则进行合并；

B：系统的繁忙程度低于预设的参数时，则进行合并；

C：A、B两者的结合。

6.如权利要求1-5任意一项所述的全文检索系统的索引在线更新方法，其特征在于，所述辅助索引与主索引结构相同，同时完整存储于内存和磁盘上，负责暂存最近新增文档。

7.如权利要求6所述的全文检索系统的索引在线更新方法，其特征在于，主索引和辅助索引可以是倒排索引，后缀数组和签名文件等索引结构形式。

8.如权利要求6所述的全文检索系统的索引在线更新方法，其特征在于，所述文档删除信息采用布尔向量进行保存，每个文档对应于布尔向量的一位。

9.如权利要求6所述的全文检索系统的索引在线更新方法，其特征在于，所述文档删除信息采用文档标号列表方式保存。

10.如权利要求2所述的全文检索系统的索引在线更新方法，其特征在于，所述主索引库和辅助索引库的具体分类需根据具体应用环境来决定，包括应用的数据总量、每天或每小时新增数据量、硬件配置情况。

Images