如下技術文章也是從我之前很久開的csdn賬号上面遷移過來的
一、總論
根據http://lucene.apache.org/java/docs/index.html定義：
Lucene是一個高效的，基于Java的全文檢索庫。
是以在了解Lucene之前要費一番工夫了解一下全文檢索。
那麼什麼叫做全文檢索呢？這要從我們生活中的資料說起。
我們生活中的資料總體分為兩種：結構化資料和非結構化資料。
- 結構化資料：指具有固定格式或有限長度的資料，如資料庫，中繼資料等。
- 非結構化資料：指不定長或無固定格式的資料，如郵件，word文檔等。
當然有的地方還會提到第三種，半結構化資料，如XML，HTML等，當根據需要可按結構化資料來處理，也可抽取出純文字按非結構化資料來處理。
非結構化資料又一種叫法叫全文資料。
按照資料的分類，搜尋也分為兩種：
- 對結構化資料的搜尋：如對資料庫的搜尋，用SQL語句。再如對中繼資料的搜尋，如利用windows搜尋對檔案名，類型，修改時間進行搜尋等。
- 對非結構化資料的搜尋：如利用windows的搜尋也可以搜尋檔案内容，Linux下的grep指令，再如用Google和百度可以搜尋大量内容資料。
對非結構化資料也即對全文資料的搜尋主要有兩種方法：
一種是順序掃描法(Serial Scanning)：所謂順序掃描，比如要找内容包含某一個字元串的檔案，就是一個文檔一個文檔的看，對于每一個文檔，從頭看到尾，如果此文檔包含此字元串，則此文檔為我們要找的檔案，接着看下一個檔案，直到掃描完所有的檔案。如利用windows的搜尋也可以搜尋檔案内容，隻是相當的慢。如果你有一個80G硬碟，如果想在上面找到一個内容包含某字元串的檔案，不花他幾個小時，怕是做不到。Linux下的grep指令也是這一種方式。大家可能覺得這種方法比較原始，但對于小資料量的檔案，這種方法還是最直接，最友善的。但是對于大量的檔案，這種方法就很慢了。
有人可能會說，對非結構化資料順序掃描很慢，對結構化資料的搜尋卻相對較快（由于結構化資料有一定的結構可以采取一定的搜尋算法加快速度），那麼把我們的非結構化資料想辦法弄得有一定結構不就行了嗎？
這種想法很天然，卻構成了全文檢索的基本思路，也即将非結構化資料中的一部分資訊提取出來，重新組織，使其變得有一定結構，然後對此有一定結構的資料進行搜尋，進而達到搜尋相對較快的目的。
這部分從非結構化資料中提取出的然後重新組織的資訊，我們稱之索引。
這種說法比較抽象，舉幾個例子就很容易明白，比如字典，字典的拼音表和部首檢字表就相當于字典的索引，對每一個字的解釋是非結構化的，如果字典沒有音節表和部首檢字表，在茫茫辭海中找一個字隻能順序掃描。然而字的某些資訊可以提取出來進行結構化處理，比如讀音，就比較結構化，分聲母和韻母，分别隻有幾種可以一一列舉，于是将讀音拿出來按一定的順序排列，每一項讀音都指向此字的詳細解釋的頁數。我們搜尋時按結構化的拼音搜到讀音，然後按其指向的頁數，便可找到我們的非結構化資料——也即對字的解釋。
這種先建立索引，再對索引進行搜尋的過程就叫全文檢索(Full-text Search)。
下面這幅圖來自《Lucene in action》，但卻不僅僅描述了Lucene的檢索過程，而是描述了全文檢索的一般過程。
全文檢索大體分兩個過程，索引建立(Indexing)和搜尋索引(Search)。
- 索引建立：将現實世界中所有的結構化和非結構化資料提取資訊，建立索引的過程。
- 搜尋索引：就是得到使用者的查詢請求，搜尋建立的索引，然後傳回結果的過程。
于是全文檢索就存在三個重要問題：
1. 索引裡面究竟存些什麼？(Index)
2. 如何建立索引？(Indexing)
3. 如何對索引進行搜尋？(Search)
下面我們順序對每個個問題進行研究。
二、索引裡面究竟存些什麼
索引裡面究竟需要存些什麼呢？
首先我們來看為什麼順序掃描的速度慢：
其實是由于我們想要搜尋的資訊和非結構化資料中所存儲的資訊不一緻造成的。
非結構化資料中所存儲的資訊是每個檔案包含哪些字元串，也即已知檔案，欲求字元串相對容易，也即是從檔案到字元串的映射。而我們想搜尋的資訊是哪些檔案包含此字元串，也即已知字元串，欲求檔案，也即從字元串到檔案的映射。兩者恰恰相反。于是如果索引總能夠儲存從字元串到檔案的映射，則會大大提高搜尋速度。
由于從字元串到檔案的映射是檔案到字元串映射的反向過程，于是儲存這種資訊的索引稱為反向索引。
反向索引的所儲存的資訊一般如下：
假設我的檔案集合裡面有100篇文檔，為了友善表示，我們為文檔編号從1到100，得到下面的結構
左邊儲存的是一系列字元串，稱為詞典。
每個字元串都指向包含此字元串的文檔(Document)連結清單，此文檔連結清單稱為倒排表(Posting List)。
有了索引，便使儲存的資訊和要搜尋的資訊一緻，可以大大加快搜尋的速度。
比如說，我們要尋找既包含字元串“lucene”又包含字元串“solr”的文檔，我們隻需要以下幾步：
1. 取出包含字元串“lucene”的文檔連結清單。
2. 取出包含字元串“solr”的文檔連結清單。
3. 通過合并連結清單，找出既包含“lucene”又包含“solr”的檔案。
看到這個地方，有人可能會說，全文檢索的确加快了搜尋的速度，但是多了索引的過程，兩者加起來不一定比順序掃描快多少。的确，加上索引的過程，全文檢索不一定比順序掃描快，尤其是在資料量小的時候更是如此。而對一個很大量的資料建立索引也是一個很慢的過程。
然而兩者還是有差別的，順序掃描是每次都要掃描，而建立索引的過程僅僅需要一次，以後便是一勞永逸的了，每次搜尋，建立索引的過程不必經過，僅僅搜尋建立好的索引就可以了。
這也是全文搜尋相對于順序掃描的優勢之一：一次索引，多次使用。
三、如何建立索引
全文檢索的索引建立過程一般有以下幾步：
第一步：一些要索引的原文檔(Document)。
為了友善說明索引建立過程，這裡特意用兩個檔案為例：
檔案一：Students should be allowed to go out with their friends, but not allowed to drink beer.
檔案二：My friend Jerry went to school to see his students but found them drunk which is not allowed.
第二步：将原文檔傳給分次元件(Tokenizer)。
分詞元件(Tokenizer)會做以下幾件事情(此過程稱為Tokenize)：
1. 将文檔分成一個一個單獨的單詞。
2. 去除标點符号。
3. 去除停詞(Stop word)。
所謂停詞(Stop word)就是一種語言中最普通的一些單詞，由于沒有特别的意義，因而大多數情況下不能成為搜尋的關鍵詞，因而建立索引時，這種詞會被去掉而減少索引的大小。
英語中挺詞(Stop word)如：“the”,“a”，“this”等。
對于每一種語言的分詞元件(Tokenizer)，都有一個停詞(stop word)集合。
經過分詞(Tokenizer)後得到的結果稱為詞元(Token)。
在我們的例子中，便得到以下詞元(Token)：
“Students”，“allowed”，“go”，“their”，“friends”，“allowed”，“drink”，“beer”，“My”，“friend”，“Jerry”，“went”，“school”，“see”，“his”，“students”，“found”，“them”，“drunk”，“allowed”。
第三步：将得到的詞元(Token)傳給語言處理元件(Linguistic Processor)。
語言處理元件(linguistic processor)主要是對得到的詞元(Token)做一些同語言相關的處理。
對于英語，語言處理元件(Linguistic Processor)一般做以下幾點：
1. 變為小寫(Lowercase)。
2. 将單詞縮減為詞根形式，如“cars”到“car”等。這種操作稱為：stemming。
3. 将單詞轉變為詞根形式，如“drove”到“drive”等。這種操作稱為：lemmatization。
Stemming 和 lemmatization的異同：
- 相同之處：Stemming和lemmatization都要使詞彙成為詞根形式。
- 兩者的方式不同：
- Stemming采用的是“縮減”的方式：“cars”到“car”，“driving”到“drive”。
- Lemmatization采用的是“轉變”的方式：“drove”到“drove”，“driving”到“drive”。
- 兩者的算法不同：
- Stemming主要是采取某種固定的算法來做這種縮減，如去除“s”，去除“ing”加“e”，将“ational”變為“ate”，将“tional”變為“tion”。
- Lemmatization主要是采用儲存某種字典的方式做這種轉變。比如字典中有“driving”到“drive”，“drove”到“drive”，“am, is, are”到“be”的映射，做轉變時，隻要查字典就可以了。
- Stemming和lemmatization不是互斥關系，是有交集的，有的詞利用這兩種方式都能達到相同的轉換。
語言處理元件(linguistic processor)的結果稱為詞(Term)。
在我們的例子中，經過語言處理，得到的詞(Term)如下：
“student”，“allow”，“go”，“their”，“friend”，“allow”，“drink”，“beer”，“my”，“friend”，“jerry”，“go”，“school”，“see”，“his”，“student”，“find”，“them”，“drink”，“allow”。
也正是因為有語言處理的步驟，才能使搜尋drove，而drive也能被搜尋出來。
第四步：将得到的詞(Term)傳給索引元件(Indexer)。
索引元件(Indexer)主要做以下幾件事情：
1. 利用得到的詞(Term)建立一個字典。
在我們的例子中字典如下：
| Term | Document ID |
| student | 1 |
| allow | 1 |
| go | 1 |
| their | 1 |
| friend | 1 |
| allow | 1 |
| drink | 1 |
| beer | 1 |
| my | 2 |
| friend | 2 |
| jerry | 2 |
| go | 2 |
| school | 2 |
| see | 2 |
| his | 2 |
| student | 2 |
| find | 2 |
| them | 2 |
| drink | 2 |
| allow | 2 |
2. 對字典按字母順序進行排序。
| Term | Document ID |
| allow | 1 |
| allow | 1 |
| allow | 2 |
| beer | 1 |
| drink | 1 |
| drink | 2 |
| find | 2 |
| friend | 1 |
| friend | 2 |
| go | 1 |
| go | 2 |
| his | 2 |
| jerry | 2 |
| my | 2 |
| school | 2 |
| see | 2 |
| student | 1 |
| student | 2 |
| their | 1 |
| them | 2 |
3. 合并相同的詞(Term)成為文檔倒排(Posting List)連結清單。
在此表中，有幾個定義：
- Document Frequency 即文檔頻次，表示總共有多少檔案包含此詞(Term)。
- Frequency 即詞頻率，表示此檔案中包含了幾個此詞(Term)。
是以對詞(Term) “allow”來講，總共有兩篇文檔包含此詞(Term)，進而詞(Term)後面的文檔連結清單總共有兩項，第一項表示包含“allow”的第一篇文檔，即1号文檔，此文檔中，“allow”出現了2次，第二項表示包含“allow”的第二個文檔，是2号文檔，此文檔中，“allow”出現了1次。
到此為止，索引已經建立好了，我們可以通過它很快的找到我們想要的文檔。
而且在此過程中，我們驚喜地發現，搜尋“drive”，“driving”，“drove”，“driven”也能夠被搜到。因為在我們的索引中，“driving”，“drove”，“driven”都會經過語言處理而變成“drive”，在搜尋時，如果您輸入“driving”，輸入的查詢語句同樣經過我們這裡的一到三步，進而變為查詢“drive”，進而可以搜尋到想要的文檔。
三、如何對索引進行搜尋？
到這裡似乎我們可以宣布“我們找到想要的文檔了”。
然而事情并沒有結束，找到了僅僅是全文檢索的一個方面。不是嗎？如果僅僅隻有一個或十個文檔包含我們查詢的字元串，我們的确找到了。然而如果結果有一千個，甚至成千上萬個呢？那個又是您最想要的檔案呢？
打開Google吧，比如說您想在微軟找份工作，于是您輸入“Microsoft job”，您卻發現總共有22600000個結果傳回。好大的數字呀，突然發現找不到是一個問題，找到的太多也是一個問題。在如此多的結果中，如何将最相關的放在最前面呢？
當然Google做的很不錯，您一下就找到了jobs at Microsoft。想象一下，如果前幾個全部是“Microsoft does a good job at software industry…”将是多麼可怕的事情呀。
如何像Google一樣，在成千上萬的搜尋結果中，找到和查詢語句最相關的呢？
如何判斷搜尋出的文檔和查詢語句的相關性呢？
這要回到我們第三個問題：如何對索引進行搜尋？
搜尋主要分為以下幾步：
第一步：使用者輸入查詢語句。
查詢語句同我們普通的語言一樣，也是有一定文法的。
不同的查詢語句有不同的文法，如SQL語句就有一定的文法。
查詢語句的文法根據全文檢索系統的實作而不同。最基本的有比如：AND, OR, NOT等。
舉個例子，使用者輸入語句：lucene AND learned NOT hadoop。
說明使用者想找一個包含lucene和learned然而不包括hadoop的文檔。
第二步：對查詢語句進行詞法分析，文法分析，及語言處理。
由于查詢語句有文法，因而也要進行文法分析，文法分析及語言處理。
1. 詞法分析主要用來識别單詞和關鍵字。
如上述例子中，經過詞法分析，得到單詞有lucene，learned，hadoop, 關鍵字有AND, NOT。
如果在詞法分析中發現不合法的關鍵字，則會出現錯誤。如lucene AMD learned，其中由于AND拼錯，導緻AMD作為一個普通的單詞參與查詢。
2. 文法分析主要是根據查詢語句的文法規則來形成一棵文法樹。
如果發現查詢語句不滿足文法規則，則會報錯。如lucene NOT AND learned，則會出錯。
如上述例子，lucene AND learned NOT hadoop形成的文法樹如下：
3. 語言處理同索引過程中的語言處理幾乎相同。
如learned變成learn等。
經過第二步，我們得到一棵經過語言處理的文法樹。
第三步：搜尋索引，得到符合文法樹的文檔。
此步驟有分幾小步：
- 首先，在反向索引表中，分别找出包含lucene，learn，hadoop的文檔連結清單。
- 其次，對包含lucene，learn的連結清單進行合并操作，得到既包含lucene又包含learn的文檔連結清單。
- 然後，将此連結清單與hadoop的文檔連結清單進行差操作，去除包含hadoop的文檔，進而得到既包含lucene又包含learn而且不包含hadoop的文檔連結清單。
- 此文檔連結清單就是我們要找的文檔。
第四步：根據得到的文檔和查詢語句的相關性，對結果進行排序。
雖然在上一步，我們得到了想要的文檔，然而對于查詢結果應該按照與查詢語句的相關性進行排序，越相關者越靠前。
如何計算文檔和查詢語句的相關性呢？
不如我們把查詢語句看作一片短小的文檔，對文檔與文檔之間的相關性(relevance)進行打分(scoring)，分數高的相關性好，就應該排在前面。
那麼又怎麼對文檔之間的關系進行打分呢？
這可不是一件容易的事情，首先我們看一看判斷人之間的關系吧。
首先看一個人，往往有很多要素，如性格，信仰，愛好，衣着，高矮，胖瘦等等。
其次對于人與人之間的關系，不同的要素重要性不同，性格，信仰，愛好可能重要些，衣着，高矮，胖瘦可能就不那麼重要了，是以具有相同或相似性格，信仰，愛好的人比較容易成為好的朋友，然而衣着，高矮，胖瘦不同的人，也可以成為好的朋友。
因而判斷人與人之間的關系，首先要找出哪些要素對人與人之間的關系最重要，比如性格，信仰，愛好。其次要判斷兩個人的這些要素之間的關系，比如一個人性格開朗，另一個人性格外向，一個人信仰佛教，另一個信仰上帝，一個人愛好打籃球，另一個愛好踢足球。我們發現，兩個人在性格方面都很積極，信仰方面都很善良，愛好方面都愛運動，因而兩個人關系應該會很好。
我們再來看看公司之間的關系吧。
首先看一個公司，有很多人組成，如總經理，經理，首席技術官，普通員工，保安，門衛等。
其次對于公司與公司之間的關系，不同的人重要性不同，總經理，經理，首席技術官可能更重要一些，普通員工，保安，門衛可能較不重要一點。是以如果兩個公司總經理，經理，首席技術官之間關系比較好，兩個公司容易有比較好的關系。然而一位普通員工就算與另一家公司的一位普通員工有血海深仇，怕也難影響兩個公司之間的關系。
因而判斷公司與公司之間的關系，首先要找出哪些人對公司與公司之間的關系最重要，比如總經理，經理，首席技術官。其次要判斷這些人之間的關系，不如兩家公司的總經理曾經是同學，經理是老鄉，首席技術官曾是創業夥伴。我們發現，兩家公司無論總經理，經理，首席技術官，關系都很好，因而兩家公司關系應該會很好。
分析了兩種關系，下面看一下如何判斷文檔之間的關系了。
首先，一個文檔有很多詞(Term)組成，如search, lucene, full-text, this, a, what等。
其次對于文檔之間的關系，不同的Term重要性不同，比如對于本篇文檔，search, Lucene, full-text就相對重要一些，this, a , what可能相對不重要一些。是以如果兩篇文檔都包含search, Lucene，fulltext，這兩篇文檔的相關性好一些，然而就算一篇文檔包含this, a, what，另一篇文檔不包含this, a, what，也不能影響兩篇文檔的相關性。
因而判斷文檔之間的關系，首先找出哪些詞(Term)對文檔之間的關系最重要，如search, Lucene, fulltext。然後判斷這些詞(Term)之間的關系。
找出詞(Term)對文檔的重要性的過程稱為計算詞的權重(Term weight)的過程。
計算詞的權重(term weight)有兩個參數，第一個是詞(Term)，第二個是文檔(Document)。
詞的權重(Term weight)表示此詞(Term)在此文檔中的重要程度，越重要的詞(Term)有越大的權重(Term weight)，因而在計算文檔之間的相關性中将發揮更大的作用。
判斷詞(Term)之間的關系進而得到文檔相關性的過程應用一種叫做向量空間模型的算法(Vector Space Model)。
下面仔細分析一下這兩個過程：
1. 計算權重(Term weight)的過程。
影響一個詞(Term)在一篇文檔中的重要性主要有兩個因素：
- Term Frequency (tf)：即此Term在此文檔中出現了多少次。tf 越大說明越重要。
- Document Frequency (df)：即有多少文檔包含次Term。df 越大說明越不重要。
容易了解嗎？詞(Term)在文檔中出現的次數越多，說明此詞(Term)對該文檔越重要，如“搜尋”這個詞，在本文檔中出現的次數很多，說明本文檔主要就是講這方面的事的。然而在一篇英國文檔中，this出現的次數更多，就說明越重要嗎？不是的，這是由第二個因素進行調整，第二個因素說明，有越多的文檔包含此詞(Term), 說明此詞(Term)太普通，不足以區分這些文檔，因而重要性越低。
這也如我們程式員所學的技術，對于程式員本身來說，這項技術掌握越深越好（掌握越深說明花時間看的越多，tf越大），找工作時越有競争力。然而對于所有程式員來說，這項技術懂得的人越少越好（懂得的人少df小），找工作越有競争力。人的價值在于不可替代性就是這個道理。
道理明白了，我們來看看公式：
這僅僅隻term weight計算公式的簡單典型實作。實作全文檢索系統的人會有自己的實作，Lucene就與此稍有不同。
2. 判斷Term之間的關系進而得到文檔相關性的過程，也即向量空間模型的算法(VSM)。
我們把文檔看作一系列詞(Term)，每一個詞(Term)都有一個權重(Term weight)，不同的詞(Term)根據自己在文檔中的權重來影響文檔相關性的打分計算。
于是我們把所有此文檔中詞(term)的權重(term weight) 看作一個向量。
Document = {term1, term2, …… ,term N}
Document Vector = {weight1, weight2, …… ,weight N}
同樣我們把查詢語句看作一個簡單的文檔，也用向量來表示。
Query = {term1, term 2, …… , term N}
Query Vector = {weight1, weight2, …… , weight N}
我們把所有搜尋出的文檔向量及查詢向量放到一個N維空間中，每個詞(term)是一維。
如圖：
我們認為兩個向量之間的夾角越小，相關性越大。
是以我們計算夾角的餘弦值作為相關性的打分，夾角越小，餘弦值越大，打分越高，相關性越大。
有人可能會問，查詢語句一般是很短的，包含的詞(Term)是很少的，因而查詢向量的維數很小，而文檔很長，包含詞(Term)很多，文檔向量維數很大。你的圖中兩者維數怎麼都是N呢？
在這裡，既然要放到相同的向量空間，自然維數是相同的，不同時，取二者的并集，如果不含某個詞(Term)時，則權重(Term Weight)為0。
相關性打分公式如下：
舉個例子，查詢語句有11個Term，共有三篇文檔搜尋出來。其中各自的權重(Term weight)，如下表格。
| t1 | t2 | t3 | t4 | t5 | t6 | t7 | t8 | t9 | t10 | t11 |
| D1 | .477 | .477 | .176 | .176 | ||||||
| D2 | .176 | .477 | .954 | .176 | ||||||
| D3 | .176 | .176 | .176 | .176 | ||||||
| Q | .176 | .477 | .176 |
于是計算，三篇文檔同查詢語句的相關性打分分别為：
于是文檔二相關性最高，先傳回，其次是文檔一，最後是文檔三。
到此為止，我們可以找到我們最想要的文檔了。
說了這麼多，其實還沒有進入到Lucene，而僅僅是資訊檢索技術(Information retrieval)中的基本理論，然而當我們看過Lucene後我們會發現，Lucene是對這種基本理論的一種基本的的實踐。是以在以後分析Lucene的文章中，會常常看到以上理論在Lucene中的應用。
在進入Lucene之前，對上述索引建立和搜尋過程所一個總結，如圖：
此圖參照http://www.lucene.com.cn/about.htm中文章《開放源代碼的全文檢索引擎Lucene》
1. 索引過程：
1) 有一系列被索引檔案
2) 被索引檔案經過文法分析和語言處理形成一系列詞(Term)。
3) 經過索引建立形成詞典和反向索引表。
4) 通過索引存儲将索引寫入硬碟。
2. 搜尋過程：
a) 使用者輸入查詢語句。
b) 對查詢語句經過文法分析和語言分析得到一系列詞(Term)。
c) 通過文法分析得到一個查詢樹。
d) 通過索引存儲将索引讀入到記憶體。
e) 利用查詢樹搜尋索引，進而得到每個詞(Term)的文檔連結清單，對文檔連結清單進行交，差，并得到結果文檔。
f) 将搜尋到的結果文檔對查詢的相關性進行排序。
g) 傳回查詢結果給使用者。
下面我們可以進入Lucene的世界了。
另：
CSDN中此文章連結為http://blog.csdn.net/forfuture1978/archive/2009/10/22/4711308.aspx
Javaeye中此文章連結為http://forfuture1978.javaeye.com/blog/546771