版權(quán)聲明：本文為博主原創(chuàng)文章，未經(jīng)博主允許不得轉(zhuǎn)載。轉(zhuǎn)載請務(wù)必加上原作者：銘毅天下，原文地址：blog.csdn.net/laoyang360 https://blog.csdn.net/wojiushiwo987/article/details/85109769
0、題記
Elasticsearch性能優(yōu)化的最終目的：用戶體驗爽。
關(guān)于爽的定義——著名產(chǎn)品人梁寧曾經(jīng)說過“人在滿足時候的狀態(tài)叫做愉悅，人不被滿足就會難受，就會開始尋求。如果這個人在尋求中，能立刻得到即時滿足，這種感覺就是爽！”。
Elasticsearch的爽點就是：快、準、全!
關(guān)于Elasticsearch性能優(yōu)化，阿里、騰訊、京東、攜程、滴滴、58等都有過很多深入的實踐總結(jié)，都是非常好的參考。本文換一個思路，基于Elasticsearch的爽點，進行性能優(yōu)化相關(guān)探討。

1、集群規(guī)劃優(yōu)化實踐
1.1 基于目標數(shù)據(jù)量規(guī)劃集群
在業(yè)務(wù)初期，經(jīng)常被問到的問題，要幾個節(jié)點的集群，內(nèi)存、CPU要多大，要不要SSD？
最主要的考慮點是：你的目標存儲數(shù)據(jù)量是多大？可以針對目標數(shù)據(jù)量反推節(jié)點多少。

1.2 要留出容量Buffer
注意：Elasticsearch有三個警戒水位線，磁盤使用率達到85%、90%、95%。
不同警戒水位線會有不同的應(yīng)急處理策略。
這點，磁盤容量選型中要規(guī)劃在內(nèi)。控制在85%之下是合理的。
當然，也可以通過配置做調(diào)整。

1.3 ES集群各節(jié)點盡量不要和其他業(yè)務(wù)功能復(fù)用一臺機器。
除非內(nèi)存非常大。
舉例：普通服務(wù)器，安裝了ES+Mysql+redis，業(yè)務(wù)數(shù)據(jù)量大了之后，勢必會出現(xiàn)內(nèi)存不足等問題。

1.4 磁盤盡量選擇SSD
Elasticsearch官方文檔肯定推薦SSD，考慮到成本的原因。需要結(jié)合業(yè)務(wù)場景，
如果業(yè)務(wù)對寫入、檢索速率有較高的速率要求，建議使用SSD磁盤。
阿里的業(yè)務(wù)場景，SSD磁盤比機械硬盤的速率提升了5倍。
但要因業(yè)務(wù)場景而異。

1.5 內(nèi)存配置要合理
官方建議：堆內(nèi)存的大小是官方建議是：Min（32GB，機器內(nèi)存大小/2）。
Medcl和wood大叔都有明確說過，不必要設(shè)置32/31GB那么大，建議：熱數(shù)據(jù)設(shè)置：26GB，冷數(shù)據(jù)：31GB。
總體內(nèi)存大小沒有具體要求，但肯定是內(nèi)容越大，檢索性能越好。
經(jīng)驗值供參考：每天200GB+增量數(shù)據(jù)的業(yè)務(wù)場景，服務(wù)器至少要64GB內(nèi)存。
除了JVM之外的預(yù)留內(nèi)存要充足，否則也會經(jīng)常OOM。

1.6 CPU核數(shù)不要太小
CPU核數(shù)是和ESThread pool關(guān)聯(lián)的。和寫入、檢索性能都有關(guān)聯(lián)。
建議：16核+。

1.7 超大量級的業(yè)務(wù)場景，可以考慮跨集群檢索
除非業(yè)務(wù)量級非常大，例如：滴滴、攜程的PB+的業(yè)務(wù)場景，否則基本不太需要跨集群檢索。

1.8 集群節(jié)點個數(shù)無需奇數(shù)
ES內(nèi)部維護集群通信，不是基于zookeeper的分發(fā)部署機制，所以，無需奇數(shù)。
但是discovery.zen.minimum_master_nodes的值要設(shè)置為：候選主節(jié)點的個數(shù)/2+1，才能有效避免腦裂。

1.9 節(jié)點類型優(yōu)化分配
集群節(jié)點數(shù)：<=3，建議：所有節(jié)點的master：true， data：true。既是主節(jié)點也是路由節(jié)點。
集群節(jié)點數(shù)：>3, 根據(jù)業(yè)務(wù)場景需要，建議：逐步獨立出Master節(jié)點和協(xié)調(diào)/路由節(jié)點。

1.10 建議冷熱數(shù)據(jù)分離
熱數(shù)據(jù)存儲SSD和普通歷史數(shù)據(jù)存儲機械磁盤，物理上提高檢索效率。

2、索引優(yōu)化實踐
Mysql等關(guān)系型數(shù)據(jù)庫要分庫、分表。Elasticserach的話也要做好充分的考慮。

2.1 設(shè)置多少個索引？
建議根據(jù)業(yè)務(wù)場景進行存儲。
不同通道類型的數(shù)據(jù)要分索引存儲。舉例：知乎采集信息存儲到知乎索引；APP采集信息存儲到APP索引。

2.2 設(shè)置多少分片？
建議根據(jù)數(shù)據(jù)量衡量。
經(jīng)驗值：建議每個分片大小不要超過30GB。

2.3 分片數(shù)設(shè)置？
建議根據(jù)集群節(jié)點的個數(shù)規(guī)模，分片個數(shù)建議>=集群節(jié)點的個數(shù)。
5節(jié)點的集群，5個分片就比較合理。
注意：除非reindex操作，分片數(shù)是不可以修改的。

2.4副本數(shù)設(shè)置？
除非你對系統(tǒng)的健壯性有異常高的要求，比如：銀行系統(tǒng)。可以考慮2個副本以上。
否則，1個副本足夠。
注意：副本數(shù)是可以通過配置隨時修改的。

2.5不要再在一個索引下創(chuàng)建多個type
即便你是5.X版本，考慮到未來版本升級等后續(xù)的可擴展性。
建議：一個索引對應(yīng)一個type。6.x默認對應(yīng)_doc，5.x你就直接對應(yīng)type統(tǒng)一為doc。

2.6 按照日期規(guī)劃索引
隨著業(yè)務(wù)量的增加，單一索引和數(shù)據(jù)量激增給的矛盾凸顯。
按照日期規(guī)劃索引是必然選擇。
好處1：可以實現(xiàn)歷史數(shù)據(jù)秒刪。很對歷史索引delete即可。注意：一個索引的話需要借助delete_by_query+force_merge操作，慢且刪除不徹底。
好處2：便于冷熱數(shù)據(jù)分開管理，檢索最近幾天的數(shù)據(jù)，直接物理上指定對應(yīng)日期的索引，速度快的一逼！
操作參考：模板使用+rollover API使用。

2.7 務(wù)必使用別名
ES不像mysql方面的更改索引名稱。使用別名就是一個相對靈活的選擇。

3、數(shù)據(jù)模型優(yōu)化實踐
3.1 不要使用默認的Mapping
默認Mapping的字段類型是系統(tǒng)自動識別的。其中：string類型默認分成：text和keyword兩種類型。如果你的業(yè)務(wù)中不需要分詞、檢索，僅需要精確匹配，僅設(shè)置為keyword即可。
根據(jù)業(yè)務(wù)需要選擇合適的類型，有利于節(jié)省空間和提升精度，如：浮點型的選擇。

3.2 Mapping各字段的選型流程

3.3 選擇合理的分詞器
常見的開源中文分詞器包括：ik分詞器、ansj分詞器、hanlp分詞器、結(jié)巴分詞器、海量分詞器、“ElasticSearch最全分詞器比較及使用方法” 搜索可查看對比效果。
如果選擇ik，建議使用ik_max_word。因為：粗粒度的分詞結(jié)果基本包含細粒度ik_smart的結(jié)果。

3.4 date、long、還是keyword
根據(jù)業(yè)務(wù)需要，如果需要基于時間軸做分析，必須date類型；
如果僅需要秒級返回，建議使用keyword。

4、數(shù)據(jù)寫入優(yōu)化實踐
4.1 要不要秒級響應(yīng)？
Elasticsearch近實時的本質(zhì)是：最快1s寫入的數(shù)據(jù)可以被查詢到。
如果refresh_interval設(shè)置為1s，勢必會產(chǎn)生大量的segment，檢索性能會受到影響。
所以，非實時的場景可以調(diào)大，設(shè)置為30s，甚至-1。

4.2 減少副本，提升寫入性能。
寫入前，副本數(shù)設(shè)置為0，
寫入后，副本數(shù)設(shè)置為原來值。

4.3 能批量就不單條寫入
批量接口為bulk，批量的大小要結(jié)合隊列的大小，而隊列大小和線程池大小、機器的cpu核數(shù)。

4.4 禁用swap
在Linux系統(tǒng)上，通過運行以下命令臨時禁用交換：

sudo swapoff -a
1
5、檢索聚合優(yōu)化實戰(zhàn)
5.1 禁用 wildcard模糊匹配
數(shù)據(jù)量級達到TB+甚至更高之后，wildcard在多字段組合的情況下很容易出現(xiàn)卡死，甚至導(dǎo)致集群節(jié)點崩潰宕機的情況。
后果不堪設(shè)想。
替代方案：
方案一：針對精確度要求高的方案:兩套分詞器結(jié)合，standard和ik結(jié)合，使用match_phrase檢索。
方案二：針對精確度要求不高的替代方案：建議ik分詞，通過match_phrase和slop結(jié)合查詢。

5.2極小的概率使用match匹配
中文match匹配顯然結(jié)果是不準確的。很大的業(yè)務(wù)場景會使用短語匹配“match_phrase"。
match_phrase結(jié)合合理的分詞詞典、詞庫，會使得搜索結(jié)果精確度更高，避免噪音數(shù)據(jù)。

5.3 結(jié)合業(yè)務(wù)場景，大量使用filter過濾器
對于不需要使用計算相關(guān)度評分的場景，無疑filter緩存機制會使得檢索更快。
舉例：過濾某郵編號碼。

5.3控制返回字段和結(jié)果
和mysql查詢一樣，業(yè)務(wù)開發(fā)中，select * 操作幾乎是不必須的。
同理，ES中，_source 返回全部字段也是非必須的。
要通過_source 控制字段的返回，只返回業(yè)務(wù)相關(guān)的字段。
網(wǎng)頁正文content，網(wǎng)頁快照html_content類似字段的批量返回，可能就是業(yè)務(wù)上的設(shè)計缺陷。
顯然，摘要字段應(yīng)該提前寫入，而不是查詢content后再截取處理。

5.4 分頁深度查詢和遍歷
分頁查詢使用：from+size;
遍歷使用：scroll；
并行遍歷使用：scroll+slice。
斟酌集合業(yè)務(wù)選型使用。

5.5 聚合Size的合理設(shè)置
聚合結(jié)果是不精確的。除非你設(shè)置size為2的32次冪-1，否則聚合的結(jié)果是取每個分片的Top size元素后綜合排序后的值。
實際業(yè)務(wù)場景要求精確反饋結(jié)果的要注意。
盡量不要獲取全量聚合結(jié)果——從業(yè)務(wù)層面取TopN聚合結(jié)果值是非常合理的。因為的確排序靠后的結(jié)果值意義不大。

5.6 聚合分頁合理實現(xiàn)
聚合結(jié)果展示的時，勢必面臨聚合后分頁的問題，而ES官方基于性能原因不支持聚合后分頁。
如果需要聚合后分頁，需要自開發(fā)實現(xiàn)。包含但不限于：
方案一：每次取聚合結(jié)果，拿到內(nèi)存中分頁返回。
方案二：scroll結(jié)合scroll after集合redis實現(xiàn)。

6、業(yè)務(wù)優(yōu)化
讓Elasticsearch做它擅長的事情，很顯然，它更擅長基于倒排索引進行搜索。
業(yè)務(wù)層面，用戶想最快速度看到自己想要的結(jié)果，中間的“字段處理、格式化、標準化”等一堆操作，用戶是不關(guān)注的。
為了讓Elasticsearch更高效的檢索，建議：
1）要做足“前戲”
字段抽取、傾向性分析、分類/聚類、相關(guān)性判定放在寫入ES之前的ETL階段進行；
2）“睡服”產(chǎn)品經(jīng)理
產(chǎn)品經(jīng)理基于各種奇葩業(yè)務(wù)場景可能會提各種無理需求。
作為技術(shù)人員，要“通知以情曉之以理”，給產(chǎn)品經(jīng)理講解明白搜索引擎的原理、Elasticsearch的原理，哪些能做，哪些真的“臣妾做不到”。

7、小結(jié)
實際業(yè)務(wù)開發(fā)中，公司一般要求又想馬兒不吃草，又想馬兒飛快跑。
對于Elasticsearch開發(fā)也是，硬件資源不足（cpu、內(nèi)存、磁盤都爆滿）幾乎沒有辦法提升性能的。
除了檢索聚合，讓Elasticsearch做N多相關(guān)、不相干的工作，然后得出結(jié)論“Elastic也就那樣慢，沒有想像的快”。
你腦海中是否也有類似的場景浮現(xiàn)呢？
提供相對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、社區(qū)：https://elasticsearch.cn/article/6202
6、社區(qū)：https://elasticsearch.cn/article/708
7、社區(qū)：https://elasticsearch.cn/article/6202
---------------------?
作者：銘毅天下?
來源：CSDN?
原文：https://blog.csdn.net/laoyang360/article/details/85109769?
版權(quán)聲明：本文為博主原創(chuàng)文章，轉(zhuǎn)載請附上博文鏈接！

總結(jié)

以上是生活随笔為你收集整理的让Elasticsearch飞起来：性能优化实践干货的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。