引子
很多搜尋引擎都是基于反向索引，比如luncene，solr以及elasticsearch
正排索引
聊倒排搜尋之前先來看看正排索引，正排其實就是資料庫表，他通過id和資料進行關聯，如下：
| 資料id | 資料内容 |
|---|---|
| 1001 | 蘋果公司釋出iPhone |
| 1002 | 地球引力起源于蘋果 |
| 1003 | iPhone螢幕碎了 |
| 1004 | 我在蘋果商店維修螢幕 |
| 1005 | 我剛剛吃了蘋果 |
我們可以通過搜尋id，來獲得相應的資料，也能删除資料。你買了一本書，書的目錄其實也是正排搜尋。
假設現在我要搜
蘋果
倆字，那麼他會對這張表格中每一行的資料做比對，去查找一下，是否包含
蘋果
這兩個字，從第一條比對到最後一條，如果一張表中資料量不多，幾萬，十幾萬，那麼問題不大，但是一旦資料量有上百萬，上千萬，那麼全表掃描這種的搜尋性能就會有影響。
其次，這個時候我想搜尋
蘋果iPhone
，那麼我們無法把這詞彙拆開再到資料庫去搜尋。
- 優點：使用起來友善，原理也簡單，比較入門
- 缺點：檢索效率低下，适合簡單場景使用，比如傳統項目，資料量較小的項目。不支援分詞搜尋。
反向索引
與正排是反着來的，他會把文檔内容進行分詞，比如
蘋果公司釋出iPhone
是一個文檔資料，當我們把他存入到搜尋引擎中去的時候，會有一個文檔id，這個文檔id就類似于資料庫主鍵。但是這文檔存儲的時候和資料庫不一樣，他會進行一個分詞，參照上面的表格，分詞後的結果如下：
| 文檔資料 | 分詞結果 |
|---|---|
| 蘋果，公司，釋出，iPhone | |
| 地球，引力，起源，于，蘋果 | |
| iPhone，螢幕，碎了 | |
| 我，在，蘋果，商店，維修，螢幕 | |
| 我，剛剛，吃了，蘋果 |
每一個詞彙都會和文檔id關聯起來，可以根據詞彙來找到所有出現的id清單，如下：
| 詞彙 | 文檔ids |
|---|---|
| 蘋果 | 1001，1002，1004，1005 |
| iPhone | 1001，1003 |
| 公司 | |
| 釋出 | |
| 地球 | |
| 引力 | |
| 起源 | |
| 于 | |
| 螢幕 | 1003，1004 |
| 碎了 | |
| 我 | 1004，1005 |
| 在 | |
| 商店 | |
| 維修 | |
| 剛剛 | |
| 吃了 |
假設現在我要搜尋
iPhone
，如果是資料庫搜尋，假設有1億條資料，那麼會比對1億次，全表掃描。最後再把資料傳回出來。
如果是搜尋引擎，那麼有可能第一次就把所有文檔資料給查出來，當然也有可能是第N次，當然他肯定要比資料庫的搜尋效率更高。如圖中位置，他會直接把
1001，1003
兩個文檔傳回。
可能會有同學會問，資料庫和搜尋引擎都是1000萬資料，搜尋的詞彙在搜尋引擎中正好是第1000萬條，那麼會不會慢，其實這個肯定會比資料庫更快，資料庫要比對是一個文本中的内容和關鍵詞比對，而搜尋引擎是直接把關鍵字做比對，效率肯定後者更快。
- 有點：搜尋更快，耗時短，使用者體驗高，精裝度也高
- 缺點：維護成本高，索引建立後要修改，必須先删除，前期需要很好地規劃
官網itzixi.com
微信公衆号：BeJavaGod
新浪微網誌
知乎
簡書
cnblogs
今日頭條
豆瓣
--> 同步更新
