請警惕 ES 的三大坑

作者 | 悟空聊架構

來源 | 悟空聊架構(ID:PassJava666)

轉載請聯繫授權(微信 ID:PassJava)

ES 搜索引擎系列文章彙總:

一、別隻會搜日誌了,求你懂點原理吧

二、ES 終於可以搜到” 悟空哥 “了!

三、1W 字|40 圖|硬核 ES 實戰

本文主要內容如下:

搜索引擎現在是用得越來越多了,比如我們日誌系統中用到的 ELK 就用到了搜索引擎 Elasticsearch(簡稱 ES)。

那對於搜索這種技術來說,最看重的是搜索的結果的準確性和搜索的響應時間。ES 的準確性可以通過 倒排索引算法來保證,那響應時間就需要磁盤或緩存來支持了,那麼磁盤和緩存會帶來哪些坑呢?(其實不論是分佈式的,還是單機模式下的搜索引擎都會遇到這個問題。)

一、ES 慢查詢之坑

Elasticsearch 是現如今用的最廣泛的搜索引擎。它是一個分佈式的開源搜索和分析引擎,適用於所有類型的數據,包括文本、數字、地理空間、結構化和非結構化數據。

1.1 工作原理:

ES 的工作原理:往 ES 裏寫數據時,實際是寫到磁盤文件,查詢時,操作系統會將磁盤文件裏的數據自動緩存 filesystem cache 裏面。如果給 filesystem cache 更多的內存,儘量讓內存可以容納所有的 idx segment file 索引數據文件,則搜索的時候走內存,性能較好。

ES 工作原理

坑: 首先如果訪問磁盤那一定很慢,而走緩存會快很多。但如果很多沒用的字段數據都丟到緩存裏面,則會浪費緩存的空間,所以很多數據還是存在磁盤裏面的,那麼大部分查詢走的數據庫,則會帶來性能問題。

1.2 案例

ES 節點 3 臺機器,每臺機器 32 G 內存,總內存 96 G,給 ES JVM 堆內存是 16 G,那麼剩下來給 cache 的是 16 G,總共 ES 集羣的的 cache 佔用內存 48 G ,如果所有的數據佔據磁盤空間 600 G,那麼每臺機器的數據量是 200 G,而查詢時,有 150 G 左右的的數據是走磁盤查詢的,那麼走 cache 的概率是 48 G/ 600 G = 8%,也就是說大量查詢是走磁盤的。

1.3 避坑指南:

1.3.1 存儲關鍵信息

搜索引擎避坑指南

1.3.2 數據預熱

1.3.3 冷熱分離

1.3.4 避免使用關聯查詢

二、ES 架構之坑

通常情況下,我們會使用 ES 的集羣模式,在集羣規模不大的情況下,性能還算可以,但如果集羣規模變得很大,則會遇到集羣瓶頸,也就是說集羣擴大,性能提升甚微,甚至不增反降。

ES 的集羣也是採用中心化的分佈式架構,整個集羣只有一個是 Master 節點。而它的職責非常重要:負責整個集羣的元數據管理,元數據包含全局的配置信息、索引信息、節點信息,如果元數據發生改變,則需要 master 節點將變更信息發佈到集羣的其他節點。

另外因爲 master 節點的任務處理是單線程的,所以每次處理任務時,需要等待全部節點接收到變更信息,並處理完變更的任務後,纔算完成了變更任務。

那麼這樣的架構會帶來什麼問題:

解決方案:採用 ES 的 tribe node 特性實現 ES 多集羣。文中後面會介紹下 tribe node 的原理。

三、業務場景的坑

ES 的被廣泛應用到多個場景,比如查詢日誌、查詢商品資料、數據聚合等。而這些場景的需求又有非常大的差異,這也是一個坑。

Kibana 界面

解決方案:按業務場景劃分 ES 集羣,同樣採用 ES tribe node 功能。

四、ES Tribe Node 方案

ES tribe node  功能原理圖如下所示:

後續我們再來聊聊 ES Tribe Node 的底層原理和用法~

參考資料: 

https://www.infoq.cn/article/SbfS6uOcF_gW6FEpQlLK https://www.elastic.co/guide/en/elasticsearch/reference/2.0/modules-tribe.html advance-java

我是悟空,努力變強,變身超級賽亞人!

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/9KJ0jJQ1ygOTcjt4GwZBAQ