ElasticSearch 索引 VS MySQL 索引

前言

這段時間在維護產品的搜索功能，每次在管理臺看到 elasticsearch 這麼高效的查詢效率我都很好奇他是如何作到的。

這甚至比在我本地使用 MySQL 經過主鍵的查詢速度還快。

爲此我搜索了相關資料：

這類問題網上不少答案，大概意思呢以下：

• ES 是基於 Lucene 的全文檢索引擎，它會對數據進行分詞後保存索引，擅長管理大量的索引數據，相對於 MySQL 來講不擅長常常更新數據及關聯查詢。

說的不是很透徹，沒有解析相關的原理；不過既然反覆提到了索引，那咱們就從索引的角度來對比下二者的差別。

MySQL 索引

先從 MySQL 提及，索引這個詞想必你們也是爛熟於心，一般存在於一些查詢的場景，是典型的空間換時間的案例。

如下內容以 Innodb 引擎爲例。

常見的數據結構

假設由咱們本身來設計 MySQL 的索引，大概會有哪些選擇呢？

散列表

首先咱們應當想到的是散列表，這是一個很是常見且高效的查詢、寫入的數據結構，對應到 Java 中就是 HashMap

這個數據結構應該不須要過多介紹了，它的寫入效率很高O(1),好比咱們要查詢 id=3 的數據時，須要將 3 進行哈希運算，而後再這個數組中找到對應的位置便可。

但若是咱們想查詢 1≤id≤6 這樣的區間數據時，散列表就不能很好的知足了，因爲它是無序的，因此得將全部數據遍歷一遍才能知道哪些數據屬於這個區間。

有序數組

有序數組的查詢效率也很高，當咱們要查詢 id=4 的數據時，只須要經過二分查找也能高效定位到數據O(logn)。

同時因爲數據也是有序的，因此天然也能支持區間查詢；這麼看來有序數組適合用作索引咯?

天然是不行，它有另外一個重大問題；假設咱們插入了 id=2.5 的數據，就得同時將後續的全部數據都移動一位，這個寫入效率就會變得很是低。

平衡二叉樹

既然有序數組的寫入效率不高，那咱們就來看看寫入效率高的，很容易就能想到二叉樹；這裏咱們以平衡二叉樹爲例：

因爲平衡二叉樹的特性：

左節點小於父節點、右節點大於父節點。

因此假設咱們要查詢 id=11 的數據，只須要查詢 10—>12—>11 便能最終找到數據，時間複雜度爲O(logn)，同理寫入數據時也爲O(logn)。

但依然不能很好的支持區間範圍查找，假設咱們要查詢5≤id≤20 的數據時，須要先查詢10節點的左子樹再查詢10節點的右子樹最終才能查詢到全部數據。

致使這樣的查詢效率並不高。

跳錶

跳錶可能不像上邊提到的散列表、有序數組、二叉樹那樣平常見的比較多，但其實 Redis 中的 sort set 就採用了跳錶實現。

這裏咱們簡單介紹下跳錶實現的數據結構有何優點。

咱們都知道即使是對一個有序鏈表進行查詢效率也不高，因爲它不能使用數組下標進行二分查找，因此時間複雜度是o(n)

但咱們也能夠巧妙的優化鏈表來變相的實現二分查找，以下圖：

咱們能夠爲最底層的數據提取出一級索引、二級索引，根據數據量的不一樣，咱們能夠提取出 N 級索引。

當咱們查詢時即可以利用這裏的索引變相的實現了二分查找。

假設如今要查詢 id=13 的數據，只須要遍歷 1—>7—>10—>13 四個節點即可以查詢到數據，當數越多時，效率提高會更明顯。

同時區間查詢也是支持，和剛纔的查詢單個節點相似，只須要查詢到起始節點，而後依次日後遍歷（鏈表有序）到目標節點便能將整個範圍的數據查詢出來。

同時因爲咱們在索引上不會存儲真正的數據，只是存放一個指針，相對於最底層存放數據的鏈表來講佔用的空間即可以忽略不計了。

平衡二叉樹的優化

但其實 MySQL 中的 Innodb 並無採用跳錶，而是使用的一個叫作 B+ 樹的數據結構。

這個數據結構不像是二叉樹那樣大學老師當作基礎數據結構常常講到，因爲這類數據結構都是在實際工程中根據需求場景在基礎數據結構中演化而來。

好比這裏的 B+ 樹就能夠認爲是由平衡二叉樹演化而來。

剛纔咱們提到二叉樹的區間查詢效率不高，針對這一點即可進行優化：

在原有二叉樹的基礎上優化後：全部的非葉子都不存放數據，只是做爲葉子節點的索引，數據所有都存放在葉子節點。

這樣全部葉子節點的數據都是有序存放的，便能很好的支持區間查詢。

只須要先經過查詢到起始節點的位置，而後在葉子節點中依次日後遍歷便可。

當數據量巨大時，很明顯索引文件是不能存放於內存中，雖然速度很快但消耗的資源也不小；因此 MySQL 會將索引文件直接存放於磁盤中。

這點和後文提到 elasticsearch 的索引略有不一樣。

因爲索引存放於磁盤中，因此咱們要儘量的減小與磁盤的 IO（磁盤 IO 的效率與內存不在一個數量級）

經過上圖能夠看出，咱們要查詢一條數據至少得進行 4 次IO，很明顯這個 IO 次數是與樹的高度密切相關的，樹的高度越低 IO 次數就會越少，同時性能也會越好。

那怎樣才能下降樹的高度呢？

咱們能夠嘗試把二叉樹變爲三叉樹，這樣樹的高度就會降低不少，這樣查詢數據時的 IO 次數天然也會下降，同時查詢效率也會提升許多。

這其實就是 B+ 樹的由來。

使用索引的一些建議

其實經過上圖對 B+樹的理解，也能優化平常工做的一些小細節；好比爲何須要最好是有序遞增的？

假設咱們寫入的主鍵數據是無序的，那麼有可能後寫入數據的 id 小於以前寫入的，這樣在維護 B+樹 索引時便有可能須要移動已經寫好數據。

若是是按照遞增寫入數據時則不會有這個考慮，每次只須要依次寫入便可。

因此咱們纔會要求數據庫主鍵儘可能是趨勢遞增的，不考慮分表的狀況時最合理的就是自增主鍵。

總體來看思路和跳錶相似，只是針對使用場景作了相關的調整（好比數據所有存儲於葉子節點）。

ES 索引

MySQL 聊完了，如今來看看 Elasticsearch 是如何來使用索引的。

正排索引

在 ES 中採用的是一種名叫倒排索引的數據結構；在正式講倒排索引以前先來聊聊和他相反的正排索引。

以上圖爲例，咱們能夠經過 doc_id 查詢到具體對象的方式稱爲使用正排索引，其實也能理解爲一種散列表。

本質是經過 key 來查找 value。

好比經過 doc_id=4 便能很快查詢到 name=jetty wang,age=20 這條數據。

倒排索引

那若是反過來我想查詢 name 中包含了 li 的數據有哪些？這樣如何高效查詢呢？

僅僅經過上文提到的正排索引顯然起不到什麼做用，只能依次將全部數據遍歷後判斷名稱中是否包含 li ；這樣效率十分低下。

但若是咱們從新構建一個索引結構：

當要查詢 name 中包含 li 的數據時，只須要經過這個索引結構查詢到 Posting List 中所包含的數據，再經過映射的方式查詢到最終的數據。

這個索引結構其實就是倒排索引。

Term Dictionary

但如何高效的在這個索引結構中查詢到 li 呢，結合咱們以前的經驗，只要咱們將 Term 有序排列，即可以使用二叉樹搜索樹的數據結構在o(logn) 下查詢到數據。

將一個文本拆分紅一個一個獨立Term 的過程其實就是咱們常說的分詞。

而將全部 Term 合併在一塊兒就是一個 Term Dictionary，也能夠叫作單詞詞典。

• 英文的分詞相對簡單，只須要經過空格、標點符號將文本分隔便能拆詞，中文則相對複雜，但也有許多開源工具作支持（因爲不是本文重點，對分詞感興趣的能夠自行搜索）。

當咱們的文本量巨大時，分詞後的 Term 也會不少，這樣一個倒排索引的數據結構若是存放於內存那確定是不夠存的，但若是像 MySQL 那樣存放於磁盤，效率也沒那麼高。

Term Index

因此咱們能夠選擇一個折中的方法，既然沒法將整個 Term Dictionary 放入內存中，那咱們能夠爲Term Dictionary 建立一個索引而後放入內存中。

這樣即可以高效的查詢Term Dictionary ，最後再經過Term Dictionary 查詢到 Posting List。

相對於 MySQL 中的 B+樹來講也會減小了幾回磁盤IO。

這個 Term Index 咱們可使用這樣的 Trie樹 也就是咱們常說的字典樹 來存放。

更多關於字典樹的內容請查看這裏。

若是咱們是以 j 開頭的 Term 進行搜索，首先第一步就是經過在內存中的 Term Index 查詢出以 j 打頭的 Term 在 Term Dictionary 字典文件中的哪一個位置（這個位置能夠是一個文件指針，多是一個區間範圍）。

緊接着在將這個位置區間中的全部 Term 取出，因爲已經排好序，即可經過二分查找快速定位到具體位置；這樣即可查詢出 Posting List。

最終經過 Posting List 中的位置信息即可在原始文件中將目標數據檢索出來。

更多優化

固然 ElasticSearch 還作了許多針對性的優化，當咱們對兩個字段進行檢索時，就能夠利用 bitmap 進行優化。

好比如今須要查詢 name=li and age=18 的數據，這時咱們須要經過這兩個字段將各自的結果 Posting List 取出。

最簡單的方法是分別遍歷兩個集合，取出重複的數據，但這個明顯效率低下。

這時咱們即可使用 bitmap 的方式進行存儲（還節省存儲空間），同時利用先天的位與 ****計算即可得出結果。

[1, 3, 5] ⇒ 10101

[1, 2, 4, 5] ⇒ 11011

這樣兩個二進制數組求與即可得出結果：

10001 ⇒ [1, 5]

最終反解出 Posting List 爲[1, 5],這樣的效率天然是要高上許多。

一樣的查詢需求在 MySQL 中並無特殊優化，只是先將數據量小的數據篩選出來以後再篩選第二個字段，效率天然也就沒有 ES 高。

固然在最新版的 ES 中也會對 Posting List 進行壓縮，具體壓縮規則能夠查看官方文檔，這裏就不具體介紹了。

總結

最後咱們來總結一下：

經過以上內容能夠看出再複雜的產品最終都是基礎數據結構組成，只是會對不一樣應用場景針對性的優化，因此打好數據結構與算法的基礎後再看某個新的技術或中間件時才能快速上手，甚至本身就能知道優化方向。

最後畫個餅，後續我會嘗試按照 ES 倒排索引的思路作一個單機版的搜索引擎，只有本身寫一遍才能加深理解。

更好的閱讀體驗請訪問此處：https://www.notion.so/ElasticSearch-VS-MySQL-54bddcc092c64c26b2127f1fb9772a23

你的點贊與分享是對我最大的支持