簡單理解 倒排索引
最近學習ES看到這個文章：https://es.xiaoleilu.com/052_Mapping_Analysis/35_Inverted_index.html
對初步瞭解es挺好的。
Elasticsearch使用一種叫做倒排索引(inverted index)的結構來做快速的全文搜尋。倒排索引由在文件中出現的唯一的單詞列表，以及對於每個單詞在文件中的位置組成。
例如，我們有兩個文件，每個文件content欄位包含：
- The quick brown fox jumped over the lazy dog
- Quick brown foxes leap over lazy dogs in summer
為了建立倒排索引，我們首先切分每個文件的content欄位為單獨的單詞（我們把它們叫做詞(terms)或者表徵(tokens)）（譯者注：關於terms和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 |
兩個文件都匹配，但是第一個比第二個有更多的匹配項。 如果我們加入簡單的相似度演算法(similarity algorithm)，計算匹配單詞的數目，這樣我們就可以說第一個文件比第二個匹配度更高——對於我們的查詢具有更多相關性。
但是在我們的倒排索引中還有些問題：
"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"，這樣就可以匹配到兩個文件。