Xapian构建索引说明

Reference: http://www.totogoo.com/article/115/xapian-desc.html

 

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才算稳定和成熟的。

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》。

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这个概念，还需要继续研究。

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”有点相似。

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+树来存储的，具有增删改查比较方便迅速的特点，缺点则是如果索引被删除后的空间不能重复利用，为了提高性能，通常要经常重建索引。

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搜索引擎应用后，我们也可以测测具体的速度。

Xapian的绝佳范例

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

在使用Xapian的过程中，我一般是查阅http://www.xapian.org/docs/上的Doc、API Doc和Wiki，遇到困难时则查阅Omega的源代码并互相印证之。实在没办法的时候只能从Google上找找一些网站的邮件列表，可以说是磕磕碰碰地将Xapian的大部分功能玩了一遍。有一些专有名词我虽然知道大概意思，但无法准确地翻译出来，因此《利用Xapian构建自己的搜索引擎》这一系列的内容可能会错漏百出。不过如果这一系列文章可以引起大家对Xapian的兴趣，它所得到的批评才是它最大的价值。

在Xapian1.0之前，是使用quartz作为database文件格式的，不过自从1.0之后，便改用Flint作为database的文件格式了。有时候，我们会将database称为“索引”，在Xapian中，索引通常比被索引的documents还要多，这表示Xapian做一个信息检索系统比做一个信息存储系统更适合。

Database的存储结构

Xapian的database是所有用于检索的信息表的集合，以下的表是必需的：

l posting list table 保存了被每一个term索引的document，实际上保存的应该是document在database中的Id，此Id是唯一的。

l record table 保存了每一个document所关联的data，data不能通过query检索，只能通过document来获取。

l term list table 保存了索引每个document的所有的term。

以下的表是可选的，即当有以下的类型的数据需要被存储的时候才会出现（在1.0.1以前，position和value表就算是没有数据的时候也会被创建，而spelling和synonym表是1.0.2后才出现的）。

l position list table 保存了每一个Term出现在每一个document中的位置

l value table 保存了每一个document的values，values是用作保存、排序或其它作用的。

l spelling table 保存了拼写纠正的数据。

l 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”文件的默认块大小会导致性能变化，但结果很难说是好是坏，因为这是跟所承载的硬件平台与操作系统平台有关的。一般来说，B树的分支因子（即每个结点能容纳的关键字的数量）越大，B树的查找性能就越强；但由于通常情况下，B树的结点都是存储在永久存储系统（例如硬盘/磁带）中，每次访问某个结点都会将整个结点由永久存储系统读入到内存中，这是一个博弈的过程：假设一棵数据量很大的B树，将B树的分支因子设到很大，这棵B树会长得很矮，从理论上来说查找性能可能很高。但这样就带来了一个弊端，每个结点所占的内存非常多，如果在一个并发访问量很大的IR系统中采用这种方式的话所使用的内存必定是非常可观的。因此在调整“.dB”文件的默认块大小的时候一定要充分考虑cpu体系和操作系统平台，以便调整到最佳性能。

原子性修改

Xapian能保证对database的所有修改都是原子性的，这意味着：

l 从一个独立的进程（或一个独立的database对象在同一个进程）角度来看，在读取数据库的时候，直到修改成功提交，所有对数据库的修改都是不可见的。

l Database在硬盘中的状态始终是保持一致的。

l 如果在修改的过程中系统发生中断，只要硬件不发生故障（硬盘损坏），就算电源被切断，database应该总是被还原到有效的状态。

提交一个修改需要几次的系统调用，以便使所有缓存的修改能刷新到硬盘上，这样能确保就算系统在任何时候发生错误，database也能处于一致的状态。当然，这样相对于说会慢了一点（因为系统已经准备好往硬盘上写数据了），因此将几次的修改组合在一起往硬盘上写会有一定的性能提升。

多个修改操作可以显式地组合在一个事务中，如果一个应用程序不显式地使用事务来保护修改操作，Xapian会将这些修改组合在一个事务中，然后批量进行修改。请注意，Xapian现在暂时还不能跨database进行事务操作。

如果要想迅速地生成非常大的database，请使用“DANGEROUS”关键字搜索Xapian的邮件列表，其提供了可以重新编译Xapian而不采用原子性修改的方法，这功能已经不再整合在xapian的标准版本中了。

Single writer, multiple reader

Xapian实现了“单写多读”的模式，这意味着任何时候，同一时刻只允许一个对象可以修改database，但允许多个对象可以读取database。

在*nix系统下，Xapian使用“lock-files”强制约束来实现此模式，在一个flint database中，每一个Xapian的database目录包含了一个名为“flintlock”的文件以作锁定用途。此文件总在存在于database的目录里，当database被打开用作写入的时候，此文件会被fcntl()方法锁定。每一个WritableDatabase打开的时候，都会产生一个子进程以便进行锁定操作。如果某个database写入器（一般是指WritableDatabase）还没有机会执行释放锁的清除操作便退出了（例如这个WritableDatabase所在的应用程被杀死了），fcntl()产生的锁会自动被操作系统释放。

在Microsoft Windows下，使用的是另一种锁定的技术，此技术不需要产生了子进程来进行锁定操作，但同理，当写入器退出时，操作系统依然会自动释放锁。熟悉Windows机制的朋友知道，Windows是使用文件句柄来操作文件的，而文件句柄是属于内核资源的一种，在任何情况下，Windows都能保证应用程序在退出时能释放所有的资源。

网络文件系统

Xapian现在可以工作在一个网络文件系统中，但存在着大量的潜在问题。因此建议在部署前要大量地在特定的网络中测试。

请注意，Xapian是非常依赖I/O操作的，除非处于一个性能非常优秀的网络，在一个网络文件系统中进行操作会相对的慢一点。

Xapian需要可以在database的目录里创建一个lock file，在某些网络文件系统中（例如NFS），这需要一个锁定的守护进程在运行，也就是上面所提到的子进程。

创建database

说了一堆的理论，下面我们来实战创建一个database。Xapian里的所有类都处于Xapian这个命名空间里，Xapian::Database是所有Database的基类，实际上，它只有一个子类，那就是WritableDatabase。从面向对象的角度来看，这两个类设计得非常好，Xapian::Database拥有大部分只读或内存操作的方法，而Xapian::WritableDatabase则拥有事务操作，刷新数据到硬盘等方法。

有几种创建Database的方法：

l Flint 如果你是使用远程后端（指网络文件系统），请使用Xapian::Flint::open()方法来创建database。使用此方法你能得到更多的控制，例如创建只读的database，或创建可写的database。

l Auto auto并不是一种database格式，你可以创建一个“database存根”文件，此文件能列出一到多个database的路径，这些路径可以作为Xapian::Database的构造函数的参数，从而被自动检测是哪种类型的database。还有，如果将一个文件路径名称而非目录名称作为参数传入到Xapian::Database的构造函数中，Xapian::Database会认为你传入了一个“database存根”文件；当然，你也可以使用Xapian::Auto::open_stub()来显式打开一个存根文件。上面说的可能有点绕口，“database存根文件”的格式是每个database一行，例如：

remote localhost:23876 flint /var/spool/xapian/webindex

这下该明白了。

l Inmemory 还可以创建内存databse，这种类型的database是保存在内存中。请注意，通过Xapian::InMemory::open()返回的类型是WritableDatabase，这意味着这是一个可刷新到硬盘上的database，它最初是为测试之用，但在建立临时的小数据库也可能是有用的。

实际上，创建一个database还有更通用的方法，例如通过将一个database所在的完整目录作为一个字符串传入到Xapian::Database的构造函数中实例化一个对象后，即可得到一个只读的database。而Xapian::WritableDatabase则复杂一点，除了要传入database的路径外，还需要设定如何打开database。有以下几个参数：

l Xapian::DB_CREATE_OR_OPEN 打开以便读写，如果不存在则创建。

l Xapian::DB_CREATE 总是创建新的database，如果存在则失败。

l Xapian::DB_CREATE_OR_OVERWRITE 如果database存在的话则覆盖之，如果不存在则创建。

l Xapian::DB_OPEN 打开以便读写，如果不存在则失败。

成功打开一个datababse是Xapian所有后续操作如检索，写入的基础。你甚至可以将通过add_database()方法则多个database组合在一起访问；如果想将database刷新到硬盘中，则执行flush()方法则可。最后，如果不想使用database了，将database对象销毁即可。

小结

在这一章里，似乎并没有多少具体的操作，但database是Xapian的存储系统，在Xapian所有操作的基础，只有清楚明白了Xapian的存储方式才能更好更高效地构造自己的搜索引擎。同时，如果您之前并没有对大型的文件存储系统有所了解的话，这篇文件可以多多少少带给您一些启示。在下一章里，我会继续介绍Document和Term等Xapian的组成部分。

里指出database是Xapian的基础，而这一篇里讲到的documents、terms和values则是索引和查询的必要组成部分。

Documents 、terms and posting

在信息检索(IR)中，我们企图要获取的项称之为“document”，每一个document是被一个terms集合所描述的。“document”和“term”这两个词汇是IR中的术语，它们是来自“图书馆管理学”的。通常一个document认为是一块文本，. Usually a document is thought of as a piece of text, most likely in a machine readable form, 而一个term则是一个词语或短语以用作描述document的，在document中大多数会存在着多个term，例如某个document是跟口腔卫生相关的，那么可能会存在着以下的terms：“tooth”、“teeth”、“toothbrush”、“decay”、 “cavity”、“plaque”或“diet”等等。

如果在一个IR系统中，存在一个名为D的document，此document被一个名为t的term所描述，那么t被认为索引了D，可以用以下式子表示：t->D。在实际应用的一个IR系统中通常是多个documents，如D1, D2, D3 …组成的集合，且有多个term，如t1, t2, t3 …组成的集合，从而有以下关系：ti -> Dj。

如果某个特定的term索引了某个特定的document，那么称之为posting，说白了posting就是带position信息的term，在相关度检索中可能有一定的用途的。

给定一个名为D的document，存在着一个terms列表索引着它，我们称之为D的term list。

给定一个名为t的term，它索引着一个documents列表，这称之为t的posting list（使用“Document list”可能会在叫法上更一致，但听起来过于空泛）。

在一个存在于计算机的IR系统中，terms是存储于索引文件中的。term可以用作有效地查找它的posting list，在posting list里，每一个document带有一个很短的标识符，就是document id。简单来说，一个posting list可以被认为是一个由document ids组成的集合，而term list则是一个字符串组成的集合。在某些IR系统的内部是使用数字来表示term的，因此在这些系统中，term list则是数字组成的集合，而Xapian则不是这样，它使用原汁原味的term，而使用前缀来压缩存储空间。

Terms不一定是要是document中出现的词语，通常它们会被转换为小写，而且往往它们被词干提取算法处理过，因此通过一个值为“connect”的term可能会检索出一系列的词语，例如“connect”、“connects”、“connection”或“connected”等，而一个词语也可能产生多个的terms，例如你会将提取出的词干和未提取的词语都索引起来。当然，这可能只适用于英语、法语或拉丁语等欧美系列的语言，而中文的分词则有很大的区别，总的来说，欧美语系的语言分词与中文分词有以下的区别：

l 拿英语来说，通常情况下英语的每一个词语之间是用空格来隔开的，而中文则不然，甚至可以极端到整篇文章都不出现空格或标点符号。

l 像上面提到的，“connect”、“connects”、“connection”或“connected”分别的意思“动词性质的连接”、“动词性质的第三人称的连接”、“名称性质的连接”或“连接的过去式”，但在中文里，用“连接”就可以表示全部了，几乎不需要词干提取。这意味着英语的各种词性大部分是有章可循的，而中文的词性则是天马行空的。

l 第二点只是中文分词非常困难的一个缩影，要完全正确地标识出某个句子的语意是很困难的，例如“中华人民共和国成立了”这个句子，可以分出“中华”、“华人”、“人民”、“共和国”、“成立”等词语，不过其中“华人”跟这个句子其实关系不大。咋一眼看上去很简单，但机器那有这么容易懂这其中的奥妙呢？

Values

Values是附加在document上一种元数据，每一个document可以有多个values，这些values通过不同的数字来标识。Values被设计成在匹配过程中快速地访问，它们可以用作排序、排队多余重复的document和范围检索等用途。虽然values并没有长度限制，但最好让它们尽可能短，如果你仅仅是想存储某个字段以便作为结果显示，那么建议您最好将它们保存在document的data中。

Document data

每一个Document只有一个data，可以是任意类型格式的数据，当然在存储的时候请先转换为字符串。这听上去可能有点古怪，实情是这样的：如果要存储的数据是文本格式，则可以直接存储；如果要存储的数据是各种的对象，请先序列化成二进制流再保存，而在读取的时候反序列化读取。

UTF-8与Unicode

Xapian里的所有东西是用UTF-8来保存的，UTF-8是Unicode的一种实现。现在很多人用VC为了方便是将编码设成“未设置”或“多字节”的，也就是说用的是系统内码（GB2312/GBK/ GB18030），这样的话则将数据保存到Xapian前要先转码为UTF-8，而从Xapian里读出的数据则要转码为GB2312/GBK/ GB18030才能正确显示，这里推荐用iconv，这是一个非常方便的库。 分词

很多文章都说现在的中文分词已经很成熟的，但据实际考察，google或百度等大公司的分词引擎都是自己开发或有专门的公司开发的，的确已经算比较成熟。但市场上提供免费甚至开源的分词引擎不多，中科院研发的ictclas30分词精确度和分词速度都非常不错，而且还有词性标注和自定义添加词的功能，可惜不开源。另外比较受欢迎的还有libmmseg和SCWS，因此都是开源的，不过经测试libmmseg的分词精度似乎不高，而SCWS由于使用了大量的递归，在生成词库的时候经常导致栈溢出（我是用vc2005编译的），需要自己将递归修改为循环，从演示的情况来看，SCWS的分词精度来算可以。 实战

由于Xapian并不像Lucene那样有Field的概念，因此一般采用以大写字母作为Term和posting的前缀，但单个字母的前缀对程序员太不友好了，所以一般的做法是自定义一个用户前缀到term前缀的映射，如Title=>T，而Xapian的QueryParser也支持这种映射，QueryParser是查询解释器，能将一段字符串解释为Xapian的Query，后面会陆续提到。

添加document的例子：

  Xapian::Document doc;

  doc.add_term(“K你好”);

  doc.add_term(“K那里”);

  //posting是带position的term

  doc.add_posting(“K吃饭”, 14);

  doc.add_posting(“K玩耍”, 8);

  /*

  这里最好先用一个map<string, int>放置value的名称和索引的配对

  这里使用起来像Lucene的SortField一样了。

  */

  doc.add_value(1, “1”);

  doc.set_data(“你好啊，在那里玩耍呢？还没吃饭吗？”);

  //创建一个可写的db

  Xapian::WritableDatabase db(“c://db”);

  //将document加入到db中,返回document的id，此id在db中是唯一的

  Xapian::docid id = db.add_document(doc);

  //刷新到硬盘中

  db.flush();

  获取document信息的例子：

  //获取

  Xapian::Document doc = db.get_document(id);

  string v = doc.get_value(1);

  printf(v);//输出

  string data = doc.get_data();

  printf(data);//输出”你好啊，在那里玩耍呢？还没吃饭吗？”

  for (Xapian::TermIterator iter = doc.termlist_begin(); iter != doc.termlist_end(); ++iter)

  {

  printf(*iter);//依次输出term和posting

  }

上面的两个例子比较简单，如果要想更深入请查阅Omega的代码，里面有更复杂的应用。值得一提的Xapian里有一个TermGenerator，可以更方便地索引数据，不过这个类有两个不知道算不算缺点的特点：首先是依赖Stem，对于中文来说除非自己实现了一个Stem，否则TermGenerator用处不大；另外TermGenerator会自动将生成的term或posting添加“Z”前缀。

在这里要提一下一个名为“Xapwrap”的东东，这是某个外国人用python写的一个封装Xapian的类库，里面某些思想还是不错的，只可惜只兼容Xapian 1.x之前的版本。我自己封装的类有一部分就是参考Xapwrap的。

下面是一段我正在用的代码：

  //CXapianDocument是封装过的Xapian::Document

  void 　doSegment(CXapianDocument& document, const char* lpszInput, string strUserPrefix)

  {

  //先分词，这里使用的是中科院的分词引擎

  int nCount = ICTCLAS_GetParagraphProcessAWordCount(lpszInput);

  result_t *result =(result_t*)malloc(sizeof(result_t)*nCount);

  //获取分词结果

  ICTCLAS_ParagraphProcessAW(nCount,result);



  string termPrefix;

  //通过用户前缀取得term前缀，这是我自定义的一个宏

  GetTermPrefixFromMap(this->m_userPrefixToTermPrefixMap, strUserPrefix, termPrefix)

  for (int i=0; i<nCount; i++)

  {

  //忽略标点符号，标点符号的词性标注为w开头的

  if(result[i].sPOS[0] == ‘w’)

  {

  continue;

  }

  char buf[100];

  memset(buf, 0, 100);

  int index = result[i].start;

  memcpy(buf,(void *)(lpszInput+index), result[i].length);

  //添加posting

  document.AppendPosting(termPrefix, buf, result[i].start);

  }



  free(result);

  }

经过前面几篇的介绍，如果再参考一下Omega的话，估计应该可以顺利创建database和往database里添加document了。有了数据，下一步关心的当然是怎样将它们查出来，在一个IR系统（不单止Xapian）中，检索的方式是多元化的，排序则是多样化的，结果则是人性化的，这就是跟关系数据库相比的最大优势。由于内容较多，因此将检索、排序和取得结果分开讲述，这一篇先讲述如何检索。

IR系统有这么多的好处，因此终端用户对它是有很高期望的，世事万物总不会完美的，于是IR系统有三个评价标准：召回率、准确率与查询效率。三个指标相互矛盾，只有取舍、不能调和，这亦是一个博弈的过程，使用者关心不同的指标，自然会采用不同的观点和做法。拿Web搜索引擎来说，查询效率肯定是摆在第一位的，其次才能考虑准确率和召回率。看字面看上去，大家心里估计对准确率还有个谱，但召回率又如何解释呢？

准确率和召回率

有时候，准确率也称为精度，举个例子，一个数据库有500个文档，其中有50个文档符合定义的问题。系统检索到75个文档，但是只有45个符合定义的问题。

召回率R=45⁄50=90%

精度P=45⁄75=60%

本例中，系统检索是比较有效的，召回率为90%。但是结果有很大的噪音，有近一半的检索结果是不相关。通常来说，在不牺牲精度的情况下，获得一个高召回率是很困难的。对于一个检索系统来讲，召回率和精度不可能两全其美：召回率高时，精度低，精度高时，召回率低。对于搜索引擎系统来讲，它可以通过搜索更多更多的结果来查到更多相关结果，从而提高召回率(查全率)，但也会导致查到更多不相关结果，从而降低了搜索结果的精度(查准率)。因为没有一个搜索引擎系统能够搜集到所有的WEB网页，所以召回率很难计算。所以一般来说，不会单独的使用召回率或精度，而是在其中一个值固定的基础上，讨论另一个值。如当召回率为60%时的精度值变化情况。因此在召回率与准确率中，Web搜索引擎会更倾向于后者，因为终端用户最想得到的他们要想得到的数据，而不是一堆似是而非的数据。

但是，对于一个传统的图书信息检索系统，情况会大不相同——书籍与文章有良好的关键字索引，包括标题、作者、摘要、正文、收录时间等定义明确的结构化数据，文档集合相对稳定并且规模相对较小，想更深一层，终端用户可能只知道某图书名的其中一两个字，那么如果在较低的召回率下，此用户可能会铩羽而归。

说到这里我们应该差不多知道IR系统在不同的应用场合下是有不同的准确率和召回率作为评价指标的，而准确率和召回率则是由分词策略直接影响的，拿我们最关心的中文分词来说，分词策略一般有以下几种：

l 第一种，默认的单字切分。这种分词策略实现起来最简单，举个例子，有以下句子：“我们在吃饭呢”，则按字切分为[我]、[们]、[在]、[吃]、[饭]、[呢]。按这种方法分词所得到的term是最少的，因为我们所使用的汉字就那么几千个，但随便所索引的数据量的增大，索引文件的增长比例却比下面的几种模型都要大，虽然其召回率是很高的，但精确率却非常低，而且一般情况下性能也是最差的。

l 第二种，二元切分，即以句子中的每两个字都作为一个词语。继续拿“我们在吃饭呢”这个句子作例子，用二元切分法会得到以下词：[我们]、[们在]、[在吃]、[吃饭]、[饭呢]。这种切分方法比第一种要好，精确率提高了，召回率也没降低多少（实际上两者都不高，太中庸了）。

l 第三种：按照词义切分。这种方法要用到词典，常见的有正向最大切分法和逆向最大切分法等。我们再拿“我们在吃饭呢”作为例子。使用正向切分法最终得到词语可能如下：[我们]、[在吃]、[饭]、[呢]，而使用逆向最大切分法则可能最终得到以下词语：[我们]、[在]、[吃饭]、[呢]。只要处理好在庞大的词典中查找词语的性能，基于词典的分词结果会挺不错。

l 第四种：基于统计概率切分。这种方法根据一个概率模型，可以从一个现有的词得出下一个词成立的概率，也以“我们在吃饭呢”这个句子举个可能不恰当的例子，假设已经存在[我们]这个词语，那么根据概率统计模型可以得出[吃饭]这个词语成立的概率。当然，实际应用中的模型要复杂得多，例如著名的隐马尔科夫模型。

在实际的中文分词应用中，一般会将按词典切分和基于统计概率切分综合起来，以便消除歧义，提高精确率。

性能

前面提到，按单字切分的查询性能可能反而是最差的，咋一眼看上去，这种分词方式低精度高召回率是没错，但为什么说它性能不好呢。为了方便解释，我们假设有两万篇文章需要被存储和索引，假设文章里所有内容都是汉字，我们常用的汉字有4000～5000个，那么最理想的情况下平均每个汉字索引了4～5篇文章，可惜实际上有很多汉字的出现频率是非常高的，就拿上面的[我]、[们]、[在]、[吃]、[饭]、[呢]这几个汉字来说，在每篇文章中出现的概率估计至少得有70%～80%。

常见的存储方式是将索引和数据（即文章内容）分开存放，以各种树（红黑树、AVL树或B树）来存储索引，每个结点除了保存父结点和儿子结点的指针外，一般还会保存其索引的文章的Id（在Xapian里就是DocId），通过这个Id可以很快地找到文章内容。在Xapian中，DocId是以32位无符号整数来表示的，占4个字节，如果“我”字在两万篇文章中出现的概率是50%，那么“我”字这个结点就至少占了41000个字节，差不多足足40K！如果某天我们的永久存储体和内存的速度一样快了，这种存储方式问题其实还不大，但由于我们现在普遍使用硬盘/磁带机来保存永久数据，商用的硬盘/磁带机的结构是使用由机械臂控制的磁头来读写盘片来存取数据的，为了减少磁头定位的次数，硬盘/磁带机会设计成按页读取，每页占2~2字节，虽然经过这样的精心设计，但硬盘/磁带机的存取速度还是比主存慢5个数量级左右，这就是I/O是最耗性能的原因，也是我们天天说的“数据库是瓶颈”的原因所在。

很明显，如果按上述的推论，“我”这个结点要占10个以上磁盘页，这太疯狂了。如果通过分词技术将文章切分为多个词语，那么每个词语所索引文章必定减少。前面提到大部分的IR系统或数据库系统的索引都是以B树的形式来存储的，B树是一种硬盘I/O性能非常好的数据结构，其特点是一般每个结点的大小和硬盘上每页的大小是一样的，每个结点能存放n个关键字，而每个结点又有n+1个子女，也就是说，在一棵高度为2的B*树中，最多只需要读取2个结点就可以到达目标结点，也就是说控制磁头的机械臂只移动了两次。在这个时候，良好的数据结构的优越性就显示出来了。

当然，这只是纯粹以硬盘/磁带机为中心来讨论，在实际应用中架构会更加良好，而且如果只有两万篇文章，当我们的主内存足够大的时候，甚至可以一次过将所有文章读到内存中以避免进行硬盘I/O操作，只是这样也带来了写入数据时非常缓慢的尴尬。现在的数据库或IR系统的数据文件动辄几个GB，因此怎样最大限度避免进行频繁的硬盘I/O读写还是放在提高性能的第一位的。

不过千万别以为IR系统一切都比关系数据库要好，IR系统的其中一个弱点是插入、修改和删除都相对缓慢，因为是中间要经过多层的工序处理，所以IR系统的首要任务是检索，其次才是存储。

布尔型检索

虽然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集合结果后，然后使用概率性的排序。

概率性IR和相关度

布尔型检索是最常用的，但在IR系统中，其还没能担大旗，因为使用布尔型检索得到的结果并没有按任何机制使其能变得对用户更友好，在这种情况下，用户必须对这个IR系统有充分的了解才能更有效地使用之。虽然如此，但只有纯粹的布尔型检索的IR系统依然活得好好的。

相关度是概率模型里的核心概念，可以将documents的集合按相关度来排列。本质上，当某个document是用户需要的，那么它则是相关的，否则便是不相关的，在理想状态下，检索到的document都是相关的，而没检索到的则是一个都不相关的，这是一个黑与白的概念。不过检索很少是完美的，因此会出现风马牛不相及的情况，于是便用相关度来表示，指两个事物间存在相互联系的百分比，这是一个非常复杂的理论。

Xapian默认的排序模式称为BM25Weight，这是一种将词频和document等元素出现的频率通过一个固定的公式得出排序权重的模式，权重越高则相关度越高，如果不想使用BM25Weight作为排序模式，可以使用BoolWeight，BoolWeight模式里的各种元素的权重都为0。排序会在后续文章里继续讲述。

组合检索

默认情况下，Xapian可以使用任意组合的复杂的布尔型查询表达式来缩小检索的范围，然后将结果按概率性排序（某些布尔型系统只允许将查询表达式限制为某种格式）。

布尔型检索和概率性检索有两种组合的方式：

先用布尔型检索得到所有documents中的某个子集，然后在这个子集中再使用概率性检索。

先进行概率性检索，然后使用布尔型检索过滤查询结果。

这两种方式的结果还是有稍稍区别的。举个例子，在某个database里包含了英文和法文两种documents，“grand”这个词语在这两种语言中都存在（意思都差不多），但在法文中更常见，不过如果使用第一种方式，先用布尔型检索先限定出英文子集，这个词语则会得到更多的权重。

第一种方法更精确，不过执行效率不高，Xapian特地优化了第二种方法，别以为Xapian真的先进行概率性检索再进行布尔型检索的，实际上Xapian是同时执行这两种操作的。在Xapian内部进行了几种优化，例如如果通过概率性检索能得出结果，Xapian就会取消正在执行的布尔型AND操作。这些优化方法经过评测可以提高几倍的性能，并且在执行多个Terms查询时会有更好的表现。

QueryParser

在IR系统中，终端用户按某种系统约定的格式输入，这些输入便称为“查询”。然后IR系统将此输入转交给查询器，查询器也是IR系统的一部分，其可以解析“查询“，匹配documents和对结果集进行排序，然后返回结果给终端用户。

在Xapian中，Query类便起着“查询”的作用，Query类的生成方法有两种，第一种是由QueryParser类解析查询字符串生成，别一种则是创建多个表示不同描述表达式的Query类，然后再将这些Query按需组合起来。

以下是Xapian::QueryParser支持的语法，其实这些语法跟其它IR系统的语法亦很相似。

l AND

expression And expression提取这两个表达式所匹配的documents的交集。

l OR

expression OR expression提取这两个表达式匹配的documents的并集。

l NOT

expression NOT expression提取只符合左边的表达式的documents集合。

如果FLAG_PURE_NOT标志被设置，那么NOTexpression表达式不提取匹配符合此表达式的documents。

l XOR

expression XORexpression 只提取左表达式和右表达式其中一个表达式匹配的documents，而不提取两者都匹配的documents。

l 组合表达式

可以使用括号将上述布尔操作符括起来从而控制其优先级，例如：(one OR two) AND three。

l +和–

一组标记了+或-操作符的terms只提取匹配所有的+terms，而不匹配所有的-terms。如果terms不标记+或-操作符会有助于documents的排名。

l NEAR

one NEAR two NEAR three会提取符合这三个关键字的词距在10之间的documents，词距从那里来？在《利用Xapian构建自己的搜索引擎：Document、Term和Value》这篇文章里就曾介绍过可以使用Document类的add_posting方法来添加带词距的terms。

NEAR默认的词距是10，可以使用NEAR/n来设置，例如one NEAR/6 two。

l ADJ

ADJ跟NEAR很相似，不过ADJ两边的terms是按顺序来比较的。因此one ADJ two ADJ three是表示one与two与three之间的词距都是10。

l 短语搜索

一个短语是被双引号括着的，可以用在文件名或邮件地址等地方。

l 使用字段名的形式

如果database里的terms已经添加了前缀，那么可以使用QueryParser的add_prefix方法来设置前缀map。例如QueryParser.add_prefix(“subject”, “S”)这样便将subject映射到S，如果某个term的值为“S标题”，那么可以使用“subject:标题”这样的表达式来检索结果。这时大家可能会记起Google也支持这种语法，例如在Google的搜索栏里输入“Site:www.wlstock.com股票”时，只会检索出www.wlstock.com里的关于股票的网页，这功能其实亦实现了Lucene的Field功能。

l 范围搜索

范围搜索在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。

l 别名

QueryParser亦支持别名检索，使用这样的语法：~term。如何添加别名，后面会介绍。

l 通配符

QueryParser支持以“”结尾的通配符，因此“wildc”可以匹配“wildcard”、“wildcarded”、“wildcards”、“wildcat”、“wildcats”。不过这功能默认是关闭的，可以将Xapian::QueryParser::FLAG_WILDCARD

作为标志传到Xapian::QueryParser::parse_query(query_string, flags)来开启按以下步骤来开启。 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

l 如何创建一个只包含一个term的Query

可以使用默认的构造函数：Xapian::Query query(term);

亦可以使用多参数的构造函数：

Xapian::Query(conststring & tname_,

Xapian::termcountwqf_ = 1,

Xapian::termpostermpos = 0) 其中wqf的全称是WithinQuery Frequency，可以指定此term在query中的权重。如果整个查询只包含了一个term，这参数用处不大；但当组合查询时，威力便显出来了，因为可以便取得的结果集跟这个term是更相关的。

而term_pos是指term在query中的位置，同样如果整个查询中只包含了一个term则用处不大，因此一般用在词组搜索中。

l 将多个Query组合起来查询

通过上面所说的Query操作符将Query组合起来，这时要用到Xapian::Query的另一个构造函数：

Xapian::Query(Xapian::Query::opop_,

const Xapian::Query &left,

const Xapian::Query &right)

l 概率性查询

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

Xapian::Queryquery(“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 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());

l 布尔型查询

假设有这样的布尔型查询表达式：

(‘EEC’ – ‘France’) and (‘1989’ or ‘1991’ or ‘1992’) and ‘Corporate Law’

This could be built up as bquery like this,那么则用Query来表示则如下

Xapian::Querybquery1(Xapian::Query::OP_AND_NOT,”EEC”, “France”);

Xapian::Querybquery2(“1989”);

bquery2 = Xapian::Query(Xapian::Query::OP_OR,bquery2, “1991”);

bquery2 = Xapian::Query(Xapian::Query::OP_OR,bquery2, “1992”);

Xapian::Querybquery3(“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);

l +和– 操作符

例如有这样的查询表达式：regulation import export +canned +fish –japan

转化为Query则是如下：

vector plus_terms;

vector minus_terms;

vector 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::Queryquery(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())); 实战

当使用QueryParser类或Query类创建了Query对象后，只需要实例化一个查询器就可以使用这些Query对象了。例：

Xapian::Databasedb(“Index”);

Enquireenquire(db);

enquire.set_query(query);