[IR] Index Construction

拋出問題

倒排索引的構建

Three steps to construct Inverted Index as following:

海量term排序

最難的step中：

1. 1. Token sequence.
   2. Sort by term.
   3. Dictionary & Postings

第2步中的最現實的問題是：假如100G的terms如何排序？

參考文檔：http://home.ustc.edu.cn/~zhufengx/ir/pdf/solution.pdf【不錯的課件內容】

 

 

 

External Sorting Algorithm (外排)

基於塊的排序索引方法 BSBI（blocked sort-based indexing algorithm）

 

註釋：

4. 文檔集讀取

5. 排序

6. 排序結果f_i 存放到disk

7. Merge 這些排序結果爲一個總體的Inverted Index list. 使用小窗口一點點地放入min-heap，

   堆頂端輸出的是Inverted Index list的 dictionary部分，由小變大的順序（由於f_i 已排序）

 

註解：說白了就是「兩個有序鏈表的合併」。

• • 須要將詞項映射成詞項ID，必須事先知道詞項的排序（知道整個詞 典）。
  • 全部的塊共享一個全局的大詞典。
  • 若是在每塊的處理中，不將詞項映射成詞項ID，而是直接對「詞項-文 檔ID」對進行排序，排序的代價將大大增長（整數的比較VS字符串的 比較）。

 

小缺陷

由於實際使用的是ID。而且一開始就整理出全部的詞項 ID—文檔 ID 並對它們進行排序的作法。

既然要排序，因此相對耗時。

 

 

內存式單遍掃描索引構建方法

 

註釋：

擁有同一hash value的terms的排序設計:

Insert-at-back and move-to-front heuristic 

 

每一個塊f_i 創建新dict；
去除了高代價的sort

最後一步依然是 MergeBlocks(.)

 

突出特色

用了詞對索引的直接關聯。還有1個比較大的特色是他不通過排序，直接按照前後順序構建索引。

Term list採用了hash的方式去查找，故構建的過程當中不須要排序。

 

 

動態索引 - Dynamic Indexing

同時保持着兩個索引：一個是大的主索引，另一個是用於存儲新文檔信息的輔助索引。

其中輔助索引保存在內存中，輔助索引用於對文檔新增內容創建索引，用戶在檢索時對主索引和輔助索引一塊兒檢索，當輔助索引很大時候，將其與磁盤中的主索引進行合併；

 

註釋：

Main Index在Disk; Auxiliary Index在Memory。

能夠視爲 Immediate Merge 與 No merge 的一個折中。

因爲每一個倒排記錄在 log₂(T/n)層 的每一層中都只處理一次，所以整個索引構建的時間是Θ(T*log₂(T/n))。

 

引申：

求Disk中最後留下的Index的數量。

We use |C| to denote the total size of the document collection, and M to denote the memory size.

Let's assume that: C = h*M

For i in [0, log2h]
{
　　X = [h - (2i – 1)] mod [2i+1]
　　If X belong to (0, 2i],
　　　　exist in column.
　　Else,
　　　　not exist.
}

The sum of existing X is the answer.

 

 

 

大數據量排序

數據多到內存裝不下怎麼辦？

假設內存有100M容量

好比1G的數據，分10份，每份100M。先用快排讓每一份各自排好序，而後寫到文件中。這10份100M的 文件這個時候已經有序了。

這10份每份取9M，一共90M，使得他們合併。合併後的結果放到10M的緩存區中，滿了就clear，IO到 文件中。

理解

有點小根對的意思，例如老是將最小的數字放入10M緩存中，放滿後也就是top 10M小的elements，而後save to disk中。

 

End.