1. 程式人生 > >讓我們ElasticSearch作伴,一起瀟灑複習~

讓我們ElasticSearch作伴,一起瀟灑複習~

微信圖片_20181219135426.png


12月15日

即便天氣寒冷,飄著雨

跨星空間座無虛席

由袋鼠雲、阿里雲、elastic中文社群主辦

袋鼠雲、阿里雲、有贊、滴滴的

技術大牛傾囊相授

ElasticSearch運維技術實踐”精彩上演

Now,

溫故而知新,一起來回顧吧

微信圖片_201812191354261.png


乾貨來啦,別帶著它入睡,

趕緊拿小本本記下來吧!


解 惑 篇

在此本萌特別精編了一輯本場沙龍現場講師和學員的A&Q,分享給大家~

阿里雲Elasticsearch實時計算平臺實踐


Q:使用時一邊構建索引一邊查詢,效能會下降,如何處理?

A:

架構

1)增加clientnode,降低DataNode的CPU開銷

2)換更好的硬體,多盤組成RAID或SSD

配置

1)增大translog flush時間間隔

2)增加索引refresh時間

3)調整merge速度,調小index.merge.scheduler.max_thread_count和merge.policy.max_merged_segment,增大merge.policy.segments_per_tier

4)調整mapping,不需要分詞的欄位不用text改用keyword

具體的還是要根據業務場景去測試和做取捨

Q:ES取消translog還有副本嗎?效能提升4倍是指在哪些方面?

A:

elasticbuild是用於離線build,所以不需要副本,依賴的HDFS自身有副本機制;去掉tranlog和記憶體merge減少IO開銷以及網路開銷。

Q:寫入HDFS的資料,如何恢復到ES?增量如何處理?

A:

在全量結束後會做一個snapshot到OSS上,然後再restore到線上叢集。bahamut在拉起全量build任務的時候會記住全量啟動的資料時間戳,然後增量任務從記錄的時間戳開始補資料。


袋鼠雲百億日誌資料下ES效能優化實踐


Q:5臺節點,master節點經常負載較高,兩臺MI,三臺DI,合理嗎?

A:

master建議3臺以上類似於zk三節點的原理防止腦裂。

Q:索引規劃,分片不超過40G,每個node不要超過3個分片,32G的記憶體配置下,每個分片1Gbuffer,有測試過嗎?

A:

分片設定後不可修配置後不要修改?三臺伺服器最多分片數?

A:改,除非做reindex的操作,建議最多不要超過12個(包括副本分片)


Q:冷熱資料處理,怎麼做?如何區分冷資料?查詢冷資料體驗如何提高?

A:

在我們使用日誌的場景中,超過3天或7天的資料定義為冷資料,冷資料遷移到大儲存的節點(OSS);查詢時需要恢復到熱節點,恢復有一定的時間。對使用者來說有冷熱資料儲存的概念。

Elasticsearch的索引和叢集隔離實踐


Q:索引是每30S重新整理一次,重新整理的那一刻rp比較高,如何降低影響?

A:

1)建議把資料做拆分,熱資料重新整理頻率高一點,冷資料重新整理頻率低一點

2)可以適當看下縮短重新整理時間能否平滑毛刺

3)資料變更太頻繁的內容考慮做下采樣,減少更新次數

Q:多索引查詢時怎麼提高效能?不同索引mapping不一致,解析response耗時長

A:

1)從查詢本身上做優化

2)response在業務層做多執行緒處理;

3)加快取,經常查詢的資料結果記錄在快取中;

4)執行中斷,查詢一部分結果就返回,查詢高併發效能不行的。

滴滴Elasticsearch Query DSL分析系統


Q:mapping優化中對使用者使用習慣未知,優化的意義在哪?

A:

ES預設對所有欄位建立索引,通過mapping優化,可以自動化的把索引中使用者查詢不使用的欄位不建索引來節省成本。自動化體現在使用者新增或者減少欄位能被系統自動感知到,從而減少和使用者溝通成本。

Q:有哪些使用者?查詢的索引中不同欄位的資料量是不同,此時進行聚合查詢怎麼辦?

A:

滴滴內部使用ES的同學,例如客服,運維和RD。我們會得到查詢語句中根據哪個欄位進行聚合,另外每個欄位基數會由其他服務進行統計,例如根據IP欄位進行聚合,由於IP基數過大(count distinct IP)。如果是針對大基數字段進行聚合查詢預估消耗記憶體較大時,就會把這種查詢熔斷。

Q:還沒有資料進來時沒有建索引時,是自動生成索引還是動態對映?

A:

每一類資料寫入索引前會根據這個索引中索引模板資訊進行對映,在索引模板中會定義一些欄位對應的型別,例如字串內容符合date format的欄位就會對映成date型別。沒有在索引模板中找到的欄位其型別由es根據第一次出現這個欄位的內容推導,例如字串自動對映成keyword型別。

Q:複雜的聚合查詢如何處理?

A:

聚合查詢巢狀不能太深(一般不要超過3層),當然這個跟聚合查詢的索引中聚合欄位的基數有關,如果欄位基數大聚合產生的桶就會有很多,消耗的記憶體也會很大,需要對消耗記憶體大的聚合查詢語句進行熔斷。至於複雜的聚合語句優化,

可以從減少聚合返回的size,合理調整聚合欄位順序,使用date_histogram來代替histogram等。

Q:gateway是自研的嗎,是否會考慮開源?

A:

gateway是自研的,後期會開源。