3.1. Lucene核心部分——索引排序
Lucene 的索引排序是使用了倒排序原理。
該結構及相應的生成算法如下：
設有兩篇文章1和2
文章1的內容爲：Tom lives in Guangzhou,I live in Guangzhou too.
文章2的內容爲：He once lived in Shanghai.
1. 由於lucene是基於關鍵詞索引和查詢的，首先我們要取得這兩篇文章的關鍵詞，通常我們需要如下處理措施
a. 我們現在有的是文章內容，即一個字符串，我們先要找出字符串中的所有單詞，即分詞。英文單詞由於用空格分隔，比較好處理。中文單詞間是連在一起的需要特殊的分詞處理。
b. 文章中的”in”, “once” “too”等詞沒有什麼實際意義，中文中的“的”“是”等字通常也無具體含義， 這些不代表概念的詞可以過濾掉，這個也就是在《Lucene詳細分析》中所講的StopTokens
c. 用戶通常希望查“He”時能把含“he”，“HE”的文章也找出來，所以所有單詞需要統一大小寫。
d. 用戶通常希望查“live”時能把含“lives”，“lived”的文章也找出來，所以需要把“lives”，“lived”還原成“live”
e. 文章中的標點符號通常不表示某種概念，也可以過濾掉,在lucene中以上措施由Analyzer類完成,經過上面處理後:
文章1的所有關鍵詞爲：[tom] [live] [guangzhou] [live] [guangzhou]
文章2的所有關鍵詞爲：[he] [live] [shanghai]
2. 有了關鍵詞後，我們就可以建立倒排索引了
上面的對應關係是：“文章號”對“文章中所有關鍵詞”。倒排索引把這個關係倒過來，變成：“關鍵詞”對“擁有該關鍵詞的所有文章號”。文章1，2經過倒排後變成
<!--[if !supportLineBreakNewLine]-->
關鍵詞
文章號
guangzhou
1
he
2
i
1
live
1,2
shanghai
2
tom
1
通常僅知道關鍵詞在哪些文章中出現還不夠，我們還需要知道關鍵詞在文章中出現次數和出現的位置，通常有兩種位置：a)字符位置，即記錄該詞是文章中第幾個字符（優點是關鍵詞亮顯時定位快）；b)關鍵詞位置，即記錄該詞是文章中第幾個關鍵詞（優點是節約索引空間、詞組（phase）查詢快），lucene中記錄的就是這種位置。
加上“出現頻率”和“出現位置”信息後，我們的索引結構變爲：
關鍵詞
文章號[出現頻率]
出現位置
guangzhou
1[2]
3，6
he
2[1]
1
i
1[1]
4
live
1[2],2[1]
2，5，2
shanghai
2[1]
3
tom
1[1]
1
以live 這行爲例我們說明一下該結構：live在文章1中出現了2次，文章2中出現了一次，它的出現位置爲“2,5,2”這表示什麼呢？我們需要結合文章號和出現頻率來分析，文章1中出現了2次，那麼“2,5”就表示live在文章1中出現的兩個位置，文章2中出現了一次，剩下的“2”就表示live是文章2中第 2個關鍵字。
以上就是lucene索引結構中最核心的部分。我們注意到關鍵字是按字符順序排列的（lucene沒有使用B樹結構），因此lucene可以用二元搜索算法快速定位關鍵詞。
實現時 lucene將上面三列分別作爲詞典文件（Term Dictionary）、頻率文件(frequencies)、位置文件 (positions)保存。其中詞典文件不僅保存有每個關鍵詞，還保留了指向頻率文件和位置文件的指針，通過指針可以找到該關鍵字的頻率信息和位置信息。
Lucene中使用了field的概念，用於表達信息所在位置（如標題中，文章中，url中），在建索引中，該field信息也記錄在詞典文件中，每個關鍵詞都有一個field信息(因爲每個關鍵字一定屬於一個或多個field)。
爲了減小索引文件的大小，Lucene對索引還使用了壓縮技術。首先，對詞典文件中的關鍵詞進行了壓縮，關鍵詞壓縮爲<前綴長度，後綴>，例如：當前詞爲“阿拉伯語”，上一個詞爲“阿拉伯”，那麼“阿拉伯語”壓縮爲<3，語>。其次大量用到的是對數字的壓縮，數字只保存與上一個值的差值（這樣可以減小數字的長度，進而減少保存該數字需要的字節數）。例如當前文章號是16389（不壓縮要用3個字節保存），上一文章號是16382，壓縮後保存7（只用一個字節）。
下面我們可以通過對該索引的查詢來解釋一下爲什麼要建立索引。
假設要查詢單詞 “live”，lucene先對詞典二元查找、找到該詞，通過指向頻率文件的指針讀出所有文章號，然後返回結果。詞典通常非常小，因而，整個過程的時間是毫秒級的。
而用普通的順序匹配算法，不建索引，而是對所有文章的內容進行字符串匹配，這個過程將會相當緩慢，當文章數目很大時，時間往往是無法忍受的。
3.2. Lucene的相關度積分公式
score_d = sum_t(tf_q * idf_t / norm_q * tf_d * idf_t / norm_d_t * boost_t) * coord_q_d
註解：
score_d : 該文檔d的得分
sum_t : 所有項得分的總和
tf_q : 查詢串q中，某個項出項的次數的平方根
tf_d : 文檔d中 ，出現某個項的次數的平方根
numDocs : 在這個索引裏，找到分數大於0的文檔的總數
docFreq_t : 包含項t的文檔總數
idf_t : log(numDocs/docFreq+1)+1.0
norm_q : sqrt(sum_t((tf_q*idf_t)^2))
norm_d_t : 在文檔d中，與項t相同的域中，所有的項總數的平方根
boost_t : 項t的提升因子，一般爲 1.0
coord_q_d : 在文檔d中，命中的項數量除以查詢q的項總數
3.3. Lucene的其他特性
3.3.1. Boosting特性
luncene對Document和Field提供了一個可以設置的Boosting參數， 這個參數的用處是告訴lucene， 某些記錄更重要，在搜索的時候優先考慮他們 比如在搜索的時候你可能覺得幾個門戶的網頁要比垃圾小站更優先考慮
lucene默認的boosting參數是1.0, 如果你覺得這個field重要,你可以把boosting設置爲1.5, 1.2....等, 對Document設置boosting相當設定了它的每個Field的基準boosting，到時候實際Field的boosting就是(Document-boosting*Field-boosting)設置了一遍相同的boosting.
似乎在lucene的記分公式裏面有boosting參數,不過我估計一般人是不會去研究他的公式的（複雜）,而且公式也無法給出最佳值，所以我們所能做的只能是一點一點的改變boosting, 然後在實際檢測中觀察它對搜索結果起到多大的作用來調整
一般的情況下是沒有必要使用boosting的, 因爲搞不好你就把搜索給搞亂了, 另外如果是單獨對Field來做Bossting, 也可以通過將這個Field提前來起到近似的效果
3.3.2. Indexing Date
日期是lucene需要特殊考慮的地方之一, 因爲我們可能需要對日期進行範圍搜索, Field.keyword(string,Date)提供了這樣的方法,lucene會把這個日期轉換爲string, 值得注意的是這裏的日期是精確到毫秒的,可能會有不必要的性能損失, 所以我們也可以把日期自行轉化爲YYYYMMDD這樣的形勢,就不用精確到具體時間了,通過File.keyword(Stirng,String) 來index, 使用PrefixQuery 的YYYY一樣能起到簡化版的日期範圍搜索(小技巧), lucene提到他不能處理1970年以前的時間,似乎是上一代電腦系統遺留下來的毛病
3.3.3. Indexing 數字
如果數字只是簡單的數據, 比如中國有56個民族. 那麼可以簡單的把它當字符處理
如果數字還包含數值的意義,比如價格, 我們會有範圍搜索的需要(20元到30元之間的商品),那麼我們必須做點小技巧, 比如把3,34,100 這三個數字轉化爲003,034,100 ,因爲這樣處理以後, 按照字符排序和按照數值排序是一樣的,而lucene內部按照字符排序,003->034->100 NOT(100->3->34)
3.3.4. 排序
Lucene默認按照相關度(score)排序,爲了能支持其他的排序方式,比如日期,我們在add Field的時候,必須保證field被Index且不能被tokenized(分詞),並且排序的只能是數字,日期,字符三種類型之一
3.3.5. Lucene的IndexWriter調整
IndexWriter提供了一些參數可供設置，列表如下
屬性
默認值
說明
mergeFactor
org.apache.lucene.mergeFactor
10
控制index的大小和頻率,兩個作用
maxMergeDocs
org.apache.lucene.maxMergeDocs
Integer.MAX_VALUE
限制一個段中的document數目
minMergeDocs
org.apache.lucene.minMergeDocs
10
緩存在內存中的document數目，超過他以後會寫入到磁盤
maxFieldLength
1000
一個Field中最大Term數目，超過部分忽略，不會index到field中，所以自然也就搜索不到
這些參數的的詳細說明比較複雜：mergeFactor有雙重作用
設置每mergeFactor個document寫入一個段，比如每10個document寫入一個段
設置每mergeFacotr個小段合併到一個大段，比如10個document的時候合併爲1小段，以後有10個小段以後合併到一個大段，有10個大段以後再合併，實際的document數目會是mergeFactor的指數
簡單的來說mergeFactor 越大，系統會用更多的內存，更少磁盤處理，如果要打批量的作index，那麼把mergeFactor設置大沒錯， mergeFactor 小了以後， index數目也會增多，searhing的效率會降低， 但是mergeFactor增大一點一點，內存消耗會增大很多(指數關係),所以要留意不要"out of memory"
把maxMergeDocs設置小，可以強制讓達到一定數量的document寫爲一個段，這樣可以抵消部分mergeFactor的作用.
minMergeDocs相當於設置一個小的cache,第一個這個數目的document會留在內存裏面，不寫入磁盤。這些參數同樣是沒有最佳值的， 必須根據實際情況一點點調整。
maxFieldLength可以在任何時刻設置， 設置後，接下來的index的Field會按照新的length截取，之前已經index的部分不會改變。可以設置爲Integer.MAX_VALUE
3.3.6. RAMDirectory 和 FSDirectory 轉化
RAMDirectory(RAMD)在效率上比FSDirectyr(FSD)高不少, 所以我們可以手動的把RAMD當作FSD的buffer,這樣就不用去很費勁的調優FSD那麼多參數了,完全可以先用RAM跑好了index， 週期性（或者是別的什麼算法）來回寫道FSD中。 RAMD完全可以做FSD的buffer。
3.3.7. 爲查詢優化索引(index)
Indexwriter.optimize()方法可以爲查詢優化索引（index），之前提到的參數調優是爲indexing過程本身優化，而這裏是爲查詢優化，優化主要是減少index文件數，這樣讓查詢的時候少打開文件，優化過程中，lucene會拷貝舊的index再合併，合併完成以後刪除舊的index，所以在此期間，磁盤佔用增加， IO符合也會增加，在優化完成瞬間，磁盤佔用會是優化前的2倍,在optimize過程中可以同時作search。
3.3.8. 併發操作Lucene和locking機制
v 所有隻讀操作都可以併發
v 在index被修改期間，所有隻讀操作都可以併發
v 對index修改操作不能併發，一個index只能被一個線程佔用
v index的優化，合併，添加都是修改操作
v IndexWriter和IndexReader的實例可以被多線程共享，他們內部是實現了同步，所以外面使用不需要同步
3.3.9. Locing
lucence內部使用文件來locking， 默認的locking文件放在java.io.tmpdir,可以通過-Dorg.apache.lucene.lockDir=xxx指定新的dir，有write.lock commit.lock兩個文件，lock文件用來防止並行操作index，如果並行操作， lucene會拋出異常，可以通過設置-DdisableLuceneLocks=true來禁止locking，這樣做一般來說很危險，除非你有操作系統或者物理級別的只讀保證，比如把index文件刻盤到CDROM上。
