利用Xapian构建自己的搜索.doc

1. 前言

1.1. Xapian与开源
Xapian的官方网站是http://www.xapian.org，这是一个非常优秀的开源搜索引擎项目，搜索引擎其实只是一个通俗的说法，正式的说法其实是IR（Information Retrieval）系统。Xapian的License是GPL，这意味着允许使用者自由地修改其源码并发布之。Xapian的中文资料非常少，可以说现在互联网上连一篇完整详细的Xapian中文介绍文档，更别说中文API文档了。其实，Xapian的英文资料也不多，除了官方网站上的Docs和Wiki外，还有一些网站上的邮件列表，在这方面跟Lucene没得比。当然，Lucene现在已经发展到2.x版本了，而Xapian的最新版本才1.012，国外开源项目一般对版本号控制得比较严格，一个项目一般到了1.x才算稳定和成熟的。

1.2. Xapian可以运行在那些平台？
Xapian由C++++编写，但可以绑定到Perl, Python, PHP, Java, Tcl, C# 和Ruby甚至更多的语言，Xapian可以说是STL编程的典范，在这里您可以找到熟悉的引用计数型智能指针、容器和迭代器，甚至连命名也跟STL相似，相信一定能引起喜好C++++和STL的你的共鸣（实际上，很少C++++程序员完全不使用STL）。由于Xapian使用的是STL和C运行时库，因此具有高度可移值性，官方说法是可以运行在Linux、 Mac OS X、 FreeBSD、 NetBSD、 OpenBSD、Solaris,、HP-UX,、Tru64和IRIX,，甚至其它的Unix平台，在Microsoft Windows上也跑得很好。当然，并不能像Java那样“一次编译，到处可以运行”，当移植到其它平台时，一般来说是需要重新编译的。至于如何在Windows32位系统下编译Xapian，请查阅我以前写的文章《nmake在windows平台下编译xapian》。

1.3. Xapian的特性
依官方的说法，Xapian是一个允许开发人员轻易地添加高级索引和搜索功能到他们的应用系统的高度可修改的工具，它在支持概率论检索模型的同时也支持布尔型操作查询集。 从功能特性上来说。Xapian和Lucene有点相似，两者都具有Term、Value（在Lucene里称为SortField）、Posting、Position和Document，不过Xapian没有Field的概念，这直接导致Xapian在使用上比Lucene麻烦了那么一点。但这完全不是问题，通过一些小技巧，完全可以自己在Xapian中实现Filed的概念。在Lucene里还有一个叫Payload的元素，即词条 (Term) 的元数据或称载荷。举一个例子，“回家吃饭吧”和“快回家吃饭”这两个句子都带有“吃饭”这个词语，但在检索的时候怎样才能将语气表达出来呢？虽然可以添加Term来解决这个问题，但由于Term的索引信息和存储信息是分开放的，相对来说I/O性能较差，Payload就是应这个问题而生的，因为Payload信息是直接放在索引里的。由于对Xapian的研究还不是很深，Xapian里是否有类似Payload这个概念，还需要继续研究。

1.4. Xapian与搜索
搜索的目的是将结果数据展现给终端用户，搜索引擎与普通的数据库查询最大的区别就在于查询。Xapian提供了多种的查询机制。 概率性搜索排名 – 重要的词语会比不那么重要的词语得到更多的权重，因此与权重高的词语关联的Documents会排到结果列表的更前面。 相关度反馈 – 通过给予一个或多个Documents, Xapian可以显示最相关的Terms以便扩展一个Query，及显示最相关的Documents。 词组和邻近搜索 -- 用户可以搜索一个精确短语或指定数组的词组。 全方位的布尔型搜索器，例如 ("stock NOT market", etc)。 支持提取搜索关键字的词干，例如当搜索“football”的时候，当Documents中含有"footballs" 或"footballer"的时候也被认作符合。这有助于找到相关结果，否则可能错过之。词干提取器现在支持Danish、Dutch、 English、 Finnish、 French、 German、 Hungarian、Italian、 Norwegian、Portuguese、Romanian、 Russian、Spanish、Swedish和Turkish。 支持通配符查询，例如“xap*”。 支持别名查询，打个比方，C++++会自动转为CPlusPlus，C#则自动转为CSharp。 Xapian支持拼写纠正，例如xapian会被纠正为xapain，当然这必须基于词组已经被索引了。这特性跟Google提供的“你是不是想搜索xxx”有点相似。

1.5. Xapian的存储系统
Xapian现在的版本默认是使用flint作为存储系统，flint是以块的形式来存储，默认每块是8K，理论上每一个文件最大可以达到2048GB。当然，在旧式的文件系统，例如FAT/FAT32是不可能实现的。熟悉Windows内存管理机制的朋友一定知道使用Windows32位系统每个进程的总虚拟地址空间只有4GB，而用户模式连2GB都不够（Windows2003可以将用户模式扩展到3GB左右），因此应用程序不可能一次过将整个Database文件读取到内存中，通常的做法是使用内存映射文件，先预订地址空间，在真正使用的时候才调拨内存，而内存分页粒度是4k，也就是说内存中每一页是4k，而在IA64系统中，内存分页粒度是8k。在内存中，除了页外，还有区块，X86和IA64的内存区块的粒度都是64k。Xapian这样存储数据估计是为了在各个平台上都能实现数据对齐，数据对齐对于cpu运算寻址是非常重要的，而8和64都是4的倍数，因此大胆猜想Xapian以8k作为存储系统的默认块大小是为了在性能和兼容性中取得最平衡和最优值。 Xapian使用unsigned 32-bit ints作为Documents的id值，因此在每个Xapian的Database中，最多可容纳40亿个Documents。而Xapian的Terms和Documents都是使用B-树来存储的，其实很多数据库系统（这里所指的是关系数据库）的索引都是用B-树或B++树来存储的，具有增删改查比较方便迅速的特点，缺点则是如果索引被删除后的空间不能重复利用，为了提高性能，通常要经常重建索引。

1.6. Xapian的性能
搜索引擎的性能是用户非常关心的一部分，Xapian的性能如何？官方的原话如下：The short answer is "very well" - a previous version of the software powered BrightStation's Webtop search engine, which offered a search over around 500 million web pages (around 1.5 terabytes of database files). Searches took less than a second.。在5亿个网页共1.5TB大小的文件中，搜索只需要小于一秒就完事了。当然，这跟运行的平台和机器是密切相关，在我们自己构建好Xapian搜索引擎应用后，我们也可以测测具体的速度。

1.7. Xapian的绝佳范例
Xapian的官方网站上有一个绝佳的使用范例，这个称为Omega的项目甚至可以开箱即用作为一个CGI应用程序。Omega附带了Omindex和ScriptIndex这两个索引生成工具，可以将硬盘上的html，pdf，图片甚至视频影片索引起来并生成Database，通过操作这些由Omindex或ScriptIndex生成的Database，Omega提供了搜索这些文件的功能。

2. 检索
经过前面几篇的介绍，如果再参考一下Omega的话，估计应该可以顺利创建database和往database里添加document了。有了数据，下一步关心的当然是怎样将它们查出来，在一个IR系统（不单止Xapian）中，检索的方式是多元化的，排序则是多样化的，结果则是人性化的，这就是跟关系数据库相比的最大优势。由于内容较多，因此将检索、排序和取得结果分开讲述，这一篇先讲述如何检索。 IR系统有这么多的好处，因此终端用户对它是有很高期望的，世事万物总不会完美的，于是IR系统有三个评价标准：召回率、准确率与查询效率。三个指标相互矛盾，只有取舍、不能调和，这亦是一个博弈的过程，使用者关心不同的指标，自然会采用不同的观点和做法。拿Web搜索引擎来说，查询效率肯定是摆在第一位的，其次才能考虑准确率和召回率。看字面看上去，大家心里估计对准确率还有个谱，但召回率又如何解释呢？

2.1. 准确率和召回率
有时候，准确率也称为精度，举个例子，一个数据库有500个文档，其中有50个文档符合定义的问题。系统检索到75个文档，但是只有45个符合定义的问题。
召回率R=45/50=90%
精度P=45/75=60%

本例中，系统检索是比较有效的，召回率为90%。但是结果有很大的噪音，有近一半的检索结果是不相关。通常来说，在不牺牲精度的情况下，获得一个高召回率是很困难的。对于一个检索系统来讲，召回率和精度不可能两全其美：召回率高时，精度低，精度高时，召回率低。对于搜索引擎系统来讲，它可以通过搜索更多更多的结果来查到更多相关结果，从而提高召回率(查全率)，但也会导致查到更多不相关结果，从而降低了搜索结果的精度(查准率)。因为没有一个搜索引擎系统能够搜集到所有的WEB网页，所以召回率很难计算。所以一般来说，不会单独的使用召回率或精度，而是在其中一个值固定的基础上，讨论另一个值。如当召回率为60%时的精度值变化情况。因此在召回率与准确率中，Web搜索引擎会更倾向于后者，因为终端用户最想得到的他们要想得到的数据，而不是一堆似是而非的数据。 但是，对于一个传统的图书信息检索系统，情况会大不相同——书籍与文章有良好的关键字索引，包括标题、作者、摘要、正文、收录时间等定义明确的结构化数据，文档集合相对稳定并且规模相对较小，想更深一层，终端用户可能只知道某图书名的其中一两个字，那么如果在较低的召回率下，此用户可能会铩羽而归。 说到这里我们应该差不多知道IR系统在不同的应用场合下是有不同的准确率和召回率作为评价指标的，而准确率和召回率则是由分词策略直接影响的，拿我们最关心的中文分词来说，分词策略一般有以下几种： - 第一种，默认的单字切分。这种分词策略实现起来最简单，举个例子，有以下句子：“我们在吃饭呢”，则按字切分为[我]、[们]、[在]、[吃]、[饭]、[呢]。按这种方法分词所得到的term是最少的，因为我们所使用的汉字就那么几千个，但随便所索引的数据量的增大，索引文件的增长比例却比下面的几种模型都要大，虽然其召回率是很高的，但精确²¾确率。 - 第二种，二元切分，即以句子中的每两个字都作为一个词语。继续拿“我们在吃饭呢”这个句子作例子，用二元切分法会得到以下词：[我们]、[们在]、[在吃]、[吃饭]、[饭呢]。这种切分方法比第一种要好，精确率提高了，召回率也没降低多少（实际上两者都不高，太中庸了）。 - 第三种：按照词义切分。这种方法要用到词典，常见的有正向最大切分法和逆向最大切分法等。我们再拿“我们在吃饭呢”作为例子。使用正向切分法最终得到词语可能如下：[我们]、[在吃]、[饭]、[呢]，而使用逆向最大切分法则可能最终得到以下词语：[我们]、[在]、[吃饭]、[呢]。只要处理好在庞大的词典中查找词语的性能，基于词典的分词结果会挺不错。
· 第四种:基于统计概率切分。 这种方法根据一个概率模型，可以从一个现有的词得出下一个词成立的概率，也以“我们在吃饭呢”这个句子举个可能不恰当的例子，假设已经存在[我们]这个词语，那么根据概率统计模型可以得出[吃饭]这个词语成立的概率。当然，实际应用中的模型要复杂得多，例如著名的隐马尔科夫模型。 在实际的中文分词应用中，一般会将按词典切分和基于统计概率切分综合起来，以便消除歧义，提高精确率。

2.2. 性能
前面提到，按单字切分的查询性能可能反而是最差的，咋一眼看上去，这种分词方式低精度高召回率是没错，但为什么说它性能不好呢。为了方便解释，我们假设有两万篇文章需要被存储和索引，假设文章里所有内容都是汉字，我们常用的汉字有4000～5000个，那么最理想的情况下平均每个汉字索引了4～5篇文章，可惜实际上有很多汉字的出现频率是非常高的，就拿上面的[我]、[们]、[在]、[吃]、[饭]、[呢]这几个汉字来说，在每篇文章中出现的概率估计至少得有70%～80%。 常见的存储方式是将索引和数据（即文章内容）分开存放，以各种树（红黑树、AVL树或B*树）来存储方式问题其实还不大，但由于我们现在普遍佼Œ在一棵高度为2的B*树中，最多只需要读取2个结点就可以到达目标结点，也就是说控制磁头的机械臂只移动了两次。在这个时候，良好的数据结构的优越性就显示出来了。 当然，这只是纯粹以硬盘/磁带机为中心来讨论，在实际应用中架构会更加良好，而且如果只有两万篇文章，当我们的主内存足够大的时候，甚至可以一次过将所有文章读到内存中以避免进行硬盘I/O操作，只是这样也带来了写入数据时非常缓慢的尴尬。现在的数据库或IR系统的数据文件动辄几个GB，因此怎样最大限度避免进行频繁的硬盘I/O读写还是放在提高性能的第一位的。 不过千万别以为IR系统一切都比关系数据库要好，IR系统的其中一个弱点是插入、修改和删除都相对缓慢，因为是中间要经过多层的工序处理，所以IR系统的首要任务是检索，其次才是存储。

2.3. 布尔型检索
虽然IR系统会帮我们分词，但有时候我们却想“帮助”IR系统理解我们要搜索什么。例如，我们可能会在百度或Google的搜索栏里输入：“我们 吃饭”来寻找我们感兴趣的关于“我们”和“吃饭”的文章，而不是直接输入“我们吃饭”来搜索文章。这两种的输入得到的结果是完全不同的，因为“我们吃饭”已经成为了Google的IR系统里的其中一个term了。 像“我们 吃饭”这样的输入，其实就是布尔型检索。在Xapian里，则是将多个terms用AND、 OR或AND_NOT连接起来，举个例子：
t1 索引了 documents 1 2 3 5 8
t2 索引了 documents 2 3 6
那么：
t1 AND t2 检索得 2 3
t1 OR t2 检索得 1 2 3 5 6 8
t1 AND_NOT t2 检索得 1 5 8
t2 AND_NOT t1 检索得 6

在很多系统中，这些documents并没有根据它们之间的相关度来排序的；但在Xapian里，布尔型风格的查询都可以在检索得出documents集合结果后，然后使用概率性的排序。

2.4. 概率性IR和相关度
布尔型检索是最常用的，但在IR系统中，其还没能担大旗，因为使用布尔型检索得到的结果并没有按任何机制使其能变得对用户更友好，在这种情况下，用户必须对这个IR系统有充分的了解才能更有效地使用之。虽然如此，但只有纯粹的布尔型检索的IR系统依然活得好好的。 相关度是概率模型里的核心概念，可以将documents的集合按相关度来排列。本质上，当某个document是用户需要的，那么它则是相关的，否则便是不相关的，在理想状态下，检索到的document都是相关的，而没检索到的则是一个都不相关的，这是一个黑与白的概念。不过检索很少是完美的，因此会出现风马牛不相及的情况，于是便用相关度来表示，指两个事物间存在相互联系的百分比，这是一个非常复杂的理论。 Xapian默认的排序模式称为BM25Weight，这是一种将词频和document等元素出现的频率通过一个固定的公式得出排序权重的模式，权重越高则相关度越高，如果不想使用BM25Weight作为排序模式，可以使用BoolWeight，BoolWeight模式里的各种元素的权重都为0。排序会在后续文章里继续讲述。

2.4.1. 组合检索
默认情况下，Xapian可以使用任意组合的复杂的布尔型查询表达式来缩小检索的范围，然后将结果按概率性排序（某些布尔型系统只允许将查询表达式限制为某种格式）。 布尔型检索和概率性检索有两种组合的方式：
1 先用布尔型检索得到所有documents中的某个子集，然后在这个子集中再使用概率性检索。
2 先进行概率性检索，然后使用布尔型检索过滤查询结果。 这两种方式的结果还是有稍稍区别的。 举个例子 ，在某个database里包含了英文和法文两种documents，“grand”这个词语在这两种语言中都存在（意思都差不多），但在法文中更常见，不过如果使用第一种方式，先用布尔型检索先限定出英文子集，这个词语则会得到更多的权重。 第一种方法更精确，不过执行效率不高，Xapian特地优化了第二种方法，别以为Xapian真的先进行概率性检索再进行布尔型检索的，实际上Xapian是同时执行这两种操作的。在Xapian内部进行了几种优化，例如如果通过概率性检索能得出结果，Xapian就会取消正在执行的布尔型AND操作。这些优化方法经过评测可以提高几倍的性能，并且在执行多个Terms查询时会有更好的表现。 ++QueryParser++ 在IR系统中，终端用户按某种系统约定的格式输入，这些输入便称为“查询”。然后IR系统将此输入转交给查询器，查询器也是IR系统的一部分，其可以解析“查询“，匹配documents和对结果集进行排序，然后返回结果给终端用户。 在Xapian中，Query类便起着“查询”的作用，Query类的生成方法有两种，第一种是由QueryParser类解析查询字符串生成，别一种则是创建多个表示不同描述表达式的Query类，然后再将这些Query按需组合起来。 以下是Xapian::QueryParser支持的语法，其实这些语法跟其它IR系统的语法亦很相似。
AND
expression And expression 提取这两个表达式所匹配的documents的交集。
OR
expression OR expression 提取这两个表达式匹配的documents的并集。
NOT
expression NOT expression 提取只符合左边的表达式的documents集合。 如果FLAG_PURE_NOT标志被设置，那么NOT expression表达式不提取匹配符合此表达式的documents。|
XOR
expression XOR expression 只提取左表达式和右表达式其中一个表达式匹配的documents，而不提取两者都匹配的documents。
组合表达式
可以使用括号将上述布尔操作符括起来从而控制其优先级，例如：(one OR two) AND three。
+ 和 –
一组标记了+或-操作符的terms只提取匹配所有的+terms，而不匹配所有的-terms。如果terms不标记+或-操作符会有助于documents的排名。
NEAR
one NEAR two NEAR three会提取符合这三个关键字的词距在10之间的documents，词距从那里来？在《利用Xapian构建自己的搜索引擎：Document、Term和Value》这篇文章里就曾介绍过可以使用Document类的add_posting方法来添加带词距的terms。 NEAR默认的词距是10，可以使用NEAR/n来设置，例如one NEAR/6 two。
ADJ
ADJ跟NEAR很相似，不过ADJ两边的terms是按顺序来比较的。因此one ADJ two ADJ three是表示one与two与three之间的词距都是10。
短语搜索
一个短语是被双引号括着的，可以用在文件名或邮件地址等地方。
使用字段名的形式
如果database里的terms已经添加了前缀，那么可以使用QueryParser的add_prefix方法来设置前缀map。例如QueryParser.add_prefix("subject", "S")这样便将subject映射到S，如果某个term的值为“S标题”，那么可以使用“subject:标题”这样的表达式来检索结果。这时大家可能会记起Google也支持这种语法，例如在Google的搜索栏里输入“Site: 股票”时，只会检索出里的关于股票的网页，这功能其实亦实现了Lucene的Field功能。
范围搜索
范围搜索在Xapian中是由Xapian::ValueRangeProcessor类来支持的，在Xapian 1.0.0以后才出现。从Xapian::ValueRangeProcessor的名字可以知道，其只能搜索Value的范围，而不能搜索terms的范围。 Xapian::ValueRangeProcessor是一个抽象基类，因此在实际应用中要使用其子类，Xapian提供了三个开箱即用的Xapian::ValueRangeProcessor的子类，分别是StringValueRangeProcessor、DateValueRangeProcessor和NumberValueRangeProcessor，如果觉得这三个类不能满足需求，亦可以继承Xapian::ValueRangeProcessor来创建自己的子类。 当使用Xapian::ValueRangeProcessor的子类时，应该将开始范围和结束范围传给它，如果Xapian::ValueRangeProcessor的子类无法明白传进来的范围，它会返回Xapian::BAD_VALUENO。下面仅以StringValueRangeProcessor举例，当database里将用户名保存在Number为4的Value中（Value是通过数字来标识的，详细请看《利用Xapian构建自己的搜索引擎：Document、Term和Value》），那么可以这样组织查询表达式：mars asimov..bradbury，只是这样当然还不够，还需要创建一个StringValueRangeProcessor Xapian::QueryParser qp; Xapian::StringValueRangeProcessor author_proc(4); qp.add_valuerangeprocessor(&author_proc); 当QueryParser解析查询表达式时会使用OP_VALUE_RANGE标志，因此QueryParser生成的query会返回以下描述： Xapian::Query(mars:(pos=1) FILTER (VALUE_RANGE 4 asimov bradbury) (VALUE_RANGE 4 asimov Bradbury)这个子表达式使用仅仅匹配Number为4的Value的值是>= asimov 和<= bradbury（使用字符串比较）。值范围搜索并不复杂，更多的介绍请看http://www.xapian.org/docs/valueranges.html。
别名
QueryParser亦支持别名检索，使用这样的语法：~term。如何添加别名，后面会介绍。
通配符
QueryParser支持以“*”结尾的通配符，因此“wildc*”可以匹配“wildcard”、“wildcarded” 、“wildcards”、“wildcat”、“wildcats”。不过这功能默认是关闭的，可以将Xapian::QueryParser::FLAG_WILDCARD 作为标志传到Xapian::QueryParser::parse_query(query_string, flags)来开启按以下步骤来开启。|

2.5. Query
如果不想使用字符串形式的查询表达式，可以用下面这些操作符将多个Query组合起来：
OP_AND
等同于QueryParser所支持的AND
OP_OR
等同于QueryParser所支持的OR
OP_AND_NOT
等同于QueryParser所支持的AND_NOT
OP_XOR
等同于QueryParser所支持的XOR
OP_AND_MAYBE
只返回左边子表达式匹配的documents，不过两边的表达式所匹配的documents都加入权重计算。
OP_FILTER
作用跟AND相似，不过仅仅左边的表达式匹配的documents才加入权重计算。
OP_NEAR
等同于QueryParser所支持的NEAR
OP_PHRASE
等同于QueryParser所支持的ADJ
OP_VALUE_RANGE
等同于QueryParser所支持的范围搜索
OP_SCALE_WEIGHT
给子表达式指定权重，如果权重为0，则此表达式为纯布尔型查询
OP_ELITE_SET
作用跟OP_OR 很相似，不过有时候性能比OP_OR 要好。这里有详细的解释：http://trac.xapian.org/wiki/FAQ/EliteSet
OP_VALUE_GE
返回大于或等于给定的document value
OP_VALUE_LE
返回小于或等于给定的document value

2.5.1. 如何创建一个只包含一个term的Query
可以使用默认的构造函数：

Xapian::Query query(term);

亦可以使用多参数的构造函数：
Xapian::Query(const string & tname_, Xapian::termcount wqf_ = 1, Xapian::termpos term_pos_ = 0)

其中wqf的全称是Within Query Frequency，可以指定此term在query中的权重。如果整个查询只包含了一个term，这参数用处不大；但当组合查询时，威力便显出来了，因为可以便取得的结果集跟这个term是更相关的。而term_pos是指term在query中的位置，同样如果整个查询中只包含了一个term则用处不大，因此一般用在词组搜索中。
2.5.2. 将多个Query组合起来查询
通过上面所说的Query操作符将Query组合起来，这时要用到Xapian::Query的另一个构造函数：
Xapian::Query(Xapian::Query::op op_,
const Xapian::Query & left,
const Xapian::Query & right)

2.5.3. 率性查询
一个普通的概率性查询其实是将terms用Xapian::Query::OP_OR连接起来。例如：

Xapian::Query query("regulation"));
query = Xapian::Query(Xapian::Query::OP_OR, query, Xapian::Query("import"));
query = Xapian::Query(Xapian::Query::OP_OR, query, Xapian::Query("export"));
query = Xapian::Query(Xapian::Query::OP_OR, query, Xapian::Query("canned"));
query = Xapian::Query(Xapian::Query::OP_OR, query, Xapian::Query("fish"));

不过这样的风格太臃肿了，可以用下面这种清爽一点的风格：
vector <string> terms;
terms.push_back("regulation");
terms.push_back("import");
terms.push_back("export");
terms.push_back("canned");
terms.push_back("fish");
Xapian::Query query(Xapian::Query::OP_OR, terms.begin(), terms.end());

2.5.4. 布尔型查询
假设有这样的布尔型查询表达式：
('EEC' - 'France') and ('1989' or '1991' or '1992') and 'Corporate Law

This could be built up as bquery like this, 那么则用Query来表示则如下
Xapian::Query bquery1(Xapian::Query::OP_AND_NOT, "EEC", "France");
Xapian::Query bquery2("1989");
bquery2 = Xapian::Query(Xapian::Query::OP_OR, bquery2, "1991");
bquery2 = Xapian::Query(Xapian::Query::OP_OR, bquery2, "1992");
Xapian::Query bquery3("Corporate Law");
Xapian::Query bquery(Xapian::Query::OP_AND, bquery1, Xapian::Query(Xapian::Query::OP_AND(bquery2, bquery3)));

还可以将上面创建的bquery对象附加到另一个概率性查询作为布尔型过滤器用来过滤结果集：
query = Xapian::Query(Xapian::Query::OP_FILTER, query, bquery);

2.5.5. + 和 – 操作符
例如有这样的查询表达式：regulation import export +canned +fish –japan 转化为Query则是如下：
vector <string> plus_terms;
vector <string> minus_terms;
vector <string> normal_terms;
plus_terms.push_back("canned");
plus_terms.push_back("fish");
minus_terms.push_back("japan");
normal_terms.push_back("regulation");
normal_terms.push_back("import");
normal_terms.push_back("export");
Xapian::Query query(Xapian::Query::OP_AND_MAYBE,
Xapian::Query(Xapian::Query::OP_AND, plus_terms.begin(), plus_terms.end());
Xapian::Query(Xapian::Query::OP_OR, normal_terms.begin(), normal_terms.end()));
query = Xapian::Query(Xapian::Query::OP_AND_NOT,
query,
Xapian::Query(Xapian::Query::OP_OR, minus_terms.begin(), minus_terms.end()));

2.6. 实战
当使用QueryParser类或Query类创建了Query对象后，只需要实例化一个查询器就可以使用这些Query对象了。例：
Xapian::Database db("Index");
Enquire enquire(db);
enquire.set_query(query);

当然，要想取得结果集、对结果集排序或扩展查询还需要更多的功夫，会在下一篇里继续讲述。
3. Database
xapian1.0之前，是使用quartz作为database文件格式的，不过自从1.0之后，便改用Flint作为database的文件格式了。有时候，我们会将database称为“索引”，在Xapian中，索引通常比被索引的documents还要多，这表示Xapian做一个信息检索系统比做一个信息存储系统更适合。

3.1. Database的存储结构
Xapian的database是所有用于检索的信息表的集合，以下的表是必需的： + posting list table 保存了被每一个term索引的document，实际上保存的应该是document在database中的Id，此Id是唯一的。 + record table 保存了每一个document所关联的data，data不能通过query检索，只能通过document来获取。 + term list table 保存了索引每个document的所有的term。
以下的表是可选的，即当有以下的类型的数据需要被存储的时候才会出现（在1.0.1以前，position和value表就算是没有数据的时候也会被创建，而spelling和synonym表是1.0.2后才出现的）。
+ position list table 保存了每一个Term出现在每一个document中的位置 + value table 保存了每一个document的values，values是用作保存、排序或其它作用的。 + spelling table 保存了拼写纠正的数据。 + synonym table 保存术语的字典，例如NBA、C#或C++等。
以上的每一个集合是保存在独立的文件中，以便允许管理员查看其中的数据。刚刚说了，有一些表不是必需的，例如当您不需要词组搜索的时候，没必要存储任何的postionlist信息。 如果你看过Xapian的database，你会发现以上的每一个表其实是使用了2到3个文件的，如果您正在使用“flint”作为database的存储格式，那么termlist表会被存储为以下三个文件“termlist.baseA”、“termlist.baseB”、“termlist.dB”。在这些文件中，其实只有”.db”文件存储了真实的数据，“.baseA”和“baseB”文件是用作跟踪如果于“.dB”文件中查找数据。通常只会出现一个“.baseA”文件和一个“.baseB”文件。 在前一篇《利用Xapian构建自己的搜索引擎：简介》中提到过，Xapian现在的版本默认是使用flint作为存储系统，“.dB”文件是以块的形式来存储，默认每块是8K，第一块是用作信息头，如果使用UltraEdit等二进制查看工具，会发现所有“.dB”文件的前三个字节都是0x00。因此，当“.dB”中仅有一条数据的时候整个文件也会有16KB时，切莫大惊小怪。 改变“.dB”文件的默认块大小会导致性能变化，但结果很难说是好是坏，因为这是