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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2 Mapping各字段的選型流程

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7、小結(jié)
實(shí)際業(yè)務(wù)開(kāi)發(fā)中，公司一般要求又想馬兒不吃草，又想馬兒飛快跑。
對(duì)于Elasticsearch開(kāi)發(fā)也是，硬件資源不足（cpu、內(nèi)存、磁盤都爆滿）幾乎沒(méi)有辦法提升性能的。
除了檢索聚合，讓Elasticsearch做N多相關(guān)、不相干的工作，然后得出結(jié)論“Elastic也就那樣慢，沒(méi)有想像的快”。
你腦海中是否也有類似的場(chǎng)景浮現(xiàn)呢？
提供相對(duì)NB的硬件資源、做好前期的各種準(zhǔn)備工作、讓Elasticsearch輕裝上陣，相信你的Elasticsearch也會(huì)飛起來(lái)！

來(lái)日我們?cè)傧鄷?huì)…

推薦閱讀：
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
---------------------?
作者：銘毅天下?
來(lái)源：CSDN?
原文：https://blog.csdn.net/laoyang360/article/details/85109769?
版權(quán)聲明：本文為博主原創(chuàng)文章，轉(zhuǎn)載請(qǐng)附上博文鏈接！

總結(jié)

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

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