1、 1. 前言1.1. Xapian 与开源Xapian 的官方网站是 http:/www.xapian.org，这是一个非常优秀的开源搜索引擎项目，搜索引擎其实只是一个通俗的说法，正式的说法其实是 IR（Information Retrieval）系统。Xapian 的 License 是 GPL，这意味着允许使用者自由地修改其源码并发布之。Xapian 的中文资料非常少，可以说现在互联网上连一篇完整详细的 Xapian 中文介绍文档，更别说中文API 文档了。其实，Xapian 的英文资料也不多，除了官方网站上的 Docs 和 Wiki 外，还有一些网站上的邮件列表，在这方面跟 Lucene
2、 没得比。当然， 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） 。由于
3、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 的特性依官方的
4、说法，Xapian 是一个允许开发人员轻易地添加高级索引和搜索功能到他们的应用系统的高度可修改的工具，它在支持概率论检索模型的同时也支持布尔型操作查询集。 从功能特性上来说。Xapian 和 Lucene 有点相似，两者都具有 Term、Value （在 Lucene 里称为 SortField） 、Posting、Position 和 Document，不过 Xapian 没有 Field 的概念，这直接导致Xapian 在使用上比 Lucene 麻烦了那么一点。但这完全不是问题，通过一些小技巧，完全可以自己在 Xapian 中实现 Filed 的概念。在 Lucene 里还有一个叫 Pay
5、load 的元素，即词条 (Term) 的元数据或称载荷。举一个例子， “回家吃饭吧”和“快回家吃饭” 这两个句子都带有“吃饭”这个词语，但在检索的时候怎样才能将语气表达出来呢？虽然可以添加 Term 来解决这个问题，但由于 Term 的索引信息和存储信息是分开放的，相对来说 I/O 性能较差，Payload 就是应这个问题而生的，因为 Payload 信息是直接放在索引里的。由于对 Xapian的研究还不是很深，Xapian 里是否有类似 Payload 这个概念，还需要继续研究。1.4. Xapian 与搜索搜索的目的是将结果数据展现给终端用户，搜索引擎与普通的数据库查询最大的区别就在于查
6、询。Xapian 提供了多种的查询机制。 概率性搜索排名 重要的词语会比不那么重要的词语得到更多的权重，因此与权重高的词语关联的 Documents 会排到结果列表的更前面。相关度反馈 通过给予一个或多个 Documents, Xapian 可以显示最相关的 Terms 以便扩展一个 Query，及显示最相关的 Documents。 词组和邻近搜索 - 用户可以搜索一个精确短语或指定数组的词组。 全方位的布尔型搜索器，例如 (“stock NOT market“, etc)。 支持提取搜索关键字的词干，例如当搜索“football”的时候，当 Documents 中含有“footballs“
7、或“footballer“的时候也被认作符合。这有助于找到相关结果，否则可能错过之。词干提取器现在支持 Danish、Dutch、 English、 Finnish、 French、 German、 Hungarian、Italian、 Norwegian、Portuguese、Romanian、 Russian、Spanish、Swedish 和 Turkish。 支持通配符查询，例如“xap*”。 支持别名查询，打个比方，C+会自动转为 CPlusPlus，C#则自动转为 CSharp。 Xapian 支持拼写纠正，例如 xapian 会被纠正为 xapain，当然这必须基于词组已经被索引
8、了。这特性跟 Google 提供的“你是不是想搜索 xxx”有点相似。1.5. Xapian 的存储系统Xapian 现在的版本默认是使用 flint 作为存储系统，flint 是以块的形式来存储，默认每块是8K，理论上每一个文件最大可以达到 2048GB。当然，在旧式的文件系统，例如FAT/FAT32是不可能实现的。熟悉 Windows 内存管理机制的朋友一定知道使用 Windows32位系统每个进程的总虚拟地址空间只有4GB，而用户模式连2GB 都不够（Windows2003可以将用户模式扩展到3GB 左右） ，因此应用程序不可能一次过将整个 Database 文件读取到内存中，通常的做法
9、是使用内存映射文件，先预订地址空间，在真正使用的时候才调拨内存，而内存分页粒度是4k，也就是说内存中每一页是4k，而在 IA64系统中，内存分页粒度是8k。在内存中，除了页外，还有区块，X86 和 IA64的内存区块的粒度都是64k。Xapian这样存储数据估计是为了在各个平台上都能实现数据对齐，数据对齐对于 cpu 运算寻址是非常重要的，而8和64都是4的倍数，因此大胆猜想 Xapian 以8k 作为存储系统的默认块大小是为了在性能和兼容性中取得最平衡和最优值。 Xapian 使用 unsigned 32-bit ints 作为Documents 的 id 值，因此在每个 Xapian 的
10、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 power
11、ed BrightStations 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 的官方网站上有一个绝佳的使用
12、范例，这个称为 Omega 的项目甚至可以开箱即用作为一个 CGI 应用程序。Omega 附带了 Omindex 和 ScriptIndex 这两个索引生成工具，可以将硬盘上的 html，pdf，图片甚至视频影片索引起来并生成 Database，通过操作这些由Omindex 或 ScriptIndex 生成的 Database，Omega 提供了搜索这些文件的功能。2. 检索经过前面几篇的介绍，如果再参考一下 Omega 的话，估计应该可以顺利创建 database 和往database 里添加 document 了。有了数据，下一步关心的当然是怎样将它们查出来，在一个IR 系统（不单止 Xa
13、pian）中，检索的方式是多元化的，排序则是多样化的，结果则是人性化的，这就是跟关系数据库相比的最大优势。由于内容较多，因此将检索、排序和取得结果分开讲述，这一篇先讲述如何检索。 IR 系统有这么多的好处，因此终端用户对它是有很高期望的，世事万物总不会完美的，于是 IR 系统有三个评价标准：召回率、准确率与查询效率。三个指标相互矛盾，只有取舍、不能调和，这亦是一个博弈的过程，使用者关心不同的指标，自然会采用不同的观点和做法。拿 Web 搜索引擎来说，查询效率肯定是摆在第一位的，其次才能考虑准确率和召回率。看字面看上去，大家心里估计对准确率还有个谱，但召回率又如何解释呢？2.1. 准确率和召回率
14、有时候，准确率也称为精度，举个例子，一个数据库有500个文档，其中有50个文档符合定义的问题。系统检索到75个文档，但是只有45个符合定义的问题。召回率 R=45/50=90%精度 P=45/75=60%本例中，系统检索是比较有效的，召回率为 90%。但是结果有很大的噪音，有近一半的检索结果是不相关。通常来说，在不牺牲精度的情况下，获得一个高召回率是很困难的。对于一个检索系统来讲，召回率和精度不可能两全其美：召回率高时，精度低，精度高时，召回率低。对于搜索引擎系统来讲，它可以通过搜索更多更多的结果来查到更多相关结果，从而提高召回率(查全率)，但也会导致查到更多不相关结果，从而降低了搜索结果的精
15、度(查准率) 。因为没有一个搜索引擎系统能够搜集到所有的 WEB 网页，所以召回率很难计算。所以一般来说，不会单独的使用召回率或精度，而是在其中一个值固定的基础上，讨论另一个值。如当召回率为 60%时的精度值变化情况。因此在召回率与准确率中，Web 搜索引擎会更倾向于后者，因为终端用户最想得到的他们要想得到的数据，而不是一堆似是而非的数据。 但是，对于一个传统的图书信息检索系统，情况会大不相同 书籍与文章有良好的关键字索引，包括标题、作者、摘要、正文、收录时间等定义明确的结构化数据，文档集合相对稳定并且规模相对较小，想更深一层，终端用户可能只知道某图书名的其中一两个字，那么如果在较低的召回率下
16、，此用户可能会铩羽而归。 说到这里我们应该差不多知道 IR 系统在不同的应用场合下是有不同的准确率和召回率作为评价指标的，而准确率和召回率则是由分词策略直接影响的，拿我们最关心的中文分词来说，分词策略一般有以下几种： - 第一种，默认的单字切分。这种分词策略实现起来最简单，举个例子，有以下句子：“我们在吃饭呢” ，则按字切分为我、 们、在 、吃 、饭、 呢。按这种方法分词所得到的 term 是最少的，因为我们所使用的汉字就那么几千个，但随便所索引的数据量的增大，索引文件的增长比例却比下面的几种模型都要大，虽然其召回率是很高的，但精确确率。 - 第二种，二元切分，即以句子中的每两个字都作为一个词
17、语。继续拿“ 我们在吃饭呢”这个句子作例子，用二元切分法会得到以下词：我们 、们在、 在吃、吃饭 、饭呢。这种切分方法比第一种要好，精确率提高了，召回率也没降低多少（实际上两者都不高，太中庸了） 。 - 第三种：按照词义切分。这种方法要用到词典，常见的有正向最大切分法和逆向最大切分法等。我们再拿“我们在吃饭呢”作为例子。使用正向切分法最终得到词语可能如下：我们、在吃 、饭、 呢，而使用逆向最大切分法则可能最终得到以下词语：我们、 在、吃饭、 呢。只要处理好在庞大的词典中查找词语的性能，基于词典的分词结果会挺不错。 第四种:基于统计概率切分。 这种方法根据一个概率模型，可以从一个现有的词得出下一
18、个词成立的概率，也以“我们在吃饭呢”这个句子举个可能不恰当的例子，假设已经存在我们这个词语，那么根据概率统计模型可以得出 吃饭这个词语成立的概率。当然，实际应用中的模型要复杂得多，例如著名的隐马尔科夫模型。 在实际的中文分词应用中，一般会将按词典切分和基于统计概率切分综合起来，以便消除歧义，提高精确率。2.2. 性能前面提到，按单字切分的查询性能可能反而是最差的，咋一眼看上去，这种分词方式低精度高召回率是没错，但为什么说它性能不好呢。为了方便解释，我们假设有两万篇文章需要被存储和索引，假设文章里所有内容都是汉字，我们常用的汉字有40005000个，那么最理想的情况下平均每个汉字索引了45篇文章
19、，可惜实际上有很多汉字的出现频率是非常高的，就拿上面的我、 们 、在、 吃、 饭、呢 这几个汉字来说，在每篇文章中出现的概率估计至少得有70% 80%。 常见的存储方式是将索引和数据（即文章内容）分开存放，以各种树（红黑树、AVL 树或 B*树）来存储方式问题其实还不大，但由于我们现在普遍佼 在一棵高度为2的 B*树中，最多只需要读取2个结点就可以到达目标结点，也就是说控制磁头的机械臂只移动了两次。在这个时候，良好的数据结构的优越性就显示出来了。 当然，这只是纯粹以硬盘/磁带机为中心来讨论，在实际应用中架构会更加良好，而且如果只有两万篇文章，当我们的主内存足够大的时候，甚至可以一次过将所有文章
20、读到内存中以避免进行硬盘 I/O 操作，只是这样也带来了写入数据时非常缓慢的尴尬。现在的数据库或 IR 系统的数据文件动辄几个 GB，因此怎样最大限度避免进行频繁的硬盘 I/O 读写还是放在提高性能的第一位的。 不过千万别以为 IR 系统一切都比关系数据库要好，IR系统的其中一个弱点是插入、修改和删除都相对缓慢，因为是中间要经过多层的工序处理，所以 IR 系统的首要任务是检索，其次才是存储。2.3. 布尔型检索虽然 IR 系统会帮我们分词，但有时候我们却想“帮助”IR 系统理解我们要搜索什么。例如，我们可能会在百度或 Google 的搜索栏里输入：“我们 吃饭”来寻找我们感兴趣的关于“我们”和
21、“吃饭”的文章，而不是直接输入“ 我们吃饭”来搜索文章。这两种的输入得到的结果是完全不同的，因为“我们吃饭” 已经成为了 Google 的 IR 系统里的其中一个 term 了。 像“ 我们 吃饭”这样的输入，其实就是布尔型检索。在 Xapian 里，则是将多个 terms 用 AND、 OR或 AND_NOT 连接起来，举个例子：t1 索引了 documents 1 2 3 5 8t2 索引了 documents 2 3 6那么：t1 AND t2 检索得 2 3t1 OR t2 检索得 1 2 3 5 6 8t1 AND_NOT t2 检索得 1 5 8t2 AND_NOT t1 检索得
22、6在很多系统中，这些 documents 并没有根据它们之间的相关度来排序的；但在 Xapian 里，布尔型风格的查询都可以在检索得出 documents 集合结果后，然后使用概率性的排序。2.4. 概率性 IR 和相关度布尔型检索是最常用的，但在 IR 系统中，其还没能担大旗，因为使用布尔型检索得到的结果并没有按任何机制使其能变得对用户更友好，在这种情况下，用户必须对这个 IR 系统有充分的了解才能更有效地使用之。虽然如此，但只有纯粹的布尔型检索的 IR 系统依然活得好好的。 相关度是概率模型里的核心概念，可以将 documents 的集合按相关度来排列。本质上，当某个 document 是
23、用户需要的，那么它则是相关的，否则便是不相关的，在理想状态下，检索到的 document 都是相关的，而没检索到的则是一个都不相关的，这是一个黑与白的概念。不过检索很少是完美的，因此会出现风马牛不相及的情况，于是便用相关度来表示，指两个事物间存在相互联系的百分比，这是一个非常复杂的理论。 Xapian 默认的排序模式称为 BM25Weight，这是一种将词频和 document 等元素出现的频率通过一个固定的公式得出排序权重的模式，权重越高则相关度越高，如果不想使用 BM25Weight 作为排序模式，可以使用 BoolWeight，BoolWeight 模式里的各种元素的权重都为 0。排序会
24、在后续文章里继续讲述。2.4.1. 组合检索默认情况下，Xapian 可以使用任意组合的复杂的布尔型查询表达式来缩小检索的范围，然后将结果按概率性排序（某些布尔型系统只允许将查询表达式限制为某种格式） 。 布尔型检索和概率性检索有两种组合的方式： 先用布尔型检索得到所有 documents 中的某个子集，然后在这个子集中再使用概率性检索。 先进行概率性检索，然后使用布尔型检索过滤查询结果。 这两种方式的结果还是有稍稍区别的。 举个例子 ，在某个 database 里包含了英文和法文两种documents， “grand”这个词语在这两种语言中都存在（意思都差不多） ，但在法文中更常见，不过如果
25、使用第一种方式，先用布尔型检索先限定出英文子集，这个词语则会得到更多的权重。 第一种方法更精确，不过执行效率不高，Xapian 特地优化了第二种方法，别以为 Xapian 真的先进行概率性检索再进行布尔型检索的，实际上 Xapian 是同时执行这两种操作的。在 Xapian 内部进行了几种优化，例如如果通过概率性检索能得出结果，Xapian 就会取消正在执行的布尔型 AND 操作。这些优化方法经过评测可以提高几倍的性能，并且在执行多个 Terms 查询时会有更好的表现。 +QueryParser+ 在 IR系统中，终端用户按某种系统约定的格式输入，这些输入便称为“查询”。然后 IR 系统将此输
26、入转交给查询器，查询器也是 IR 系统的一部分，其可以解析“查询“，匹配documents 和对结果集进行排序，然后返回结果给终端用户。 在 Xapian 中，Query 类便起着“查询”的作用，Query 类的生成方法有两种，第一种是由 QueryParser 类解析查询字符串生成，别一种则是创建多个表示不同描述表达式的 Query 类，然后再将这些Query 按需组合起来。 以下是 Xapian:QueryParser 支持的语法，其实这些语法跟其它IR 系统的语法亦很相似。AND expression And expression 提取这两个表达式所匹配的 documents 的交集。O
27、R expression OR expression 提取这两个表达式匹配的 documents 的并集。NOTexpression NOT expression 提取只符合左边的表达式的 documents 集合。 如果 FLAG_PURE_NOT 标志被设置，那么 NOT expression 表达式不提取匹配符合此表达式的 documents。|XOR expression XOR expression 只提取左表达式和右表达式其中一个表达式匹配的 documents，而不提取两者都匹配的 documents。组合表达式 可以使用括号将上述布尔操作符括起来从而控制其优先级，例如：(one
28、 OR two) AND three。+ 和 一组标记了+或-操作符的 terms 只提取匹配所有的+terms，而不匹配所有的-terms 。如果 terms 不标记 +或-操作符会有助于 documents 的排名。NEARone NEAR two NEAR three 会提取符合这三个关键字的词距在 10之间的documents，词距从那里来？在利用 Xapian 构建自己的搜索引擎：Document、Term 和 Value这篇文章里就曾介绍过可以使用 Document 类的 add_posting 方法来添加带词距的 terms。 NEAR 默认的词距是10，可以使用 NEAR/n
29、来设置，例如 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，如果某
30、个 term 的值为“S 标题”，那么可以使用“subject:标题” 这样的表达式来检索结果。这时大家可能会记起Google 也支持这种语法，例如在 Google 的搜索栏里输入“Site: 股票”时，只会检索出 里的关于股票的网页，这功能其实亦实现了 Lucene 的 Field 功能。范围搜索范围搜索在 Xapian 中是由 Xapian:ValueRangeProcessor 类来支持的，在Xapian 1.0.0以后才出现。从 Xapian:ValueRangeProcessor 的名字可以知道，其只能搜索 Value 的范围，而不能搜索 terms 的范围。 Xapian:Val
31、ueRangeProcessor 是一个抽象基类，因此在实际应用中要使用其子类，Xapian 提供了三个开箱即用的 Xapian:ValueRangeProcessor 的子类，分别是 StringValueRangeProcessor、DateValueRangeProcessor 和NumberValueRangeProcessor，如果觉得这三个类不能满足需求，亦可以继承 Xapian:ValueRangeProcessor 来创建自己的子类。 当使用Xapian:ValueRangeProcessor 的子类时，应该将开始范围和结束范围传给它，如果 Xapian:ValueRangeP
32、rocessor 的子类无法明白传进来的范围，它会返回 Xapian:BAD_VALUENO。下面仅以 StringValueRangeProcessor 举例，当 database 里将用户名保存在 Number 为4的 Value 中（Value 是通过数字来标识的，详细请看利用 Xapian 构建自己的搜索引擎：Document、Term 和 Value ） ，那么可以这样组织查询表达式：mars asimov.bradbury，只是这样当然还不够，还需要创建一个StringValueRangeProcessor Xapian:QueryParser qp; Xapian:StringV
33、alueRangeProcessor author_proc(4); qp.add_valuerangeprocessor( 当 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 和 terms;terms.push_ba
34、ck(“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 LawThis could be built up as bqu
35、ery 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 bque
36、ry(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 plus_terms;vecto
37、r 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:Query query(Xapian:Query:OP_AND_MAYBE,Xapian:Query(Xapian:Query:O
38、P_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 对象后，只需要实例化一个查询器就
39、可以使用这些 Query 对象了。例：Xapian:Database db(“Index“);Enquire enquire(db);enquire.set_query(query);当然，要想取得结果集、对结果集排序或扩展查询还需要更多的功夫，会在下一篇里继续讲述。 3. Databasexapian1.0之前，是使用 quartz 作为 database 文件格式的，不过自从 1.0之后，便改用 Flint 作为 database 的文件格式了。有时候，我们会将 database 称为 “索引” ，在 Xapian 中，索引通常比被索引的 documents 还要多，这表示 Xapian
40、做一个信息检索系统比做一个信息存储系统更适合。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 的所有的 te
41、rm。以下的表是可选的，即当有以下的类型的数据需要被存储的时候才会出现（在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+等
42、。以上的每一个集合是保存在独立的文件中，以便允许管理员查看其中的数据。刚刚说了，有一些表不是必需的，例如当您不需要词组搜索的时候，没必要存储任何的 postionlist 信息。 如果你看过 Xapian 的 database，你会发现以上的每一个表其实是使用了2到3个文件的，如果您正在使用“flint”作为 database 的存储格式，那么 termlist 表会被存储为以下三个文件“termlist.baseA”、 “termlist.baseB”、 “termlist.dB”。在这些文件中，其实只有 ”.db”文件存储了真实的数据， “.baseA”和“baseB” 文件是用作跟踪如果于“.dB”文件中查找数据。通常只会出现一个“.baseA” 文件和一个“.baseB”文件。 在前一篇利用 Xapian 构建自己的搜索引
