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的兴趣，它所得到的批评才是它大的价值。
在后续文章中，我会从Xapian的Database开始一步一步构建搜索引擎应用，并配以自己的理解，请大家一起讨论。
由于工作原因，一般只有晚上才有时间写文章，在写的过程中还要不断印证自己的想法是否正确，免得经常作无谓猜测而导致欠缺严谨性，因此不能保证每天都能更新，请大家见谅。