大白話告訴你倒排索引是個啥
- 2020 年 3 月 18 日
- 筆記
引子
很多搜索引擎都是基於倒排索引,比如luncene,solr以及elasticsearch

正排索引
聊倒排搜索之前先來看看正排索引,正排其實就是數據庫表,他通過id和數據進行關聯,如下:
數據id |
數據內容 |
---|---|
1001 |
蘋果公司發佈iPhone |
1002 |
地球引力起源於蘋果 |
1003 |
iPhone屏幕碎了 |
1004 |
我在蘋果商店維修屏幕 |
1005 |
我剛剛吃了蘋果 |
我們可以通過搜索id,來獲得相應的數據,也能刪除數據。你買了一本書,書的目錄其實也是正排搜索。
假設現在我要搜蘋果
倆字,那麼他會對這張表格中每一行的數據做匹配,去查找一下,是否包含蘋果
這兩個字,從第一條匹配到最後一條,如果一張表中數據量不多,幾萬,十幾萬,那麼問題不大,但是一旦數據量有上百萬,上千萬,那麼全表掃描這種的搜索性能就會有影響。
其次,這個時候我想搜索蘋果iPhone
,那麼我們無法把這詞彙拆開再到數據庫去搜索。
- 優點:使用起來方便,原理也簡單,比較入門
- 缺點:檢索效率低下,適合簡單場景使用,比如傳統項目,數據量較小的項目。不支持分詞搜索。
倒排索引
與正排是反着來的,他會把文檔內容進行分詞,比如蘋果公司發佈iPhone
是一個文檔數據,當我們把他存入到搜索引擎中去的時候,會有一個文檔id,這個文檔id就類似於數據庫主鍵。但是這文檔存儲的時候和數據庫不一樣,他會進行一個分詞,參照上面的表格,分詞後的結果如下:
文檔數據 |
分詞結果 |
---|---|
蘋果公司發佈iPhone |
蘋果,公司,發佈,iPhone |
地球引力起源於蘋果 |
地球,引力,起源,於,蘋果 |
iPhone屏幕碎了 |
iPhone,屏幕,碎了 |
我在蘋果商店維修屏幕 |
我,在,蘋果,商店,維修,屏幕 |
我剛剛吃了蘋果 |
我,剛剛,吃了,蘋果 |
每一個詞彙都會和文檔id關聯起來,可以根據詞彙來找到所有出現的id列表,如下:
詞彙 |
文檔ids |
---|---|
蘋果 |
1001,1002,1004,1005 |
iPhone |
1001,1003 |
公司 |
1001 |
發佈 |
1001 |
地球 |
1001 |
引力 |
1001 |
起源 |
1001 |
於 |
1001 |
屏幕 |
1003,1004 |
碎了 |
1003 |
我 |
1004,1005 |
在 |
1004 |
商店 |
1004 |
維修 |
1004 |
剛剛 |
1005 |
吃了 |
1005 |
假設現在我要搜索iPhone
,如果是數據庫搜索,假設有1億條數據,那麼會匹配1億次,全表掃描。最後再把數據返回出來。 如果是搜索引擎,那麼有可能第一次就把所有文檔數據給查出來,當然也有可能是第N次,當然他肯定要比數據庫的搜索效率更高。如圖中位置,他會直接把1001,1003
兩個文檔返回。
可能會有同學會問,數據庫和搜索引擎都是1000萬數據,搜索的詞彙在搜索引擎中正好是第1000萬條,那麼會不會慢,其實這個肯定會比數據庫更快,數據庫要匹配是一個文本中的內容和關鍵詞匹配,而搜索引擎是直接把關鍵字做匹配,效率肯定後者更快。
- 有點:搜索更快,耗時短,用戶體驗高,精裝度也高
- 缺點:維護成本高,索引新建後要修改,必須先刪除,前期需要很好地規劃