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開始一步一步構建搜索引擎應用，並配以自己的理解，請大家一起討論。
由於工作原因，一般只有晚上纔有時間寫文章，在寫的過程中還要不斷印證自己的想法是否正確，免得經常作無謂猜測而導致欠缺嚴謹性，因此不能保證每天都能更新，請大家見諒。