資訊檢索導論——四、索引構建
課件網址http://www.docin.com/p-473651858.html
1、硬體基礎
2、基於塊的排序索引方法
3、記憶體式單遍掃描索引構建演算法
4、分散式索引構建
5、動態索引構建
6、安全性和排序式檢索中的索引問題
1、硬體基礎
與IR系統的設計相關的硬體基本效能引數如下：
1）訪問記憶體資料比訪問磁碟資料快得多（10倍左右）
2）硬碟尋道時間不進行資料傳輸，所以連續讀取的資料塊應在磁碟上連續存放
3）操所繫統往往以資料塊為單位進行讀寫，因此從磁碟讀取一個位元組和一個數據塊耗時可能一樣多（8KB到256KB不等）
4）資料從磁碟傳輸到記憶體是由系統匯流排而不是處理器來實現的，這意味著在磁碟I/O時處理器仍然可以處理資料。（比如將資料壓縮後儲存在磁碟上，若採用高效解壓縮演算法，那麼讀磁碟壓縮資料再解壓所花時間往往比直接讀取未壓縮資料的時間少）。
5）IR系統伺服器典型配置有幾GB或者幾十GB的記憶體，磁碟空間大小一般比記憶體大小高几個數量級
6）容錯處理的代價非常昂貴，採用多臺普通機器會比一臺提供容錯的機器的價格更便宜。
2、基於塊的排序索引方法——BSBI（blocked sort-based indexing algorithm）
由於將所有的詞項ID-文件ID對放在記憶體進行排序可能是一件困難的事情，所以我們必須使用基於磁碟的外部排序演算法。為了達到可以接受的速度，對該演算法的核心要求是：
1）將文件集分割成幾個大小相等的部分
2）將每個部分的詞項ID-文件ID對排序
3）將中間產生的臨時排序結果存放到磁碟中
4）將所有的中間檔案合併成最終的索引。
上述演算法實現的最後一步的方法如下圖：記憶體中維護了為10個塊準備的讀緩衝區和一個為最終合併索引準備的寫緩衝區。
BSBI演算法複雜度：由於最主要的時間消耗在排序上，所以時間複雜度為，其中T為所需排序的項數目的上界（詞項ID-文件ID對的個數）
3、記憶體式單遍掃描索引構建演算法 SPIMI
基於塊的排序索引演算法具有很好的可擴充套件性,但是需要一種將詞項對映成其 ID 的資料結構。對於大規模的文件集來說,該資料結構會很大以致在記憶體中難以存放。一種更具擴充套件性的演算法稱為 SPIMI(single-pass in-memory indexing,記憶體式單遍掃描索引演算法)。SPIMI 使用詞項而不是其 ID,它將每個塊的詞典寫入磁碟,對於下一個塊則重新採用新的詞典。只要硬碟空間足夠大,SPIMI 就能夠索引任何大小的文件集。
SPIMI 演算法的流程如圖 4-4 所示,其中省略了文件分析以及將文件轉換成詞項—文件 ID 流(算 法中稱為 token_stream)的過程。反覆呼叫 SPIMI-INVERT 函式直到將全部的文件集處理完為止。
【BSBI 和 SPIMI 的區別】
1、BSBI對TokenHit排序，所以排序的時間基準是TokenHit的個數。SPIMI對詞項排序，排序的基準是Token的個數，所以SPIMI對排序的時間大大減小。
2、BSBI需要使用一個數據結構將詞項轉變成詞項ID。SPIMI不需要，省記憶體。
【分散式索引構建】
使用mapreduce即可。
【動態索引構建】
大部分文件集會隨文件的增加、刪除或更新而不斷改變。這也意味著需要將新的詞項加入詞典,並對已有詞項的倒排記錄表進行更新。如果要求能夠及時檢索到新文件,那麼一種解決方法是同時保持兩個索引:一個是大的主索引,另一個是小的用於儲存新文件資訊的輔助索引(auxiliary index),後者儲存在記憶體中。檢索時可以同時遍歷兩個索引並將結果合併。
問題：
1、按目前架構，不更新索引，只更新屬性，所以如果一個文件發生變化，則新的Token會被無視。不過一個條文件釋出後，無法編輯，所以不存在此問題。
2、對於文件的刪除，從TokenID找到DocID，那麼Doc的屬性中會記錄此文件是否被刪除再決定是否展現。另外，按照目前架構，如果有大量文件被刪除，對於已新索引，則會存在大量空的情況。
沒有編輯完，後部分參照：
http://www.cnblogs.com/tekkaman/archive/2013/09/11/3315822.html