圖解 ElasticSearch 原理,你可收好了!
點(diǎn)擊上方藍(lán)色“小哈學(xué)Java”,選擇“設(shè)為星標(biāo)”
回復(fù)“資源”獲取獨(dú)家整理的學(xué)習(xí)資料!


來(lái)源:Richaaaard
Elasticsearch 是一款功能強(qiáng)大的開(kāi)源分布式搜索與數(shù)據(jù)分析引擎,目前國(guó)內(nèi)諸多互聯(lián)網(wǎng)大廠都在使用,包括攜程、滴滴、今日頭條、餓了么、360 安全、小米、vivo 等。
除了搜索之外,結(jié)合 Kibana、Logstash、Beats,Elastic Stack 還被廣泛運(yùn)用在大數(shù)據(jù)近實(shí)時(shí)分析領(lǐng)域,包括日志分析、指標(biāo)監(jiān)控、信息安全等多個(gè)領(lǐng)域。
它可以幫助你探索海量結(jié)構(gòu)化、非結(jié)構(gòu)化數(shù)據(jù),按需創(chuàng)建可視化報(bào)表,對(duì)監(jiān)控?cái)?shù)據(jù)設(shè)置報(bào)警閾值,甚至通過(guò)使用機(jī)器學(xué)習(xí)技術(shù),自動(dòng)識(shí)別異常狀況。
今天,我們先自上而下,后自底向上的介紹ElasticSearch的底層工作原理,并試圖回答以下問(wèn)題:
為什么我的搜索?*foo-bar*?無(wú)法匹配 foo-bar ?
為什么增加更多的文件會(huì)壓縮索引(Index)?
為什么 ElasticSearch 占用很多內(nèi)存?
圖解 ElasticSearch
①云上的集群

②集群里的盒子

③節(jié)點(diǎn)之間

④索引里的小方塊

⑤Shard=Lucene Index

Lucene 是一個(gè) Full Text 搜索庫(kù)(也有很多其他形式的搜索庫(kù)),ElasticSearch 是建立在 Lucene 之上的。
接下來(lái)的故事要說(shuō)的大部分內(nèi)容實(shí)際上是 ElasticSearch 如何基于 Lucene 工作的。
圖解 Lucene
Mini 索引:Segment

Segment 內(nèi)部

Segment 內(nèi)部有著許多數(shù)據(jù)結(jié)構(gòu),如上圖:
Inverted Index
Stored Fields
Document Values
Cache
最最重要的 Inverted Index

Inverted Index 主要包括兩部分:
一個(gè)有序的數(shù)據(jù)字典 Dictionary(包括單詞 Term 和它出現(xiàn)的頻率)。
與單詞 Term 對(duì)應(yīng)的 Postings(即存在這個(gè)單詞的文件)。

①查詢“the fury”

②自動(dòng)補(bǔ)全(AutoCompletion-Prefix)

③昂貴的查找

在此種情況下,如果想要做優(yōu)化,那么我們面對(duì)的問(wèn)題是如何生成合適的 Term。
④問(wèn)題的轉(zhuǎn)化

對(duì)于以上諸如此類(lèi)的問(wèn)題,我們可能會(huì)有幾種可行的解決方案:
* suffix→xiffus *,如果我們想以后綴作為搜索條件,可以為 Term 做反向處理。
(60.6384, 6.5017)→ u4u8gyykk,對(duì)于 GEO 位置信息,可以將它轉(zhuǎn)換為 GEO Hash。
123→{1-hundreds, 12-tens, 123},對(duì)于簡(jiǎn)單的數(shù)字,可以為它生成多重形式的 Term。
⑤解決拼寫(xiě)錯(cuò)誤
一個(gè) Python 庫(kù)為單詞生成了一個(gè)包含錯(cuò)誤拼寫(xiě)信息的樹(shù)形狀態(tài)機(jī),解決拼寫(xiě)錯(cuò)誤的問(wèn)題。

⑥Stored Field 字段查找
當(dāng)我們想要查找包含某個(gè)特定標(biāo)題內(nèi)容的文件時(shí),Inverted Index 就不能很好的解決這個(gè)問(wèn)題,所以 Lucene 提供了另外一種數(shù)據(jù)結(jié)構(gòu) Stored Fields 來(lái)解決這個(gè)問(wèn)題。
本質(zhì)上,Stored Fields 是一個(gè)簡(jiǎn)單的鍵值對(duì) key-value。默認(rèn)情況下,ElasticSearch 會(huì)存儲(chǔ)整個(gè)文件的 JSON source。

⑦Document Values 為了排序,聚合
即使這樣,我們發(fā)現(xiàn)以上結(jié)構(gòu)仍然無(wú)法解決諸如:排序、聚合、facet,因?yàn)槲覀兛赡軙?huì)要讀取大量不需要的信息。
所以,另一種數(shù)據(jù)結(jié)構(gòu)解決了此種問(wèn)題:Document Values。這種結(jié)構(gòu)本質(zhì)上就是一個(gè)列式的存儲(chǔ),它高度優(yōu)化了具有相同類(lèi)型的數(shù)據(jù)的存儲(chǔ)結(jié)構(gòu)。

為了提高效率,ElasticSearch 可以將索引下某一個(gè) Document Value 全部讀取到內(nèi)存中進(jìn)行操作,這大大提升訪問(wèn)速度,但是也同時(shí)會(huì)消耗掉大量的內(nèi)存空間。
總之,這些數(shù)據(jù)結(jié)構(gòu) Inverted Index、Stored Fields、Document Values 及其緩存,都在 segment 內(nèi)部。
搜索發(fā)生時(shí)
搜索時(shí),Lucene 會(huì)搜索所有的 Segment 然后將每個(gè) Segment 的搜索結(jié)果返回,最后合并呈現(xiàn)給客戶。
Lucene 的一些特性使得這個(gè)過(guò)程非常重要:
Segments 是不可變的(immutable):Delete?當(dāng)刪除發(fā)生時(shí),Lucene 做的只是將其標(biāo)志位置為刪除,但是文件還是會(huì)在它原來(lái)的地方,不會(huì)發(fā)生改變。
Update?所以對(duì)于更新來(lái)說(shuō),本質(zhì)上它做的工作是:先刪除,然后重新索引(Re-index)。
隨處可見(jiàn)的壓縮:Lucene 非常擅長(zhǎng)壓縮數(shù)據(jù),基本上所有教科書(shū)上的壓縮方式,都能在 Lucene 中找到。
緩存所有的所有:Lucene 也會(huì)將所有的信息做緩存,這大大提高了它的查詢效率。
緩存的故事
當(dāng) ElasticSearch 索引一個(gè)文件的時(shí)候,會(huì)為文件建立相應(yīng)的緩存,并且會(huì)定期(每秒)刷新這些數(shù)據(jù),然后這些文件就可以被搜索到。

隨著時(shí)間的增加,我們會(huì)有很多 Segments,如下圖:

所以 ElasticSearch 會(huì)將這些 Segment 合并,在這個(gè)過(guò)程中,Segment 會(huì)最終被刪除掉。

舉個(gè)栗子
有兩個(gè) Segment 將會(huì) Merge:

這兩個(gè) Segment 最終會(huì)被刪除,然后合并成一個(gè)新的 Segment,如下圖:

這時(shí)這個(gè)新的 Segment 在緩存中處于 Cold 狀態(tài),但是大多數(shù) Segment 仍然保持不變,處于 Warm 狀態(tài)。
在 Shard 中搜索
ElasticSearch 從 Shard 中搜索的過(guò)程與 Lucene Segment 中搜索的過(guò)程類(lèi)似。
與在 Lucene Segment 中搜索不同的是,Shard 可能是分布在不同 Node 上的,所以在搜索與返回結(jié)果時(shí),所有的信息都會(huì)通過(guò)網(wǎng)絡(luò)傳輸。
對(duì)于日志文件的處理:當(dāng)我們想搜索特定日期產(chǎn)生的日志時(shí),通過(guò)根據(jù)時(shí)間戳對(duì)日志文件進(jìn)行分塊與索引,會(huì)極大提高搜索效率。
當(dāng)我們想要?jiǎng)h除舊的數(shù)據(jù)時(shí)也非常方便,只需刪除老的索引即可。
如何 Scale

Shard 不會(huì)進(jìn)行更進(jìn)一步的拆分,但是 Shard 可能會(huì)被轉(zhuǎn)移到不同節(jié)點(diǎn)上。

節(jié)點(diǎn)分配與 Shard 優(yōu)化:
為更重要的數(shù)據(jù)索引節(jié)點(diǎn),分配性能更好的機(jī)器。
確保每個(gè) Shard 都有副本信息 Replica。

路由 Routing:每個(gè)節(jié)點(diǎn),每個(gè)都存留一份路由表,所以當(dāng)請(qǐng)求到任何一個(gè)節(jié)點(diǎn)時(shí),ElasticSearch 都有能力將請(qǐng)求轉(zhuǎn)發(fā)到期望節(jié)點(diǎn)的 Shard 進(jìn)一步處理。
一個(gè)真實(shí)的請(qǐng)求

①Q(mào)uery
如下圖:

②Aggregation
如下圖:

③請(qǐng)求分發(fā)
這個(gè)請(qǐng)求可能被分發(fā)到集群里的任意一個(gè)節(jié)點(diǎn),如下圖:
④上帝節(jié)點(diǎn)

根據(jù)索引信息,判斷請(qǐng)求會(huì)被路由到哪個(gè)核心節(jié)點(diǎn)。
以及哪個(gè)副本是可用的。
等等。
⑤路由

⑥在真實(shí)搜索之前
ElasticSearch 會(huì)將 Query 轉(zhuǎn)換成 Lucene Query,如下圖:
然后在所有的 Segment 中執(zhí)行計(jì)算,如下圖:

但 Queries 不會(huì)被緩存,所以如果相同的 Query 重復(fù)執(zhí)行,應(yīng)用程序自己需要做緩存。
Filters 可以在任何時(shí)候使用。
Query 只有在需要 Score 的時(shí)候才使用。
⑦返回
搜索結(jié)束之后,結(jié)果會(huì)沿著下行的路徑向上逐層返回,如下圖:
題外話: 目前小哈正在個(gè)人博客(新搭建的網(wǎng)站,域名就是犬小哈的拼音)?www.quanxiaoha.com?上更新《Go語(yǔ)言教程》、《Gin Web框架教程》,畢竟Go自帶天然的并發(fā)優(yōu)勢(shì),后端的同學(xué)還是要學(xué)一下的,這個(gè)教程系列小哈會(huì)一直更新下去,歡迎小伙伴們?cè)L問(wèn)哦~
END
有熱門(mén)推薦?
1.?萬(wàn)字長(zhǎng)文詳解Shardingsphere對(duì)XA分布式事務(wù)的支持
最近面試BAT,整理一份面試資料《Java面試BATJ通關(guān)手冊(cè)》,覆蓋了Java核心技術(shù)、JVM、Java并發(fā)、SSM、微服務(wù)、數(shù)據(jù)庫(kù)、數(shù)據(jù)結(jié)構(gòu)等等。
獲取方式:點(diǎn)“在看”,關(guān)注公眾號(hào)并回復(fù)?Java?領(lǐng)取,更多內(nèi)容陸續(xù)奉上。
文章有幫助的話,在看,轉(zhuǎn)發(fā)吧。
謝謝支持喲 (*^__^*)

