ElasticSearch教程——倒排索引及其資料結構以及優缺點
ElasticSearch彙總請檢視：ElasticSearch教程——彙總篇
倒排索引
Elasticsearch 使用一種稱為 倒排索引 的結構，它適用於快速的全文搜尋。一個倒排索引由文件中所有不重複詞的列表構成，對於其中每個詞，有一個包含它的文件列表。
例如，假設我們有兩個文件，每個文件的 content 域包含如下內容：
- The quick brown fox jumped over the lazy dog
- Quick brown foxes leap over lazy dogs in summer
為了建立倒排索引，我們首先將每個文件的 content 域拆分成單獨的 詞（我們稱它為 詞條 或 tokens），建立一個包含所有不重複詞條的排序列表，然後列出每個詞條出現在哪個文件。結果如下所示：
Term Doc_1 Doc_2 ------------------------- Quick | | X The | X | brown | X | X dog | X | dogs | | X fox | X | foxes | | X in | | X jumped | X | lazy | X | X leap | | X over | X | X quick | X | summer | | X the | X | ------------------------
現在，如果我們想搜尋 quick brown ，我們只需要查詢包含每個詞條的文件：
Term Doc_1 Doc_2
-------------------------
brown | X | X
quick | X |
------------------------
Total | 2 | 1兩個文件都匹配，但是第一個文件比第二個匹配度更高。如果我們使用僅計算匹配詞條數量的簡單 相似性演算法 ，那麼，我們可以說，對於我們查詢的相關性來講，第一個文件比第二個文件更佳。
但是，我們目前的倒排索引有一些問題：
Quick和quick以獨立的詞條出現，然而使用者可能認為它們是相同的詞。fox和foxes非常相似, 就像dog和dogs；他們有相同的詞根。jumped和leap, 儘管沒有相同的詞根，但他們的意思很相近。他們是同義詞。
使用前面的索引搜尋 +Quick +fox 不會得到任何匹配文件。（記住，+ 字首表明這個詞必須存在。）只有同時出現 Quick 和 fox 的文件才滿足這個查詢條件，但是第一個文件包含 quick fox ，第二個文件包含 Quick foxes 。
我們的使用者可以合理的期望兩個文件與查詢匹配。我們可以做的更好。
如果我們將詞條規範為標準模式，那麼我們可以找到與使用者搜尋的詞條不完全一致，但具有足夠相關性的文件。例如：
Quick可以小寫化為quick。foxes可以 詞幹提取 --變為詞根的格式-- 為fox。類似的，dogs可以為提取為dog。jumped和leap是同義詞，可以索引為相同的單詞jump。
現在索引看上去像這樣：
Term Doc_1 Doc_2
-------------------------
brown | X | X
dog | X | X
fox | X | X
in | | X
jump | X | X
lazy | X | X
over | X | X
quick | X | X
summer | | X
the | X | X
------------------------這還遠遠不夠。我們搜尋 +Quick +fox 仍然 會失敗，因為在我們的索引中，已經沒有 Quick 了。但是，如果我們對搜尋的字串使用與 content 域相同的標準化規則，會變成查詢 +quick +fox ，這樣兩個文件都會匹配！
倒排索引結構
（1）包含這個關鍵詞的document list
（2）包含這個關鍵詞的所有document的數量：IDF（inverse document frequency）
（3）這個關鍵詞在每個document中出現的次數：TF（term frequency）
（4）這個關鍵詞在這個document中的次序
（5）每個document的長度：length norm
（6）包含這個關鍵詞的所有document的平均長度
倒排索引不可變
優點
（1）不需要鎖，提升併發能力，避免鎖的問題
（2）資料不變，一直儲存在os cache中，只要cache記憶體足夠
（3）filter cache一直駐留在記憶體，因為資料不變
（4）可以壓縮，節省cpu和io開銷
缺點
每次都要重新構建整個索引，比較繁瑣。