1.概述
在關系數據庫系統里，索引是檢索數據最有效率的方式,。但對于搜索引起，他它并不能滿足其特殊要求：
1）海量數據：搜索引擎面對的是海量數據，像Google，百度這樣大型的商業搜索引擎索引都是億級甚至幾千的網頁數量 ，面對如此海量數據 ,使得數據庫系統很難有效的管理。
2）數據操作簡單：搜索引擎使用的數據操作簡單 ,一般而言 ,只需要增、 刪、 改、 查幾個功能 ,而且數據都有特定的格式 ,可以針對這些應用設計出簡單高效的應用程序。而一般的數據庫系統則支持大而全的功能 ,同時損失了速度和空間。最后 ,搜索引擎面臨大量的用戶檢索需求 ,這要求搜索引擎在檢索程序的設計上要分秒必爭 ,盡可能的將大運算量的工作在索引建立時完成 ,使檢索運算盡量的少。一般的數據庫系統很難承受如此大量的用戶請求 ,而且在檢索響應時間和檢索并發度上都不及我們專門設計的索引系統。
2.倒排索引
來自維基百科定義：
倒排索引（英語：Inverted index），也常被稱為反向索引、置入檔案或反向檔案，是一種索引方法，被用來存儲在全文搜索下某個單詞在一個文檔或者一組文檔中的存儲位置的映射。它是文檔檢索系統中最常用的數據結構。通過倒排索引，可以根據單詞快速獲取包含這個單詞的文檔列表。倒排索引主要由兩個部分組成：“單詞詞典”和“倒排文件”。
倒排索引有兩種不同的反向索引形式：
一條記錄的水平反向索引（或者反向檔案索引）包含每個引用單詞的文檔的列表。
一個單詞的水平反向索引（或者完全反向索引）又包含每個單詞在一個文檔中的位置。
后者的形式提供了更多的兼容性（比如短語搜索），但是需要更多的時間和空間來創建。
現代搜索引起的索引都是基于倒排索引。相比“簽名文件”、“后綴樹”等索引結構，“倒排索引”是實現單詞到文檔映射關系的最佳實現方式和最有效的索引結構.
倒排索引的簡單實例： 搜索引擎-倒排索引基礎知識
3.倒排列表
倒排列表用來記錄有哪些文檔包含了某個單詞。一般在文檔集合里會有很多文檔包含某個單詞，每個文檔會記錄文檔編號（DocID），單詞在這個文檔中出現的次數（TF）及單詞在文檔中哪些位置出現過等信息，這樣與一個文檔相關的信息被稱做倒排索引項（Posting），包含這個單詞的一系列倒排索引項形成了列表結構，這就是某個單詞對應的倒排列表。圖1是倒排列表的示意圖，在文檔集合中出現過的所有單詞及其對應的倒排列表組成了倒排索引。
圖1 倒排列表
在實際的搜索引擎系統中，并不存儲倒排索引項中的實際文檔編號，而是代之以文檔編號差值（D-Gap）。文檔編號差值是倒排列表中相鄰的兩個倒排索引項文檔編號的差值，一般在索引構建過程中，可以保證倒排列表中后面出現的文檔編號大于之前出現的文檔編號，所以文檔編號差值總是大于0的整數。如圖2所示的例子中，原始的 3個文檔編號分別是187、196和199，通過編號差值計算，在實際存儲的時候就轉化成了：187、9、3。
圖2 文檔編號差值
之所以要對文檔編號進行差值計算，主要原因是為了更好地對數據進行壓縮，原始文檔編號一般都是大數值，通過差值計算，就有效地將大數值轉換為了小數值，而這有助于增加數據的壓縮率。
4.建立倒排索引
4.1 簡單索引構建
索引的構建相當于從正排表到倒排表的建立過程。當我們分析完網頁時 ,得到的是以網頁為主碼的索引表。當索引建立完成后 ,應得到倒排表 ,具體流程如圖3所示：
圖3 索引構建
流程：
1）將文檔分析稱單詞term標記，
2）使用hash去重單詞term
3）對單詞生成倒排列表
倒排列表就是文檔編號DocID，沒有包含其他的信息（如詞頻，單詞位置等），這就是簡單的索引。
這個簡單索引功能可以用于小數據，例如索引幾千個文檔。然而它有兩點限制：
1）需要有足夠的內存來存儲倒排表，對于搜索引擎來說， 都是G級別數據，特別是當規模不斷擴大時 ,我們根本不可能提供這么多的內存。
2）算法是順序執行，不便于并行處理。
4.3 合并法建立索引
歸并法,即每次將內存中數據寫入磁盤時，包括詞典在內的所有中間結果信息都被寫入磁盤，這樣內存所有內容都可以被清空，后續建立索引可以使用全部的定額內存。
如圖4 歸并示意圖：
圖4：歸并索引
合并流程如圖5：
1）頁面分析，生成臨時倒排數據索引A，B，當臨時倒排數據索引A，B占滿內存后，將內存索引A，B寫入臨時文件生成臨時倒排文件，
2) 對生成的多個臨時倒排文件 ,執行多路歸并 ,輸出得到最終的倒排文件 ( inverted file)。
圖5 合并流程
索引創建過程中的頁面分析 ,特別是中文分詞為主要時間開銷。算法的第二步相對很快。這樣創建算法的優化集中在中文分詞效率上。
4.2 并行與分布式建立索引
在 搜索引擎-網絡爬蟲, 已經提到云存儲文檔，使用Map/Reduce并行計算模型，對文檔生成倒排索引列：
對于建立倒排索引這個任務來說，如圖6所示，輸入數據也是網頁，以網頁的DOCID作為輸入數據 的Key, 網頁中出現的單詞集合是輸入數據的 Value; Map 操作將輸入數據轉化為 (word，DOCID)的形式，即某個單詞作為Key， DOCID作為中間數據的value，其含義是單詞 word在DOCID這個網頁出現過；Reduce操作將中間數據中相同Key的記錄融合，得到某 個單詞對應的網頁ID列表： <word，List(DodD:pos)>。這就是單詞word對應的倒排列表。通過 這種方式就可以建立簡單的倒排索引，在Reduce階段也可以做些復雜操作，獲得形式更為復雜的倒排索引。
圖6
5.索引更新策略
更新策略有四種：完全重建、再合并策略、原地更新策略以及混合策略。
-
完全重建策略：當新增文檔到達一定數量，將新增文檔和原先的老文檔整合，然后利用靜態索引創建方法對所有文檔重建索引，新索引建立完成后老索引會被遺棄。此法代價高，但是目前主流商業搜索引擎一般是采用此方式來維護索引的更新（這句話是書中原話）
-
再合并策略：當新增文檔進入系統，解析文檔，之后更新內存中維護的臨時索引，文檔中出現的每個單詞，在其倒排表列表末尾追加倒排表列表項；一旦臨時索引將指定內存消耗光，即進行一次索引合并，這里需要倒排文件里的倒排列表存放順序已經按照索引單詞字典順序由低到高排序，這樣直接順序掃描合并即可。其缺點是：因為要生成新的倒排索引文件，所以對老索引中的很多單詞，盡管其在倒排列表并未發生任何變化，也需要將其從老索引中取出來并寫入新索引中，這樣對磁盤消耗是沒必要的。
-
原地更新策略：試圖改進再合并策略，在原地合并倒排表，這需要提前分配一定的空間給未來插入，如果提前分配的空間不夠了需要遷移。實際顯示，其索引更新的效率比再合并策略要低。
-
混合策略：出發點是能夠結合不同索引更新策略的長處，將不同索引更新策略混合，以形成更高效的方法。
轉自：http://blog.csdn.net/hguisu/article/details/7969757
原創文章，作者：s19930811，如若轉載，請注明出處：http://www.www58058.com/2735
