163study

讓 Elasticsearch 飛起來!——性能優化實踐干貨

0、題記

Elasticsearch性能優化的最終目的:用戶體驗

關于爽的定義——著名產品人梁寧曾經說過“人在滿足時候的狀態叫做愉悅,人不被滿足就會難受,就會開始尋求。如果這個人在尋求中,能立刻得到即時滿足,這種感覺就是爽!”。

Elasticsearch的爽點就是:快、準、全!

關于Elasticsearch性能優化,阿里、騰訊、京東、攜程、滴滴、58等都有過很多深入的實踐總結,都是非常好的參考。本文換一個思路,基于Elasticsearch的爽點,進行性能優化相關探討。

1、集群規劃優化實踐

1.1 基于目標數據量規劃集群

在業務初期,經常被問到的問題,要幾個節點的集群,內存、CPU要多大,要不要SSD?

最主要的考慮點是:你的目標存儲數據量是多大?可以針對目標數據量反推節點多少。

1.2 要留出容量Buffer

注意:Elasticsearch有三個警戒水位線,磁盤使用率達到85%、90%、95%。

不同警戒水位線會有不同的應急處理策略。

這點,磁盤容量選型中要規劃在內。控制在85%之下是合理的。

當然,也可以通過配置做調整。

1.3 ES集群各節點盡量不要和其他業務功能復用一臺機器。

除非內存非常大。

舉例:普通服務器,安裝了ES+Mysql+redis,業務數據量大了之后,勢必會出現內存不足等問題。

1.4 磁盤盡量選擇SSD

Elasticsearch官方文檔肯定推薦SSD,考慮到成本的原因。需要結合業務場景,如果業務對寫入、檢索速率有較高的速率要求,建議使用SSD磁盤。

阿里的業務場景,SSD磁盤比機械硬盤的速率提升了5倍。但要因業務場景而異。

1.5 內存配置要合理

官方建議:堆內存的大小是官方建議是:Min(32GB,機器內存大小/2)。

Medcl和wood大叔都有明確說過,不必要設置32/31GB那么大,建議:熱數據設置:26GB,冷數據:31GB

總體內存大小沒有具體要求,但肯定是內容越大,檢索性能越好。

經驗值供參考:每天200GB+增量數據的業務場景,服務器至少要64GB內存。除了JVM之外的預留內存要充足,否則也會經常OOM。

1.6 CPU核數不要太小

CPU核數是和ESThread pool關聯的。和寫入、檢索性能都有關聯。

建議:16核+

1.7 超大量級的業務場景,可以考慮跨集群檢索

除非業務量級非常大,例如:滴滴、攜程的PB+的業務場景,否則基本不太需要跨集群檢索。

1.8 集群節點個數無需奇數

ES內部維護集群通信,不是基于zookeeper的分發部署機制,所以,無需奇數

但是discovery.zen.minimum_master_nodes的值要設置為:候選主節點的個數/2+1,才能有效避免腦裂。

1.9 節點類型優化分配

集群節點數:<=3,建議:所有節點的master:true, data:true。既是主節點也是路由節點。 集群節點數:>3, 根據業務場景需要,建議:逐步獨立出Master節點和協調/路由節點。

1.10 建議冷熱數據分離

熱數據存儲SSD和普通歷史數據存儲機械磁盤,物理上提高檢索效率。

2、索引優化實踐

Mysql等關系型數據庫要分庫、分表。Elasticserach的話也要做好充分的考慮。

2.1 設置多少個索引?

建議根據業務場景進行存儲。

不同通道類型的數據要分索引存儲。舉例:知乎采集信息存儲到知乎索引;APP采集信息存儲到APP索引。

2.2 設置多少分片?

建議根據數據量衡量。

經驗值:建議每個分片大小不要超過30GB

2.3 分片數設置?

建議根據集群節點的個數規模,分片個數建議>=集群節點的個數。

5節點的集群,5個分片就比較合理。

注意:除非reindex操作,分片數是不可以修改的。

2.4副本數設置?

除非你對系統的健壯性有異常高的要求,比如:銀行系統。可以考慮2個副本以上。否則,1個副本足夠。

注意:副本數是可以通過配置隨時修改的。

2.5不要再在一個索引下創建多個type

即便你是5.X版本,考慮到未來版本升級等后續的可擴展性。

建議:一個索引對應一個type。6.x默認對應_doc,5.x你就直接對應type統一為doc。

2.6 按照日期規劃索引

隨著業務量的增加,單一索引和數據量激增給的矛盾凸顯。按照日期規劃索引是必然選擇。

好處1:可以實現歷史數據秒刪。很對歷史索引delete即可。注意:一個索引的話需要借助delete_by_query+force_merge操作,慢且刪除不徹底。

好處2:便于冷熱數據分開管理,檢索最近幾天的數據,直接物理上指定對應日期的索引,速度快的一逼!

操作參考:模板使用+rollover API使用

2.7 務必使用別名

ES不像mysql方面的更改索引名稱。使用別名就是一個相對靈活的選擇。

3、數據模型優化實踐

3.1 不要使用默認的Mapping

默認Mapping的字段類型是系統自動識別的。其中:string類型默認分成:text和keyword兩種類型。如果你的業務中不需要分詞、檢索,僅需要精確匹配,僅設置為keyword即可。

根據業務需要選擇合適的類型,有利于節省空間和提升精度,如:浮點型的選擇。

3.2 Mapping各字段的選型流程

3.3 選擇合理的分詞器

常見的開源中文分詞器包括:ik分詞器、ansj分詞器、hanlp分詞器、結巴分詞器、海量分詞器、“ElasticSearch最全分詞器比較及使用方法” 搜索可查看對比效果。

如果選擇ik,建議使用ik_max_word。因為:粗粒度的分詞結果基本包含細粒度ik_smart的結果。

3.4 date、long、還是keyword

根據業務需要,如果需要基于時間軸做分析,必須date類型;如果僅需要秒級返回,建議使用keyword

4、數據寫入優化實踐

4.1 要不要秒級響應?

Elasticsearch近實時的本質是:最快1s寫入的數據可以被查詢到。

如果refresh_interval設置為1s,勢必會產生大量的segment,檢索性能會受到影響。

所以,非實時的場景可以調大,設置為30s,甚至-1。

4.2 減少副本,提升寫入性能。

寫入前,副本數設置為0,寫入后,副本數設置為原來值。

4.3 能批量就不單條寫入

批量接口為bulk,批量的大小要結合隊列的大小,而隊列大小和線程池大小、機器的cpu核數。

4.4 禁用swap

在Linux系統上,通過運行以下命令臨時禁用交換:

1sudo?swapoff?-a

5、檢索聚合優化實戰

5.1 禁用 wildcard模糊匹配

數據量級達到TB+甚至更高之后,wildcard在多字段組合的情況下很容易出現卡死,甚至導致集群節點崩潰宕機的情況。

后果不堪設想。

替代方案:

方案一:針對精確度要求高的方案:兩套分詞器結合,standard和ik結合,使用match_phrase檢索。

方案二:針對精確度要求不高的替代方案:建議ik分詞,通過match_phrase和slop結合查詢。

5.2極小的概率使用match匹配

中文match匹配顯然結果是不準確的。很大的業務場景會使用短語匹配“match_phrase”。

match_phrase結合合理的分詞詞典、詞庫,會使得搜索結果精確度更高,避免噪音數據。

5.3 結合業務場景,大量使用filter過濾器

對于不需要使用計算相關度評分的場景,無疑filter緩存機制會使得檢索更快。

舉例:過濾某郵編號碼。

5.4控制返回字段和結果

和mysql查詢一樣,業務開發中,select * 操作幾乎是不必須的。

同理,ES中,_source 返回全部字段也是非必須的。

要通過_source 控制字段的返回,只返回業務相關的字段。

網頁正文content,網頁快照html_content類似字段的批量返回,可能就是業務上的設計缺陷。

顯然,摘要字段應該提前寫入,而不是查詢content后再截取處理。

5.5 分頁深度查詢和遍歷

分頁查詢使用:from+size;
遍歷使用:scroll;
并行遍歷使用:scroll+slice

斟酌集合業務選型使用。

5.6 聚合Size的合理設置

聚合結果是不精確的。除非你設置size為2的32次冪-1,否則聚合的結果是取每個分片的Top size元素后綜合排序后的值。

實際業務場景要求精確反饋結果的要注意。
盡量不要獲取全量聚合結果——從業務層面取TopN聚合結果值是非常合理的。因為的確排序靠后的結果值意義不大。

5.7 聚合分頁合理實現

聚合結果展示的時,勢必面臨聚合后分頁的問題,而ES官方基于性能原因不支持聚合后分頁。

如果需要聚合后分頁,需要自開發實現。包含但不限于:

方案一:每次取聚合結果,拿到內存中分頁返回。

方案二:scroll結合scroll after集合redis實現。

6、業務優化

讓Elasticsearch做它擅長的事情,很顯然,它更擅長基于倒排索引進行搜索。

業務層面,用戶想最快速度看到自己想要的結果,中間的“字段處理、格式化、標準化”等一堆操作,用戶是不關注的。

為了讓Elasticsearch更高效的檢索,建議:

1)要做足“前戲”
字段抽取、傾向性分析、分類/聚類、相關性判定放在寫入ES之前的ETL階段;

2)“睡服”產品經理
產品經理基于各種奇葩業務場景可能會提各種無理需求。

作為技術人員,要“通知以情曉之以理”,給產品經理講解明白搜索引擎的原理、Elasticsearch的原理,哪些能做,哪些真的“臣妾做不到”。

7、小結

實際業務開發中,公司一般要求又想馬兒不吃草,又想馬兒飛快跑

對于Elasticsearch開發也是,硬件資源不足(cpu、內存、磁盤都爆滿)幾乎沒有辦法提升性能的。

除了檢索聚合,讓Elasticsearch做N多相關、不相干的工作,然后得出結論“Elastic也就那樣慢,沒有想像的快”。

你腦海中是否也有類似的場景浮現呢?

提供相對NB的硬件資源、做好前期的各種準備工作、讓Elasticsearch輕裝上陣,相信你的Elasticsearch也會飛起來!

推薦閱讀:

  • 1、阿里:https://elasticsearch.cn/article/6171
  • 2、滴滴:http://t.cn/EUNLkNU
  • 3、騰訊:http://t.cn/E4y9ylL
  • 4、攜程:https://elasticsearch.cn/article/6205
  • 5、社區:https://elasticsearch.cn/article/6202
  • 6、社區:https://elasticsearch.cn/article/708
  • 7、社區:https://elasticsearch.cn/article/6202

發表我的評論

取消評論
表情 插代碼

Hi,您需要填寫昵稱和郵箱!

  • 必填項
  • 必填項
22选5今晚开奖公告