提到Elasticsearch，做業務開發的同學是不是既陌生又熟悉呢？

說陌生，是因為它并不跟MySQL一樣，天天拿來做存儲查詢數據用；

說熟悉，我們排查問題查詢的ELK日志，文本分詞檢索等場景，好像又離不開它....

Elasticsearch 特別擅長處理各種各樣的數據類型，不管是文本、數字，還是其他稀奇古怪的玩意兒，它就像一個超級收納大師，把所有的數據都放在合適的位置，還能讓你輕松地找到它們。

今天，我們就來一起揭開它搜索原理的神秘面紗吧~

圖片

摘要

先自上而下，后自底向上的介紹ElasticSearch的底層工作原理，試圖回答以下問題：

• 為什么我的搜索 **foo-bar** 無法匹配foo-bar？
• 為什么增加更多的文件會壓縮索引（Index）？
• 為什么ElasticSearch占用很多內存？

圖解ElasticSearch

云上的集群

圖片

集群里的盒子

云里面的每個白色正方形的盒子代表一個節點——Node。

圖片

節點之間

在一個或者多個節點之間，多個綠色小方塊組合在一起形成一個ElasticSearch的索引。

圖片

索引里的小方塊

在一個索引下，分布在多個節點里的綠色小方塊稱為分片——Shard。

圖片

Shard＝Lucene Index

一個ElasticSearch的Shard本質上是一個Lucene Index。

圖片

Lucene是一個Full Text 搜索庫（也有很多其他形式的搜索庫），ElasticSearch是建立在Lucene之上的。接下來的故事要說的大部分內容實際上是ElasticSearch如何基于Lucene工作的。

圖解Lucene

Mini索引——segment

在Lucene里面有很多小的segment，我們可以把它們看成Lucene內部的mini-index。

圖片

Segment內部

有著許多數據結構：

• Inverted Index
• Stored Fields
• Document Values
• Cache

圖片

最最重要的Inverted Index

圖片

Inverted Index主要包括兩部分：

1. 一個有序的數據字典Dictionary（包括單詞Term和它出現的頻率）。
2. 與單詞Term對應的Postings（即存在這個單詞的文件）。

當我們搜索的時候，首先將搜索的內容分解，然后在字典里找到對應Term，從而查找到與搜索相關的文件內容。

圖片

查詢“the fury”

圖片

自動補全（AutoCompletion-Prefix）

如果想要查找以字母“c”開頭的字母，可以簡單的通過二分查找（Binary Search）在Inverted Index表中找到例如“choice”、“coming”這樣的詞（Term）。

圖片

昂貴的查找

如果想要查找所有包含“our”字母的單詞，那么系統會掃描整個Inverted Index，這是非常昂貴的。

圖片

在此種情況下，如果想要做優化，那么我們面對的問題是如何生成合適的Term。

問題的轉化

圖片

對于以上諸如此類的問題，我們可能會有幾種可行的解決方案：

• * suffix -> xiffus *如果我們想以后綴作為搜索條件，可以為Term做反向處理。
• (60.6384, 6.5017) -> u4u8gyykk對于GEO位置信息，可以將它轉換為GEO Hash。
• 123 -> {1-hundreds, 12-tens, 123}對于簡單的數字，可以為它生成多重形式的Term。

解決拼寫錯誤

一個Python庫為單詞生成了一個包含錯誤拼寫信息的樹形狀態機，解決拼寫錯誤的問題。

Stored Field字段查找

當我們想要查找包含某個特定標題內容的文件時，Inverted Index就不能很好的解決這個問題，所以Lucene提供了另外一種數據結構Stored Fields來解決這個問題。本質上，Stored Fields是一個簡單的鍵值對key-value。默認情況下，ElasticSearch會存儲整個文件的JSON source。

圖片

Document Values為了排序，聚合

即使這樣，我們發現以上結構仍然無法解決諸如：排序、聚合、facet，因為我們可能會要讀取大量不需要的信息。

所以，另一種數據結構解決了此種問題：Document Values。這種結構本質上就是一個列式的存儲，它高度優化了具有相同類型的數據的存儲結構。

圖片

為了提高效率，ElasticSearch可以將索引下某一個Document Value全部讀取到內存中進行操作，這大大提升訪問速度，但是也同時會消耗掉大量的內存空間。

總之，這些數據結構Inverted Index、Stored Fields、Document Values及其緩存，都在segment內部。

搜索發生時

搜索時，Lucene會搜索所有的segment，然后將每個segment的搜索結果返回，最后合并呈現給客戶。

Lucene的一些特性使得這個過程非常重要：

• Segments是不可變的（immutable）

         Delete?當刪除發生時，Lucene做的只是將其標志位置為刪除，但是文件還是會在它原來的地方，不會發生改變。

         Update?所以對于更新來說，本質上它做的工作是：先刪除，然后重新索引（Re-index）。

• 隨處可見的壓縮Lucene非常擅長壓縮數據，基本上所有教科書上的壓縮方式，都能在Lucene中找到。
• 緩存所有的所有Lucene也會將所有的信息做緩存，這大大提高了它的查詢效率。

緩存的故事

當ElasticSearch索引一個文件的時候，會為文件建立相應的緩存，并且會定期（每秒）刷新這些數據，然后這些文件就可以被搜索到。

圖片

隨著時間的增加，我們會有很多segments。

圖片

所以ElasticSearch會將這些segment合并，在這個過程中，segment會最終被刪除掉。

圖片

這就是為什么增加文件可能會使索引所占空間變小，它會引起merge，從而可能會有更多的壓縮。

舉個栗子

有兩個segment將會merge。

這兩個segment最終會被刪除，然后合并成一個新的segment。

圖片

這時，這個新的segment在緩存中處于cold狀態，但是大多數segment仍然保持不變，處于warm狀態。

以上場景經常在Lucene Index內部發生的。

圖片

在Shard中搜索

ElasticSearch從Shard中搜索的過程與Lucene Segment中搜索的過程類似。

圖片

與在Lucene Segment中搜索不同的是，Shard可能是分布在不同Node上的，所以在搜索與返回結果時，所有的信息都會通過網絡傳輸。

需要注意的是：

1次搜索查找2個shard ＝ 2次分別搜索shard

圖片

對于日志文件的處理

當我們想搜索特定日期產生的日志時，通過根據時間戳對日志文件進行分塊與索引，會極大提高搜索效率。

當我們想要刪除舊的數據時也非常方便，只需刪除老的索引即可。

在上種情況下，每個index有兩個shards。

如何Scale

圖片

shard不會進行更進一步的拆分，但是shard可能會被轉移到不同節點上。

圖片

所以，如果當集群節點壓力增長到一定的程度，我們可能會考慮增加新的節點，這就會要求我們對所有數據進行重新索引，這是我們不太希望看到的，所以我們需要在規劃的時候就考慮清楚，如何去平衡足夠多的節點與不足節點之間的關系。

節點分配與Shard優化

• 為更重要的數據索引節點，分配性能更好的機器
• 確保每個shard都有副本信息replica

圖片

路由Routing

每個節點，每個都存留一份路由表，所以當請求到任何一個節點時，ElasticSearch都有能力將請求轉發到期望節點的shard進一步處理。

圖片

一個真實的請求

圖片

Query

圖片

Query有一個類型filtered，以及一個multi_match的查詢。

Aggregation

圖片

根據作者進行聚合，得到top10的hits的top10作者的信息。

請求分發

這個請求可能被分發到集群里的任意一個節點。

圖片

上帝節點

圖片

這時這個節點就成為當前請求的協調者（Coordinator），它決定：

• 根據索引信息，判斷請求會被路由到哪個核心節點
• 以及哪個副本是可用的
• 等等

路由

圖片

在真實搜索之前

ElasticSearch 會將Query轉換成Lucene Query。

圖片

然后在所有的segment中執行計算。

圖片

對于Filter條件本身也會有緩存。

圖片

但queries不會被緩存，所以如果相同的Query重復執行，應用程序自己需要做緩存。

圖片

所以，

• filters可以在任何時候使用
• query只有在需要score的時候才使用

返回

搜索結束之后，結果會沿著下行的路徑向上逐層返回。

圖片

圖片

圖片

圖片

圖片