優化

es的安裝和配置是非常輕量級的，為滿足多種不同的應用場景，底層提供多種資料結構支援，並做了大量的預設配置優化，部分配置針對具體的使用者使用場景可能是冗餘的，甚至可能造成效能的下降，需要根據實際業務場景做適當取捨，我們結合自身使用場景做了如下優化（文章中有疏漏或不正確的地方也歡迎點評指正）。

一、環境配置

sudo swapoff -a
# 禁用swapping，開啟伺服器虛擬記憶體交換功能會對es產生致命的打擊
vm.max_map_count
# 在/etc/sysctl.conf檔案中找到該引數，修改為655300後 執行sysctl -p，不然啟動時會報值太小

二、記憶體優化

　　常用的配置在兩個檔案裡，分別是 elasticsearch.yml 和 jvm.options（配置記憶體）

　　jvm.options主要是進行記憶體相關配置，elasticsearch預設給的1g，官方建議分配給es的記憶體不要超出系統記憶體的50%，預留一半給Lucene，因為Lucene會快取segment資料提升檢索效能；記憶體配置不要超過32g，如果你的伺服器記憶體沒有遠遠超過64g，那麼不建議將es的jvm記憶體設定為32g，因為超過32g後每個jvm物件指標的長度會翻倍，導致記憶體與cpu的開銷增大。

-Xms10g
-Xmx10g

三、基礎配置

　　修改配置檔案elasticsearch.yml

cluster.name: elasticsearch
叢集名稱，es服務會通過廣播方式自動連線在同一網段下的es服務，通過多播方式進行通訊，同一網段下可以有多個叢集，通過叢集名稱這個屬性來區分不同的叢集。

node.name: "test"
當前配置所在機器的節點名，你不設定就預設隨機指定一個name列表中名字，該name列表在es的jar包中config資料夾裡name.txt檔案中，其中有很多作者新增的有趣名字。

node.master: true
指定該節點是否有資格被選舉成為node（注意這裡只是設定成有資格， 不代表該node一定就是master），預設是true，es是預設叢集中的第一臺機器為master，如果這臺機掛了就會重新選舉master。

node.data: true
指定該節點是否儲存索引資料，預設為true。

index.number_of_shards: 5
設定預設索引分片個數，預設為5片。

index.number_of_replicas: 1
設定預設索引副本個數，預設為1個副本。如果採用預設設定，而你叢集只配置了一臺機器，那麼叢集的健康度為yellow，也就是所有的資料都是可用的，但是某些複製沒有被分配。

path.conf: /path/to/conf
設定配置檔案的儲存路徑，預設是es根目錄下的config資料夾。

path.data: /path/to/data
設定索引資料的儲存路徑，預設是es根目錄下的data資料夾，可以設定多個儲存路徑，用逗號隔開，例：path.data: /path/to/data1,/path/to/data2

path.work: /path/to/work
設定臨時檔案的儲存路徑，預設是es根目錄下的work資料夾。

path.logs: /path/to/logs
設定日誌檔案的儲存路徑，預設是es根目錄下的logs資料夾

path.plugins: /path/to/plugins
設定外掛的存放路徑，預設是es根目錄下的plugins資料夾, 外掛在es裡面普遍使用，用來增強原系統核心功能。

bootstrap.mlockall: true
設定為true來鎖住記憶體不進行swapping。因為當jvm開始swapping時es的效率 會降低，所以要保證它不swap，可以把ES_MIN_MEM和ES_MAX_MEM兩個環境變數設定成同一個值，並且保證機器有足夠的記憶體分配給es。 同時也要允許elasticsearch的程序可以鎖住記憶體，linux下啟動es之前可以通過`ulimit -l unlimited`命令設定。

network.bind_host: 192.168.0.1
設定繫結的ip地址，可以是ipv4或ipv6的，預設為127.0.0.1。

network.publish_host: 192.168.0.1
設定其它節點和該節點互動的ip地址，如果不設定它會自動判斷，值必須是個真實的ip地址。

network.host: 192.168.0.1
這個引數是用來同時設定bind_host和publish_host上面兩個引數。

transport.tcp.port: 9300
設定節點之間互動的tcp埠，預設是9300。

transport.tcp.compress: true
設定是否壓縮tcp傳輸時的資料，預設為false，不壓縮。

http.port: 9200
設定對外服務的http埠，預設為9200。

http.max_content_length: 100mb
設定內容的最大容量，預設100mb

http.enabled: false
是否使用http協議對外提供服務，預設為true，開啟。

gateway.type: local
gateway的型別，預設為local即為本地檔案系統，可以設定為本地檔案系統，分散式檔案系統，hadoop的HDFS，和amazon的s3伺服器等。

gateway.recover_after_nodes: 1
設定叢集中N個節點啟動時進行資料恢復，預設為1。

gateway.recover_after_time: 5m
設定初始化資料恢復程序的超時時間，預設是5分鐘。

gateway.expected_nodes: 2
設定這個叢集中節點的數量，預設為2，一旦這N個節點啟動，就會立即進行資料恢復。

cluster.routing.allocation.node_initial_primaries_recoveries: 4
初始化資料恢復時，併發恢復執行緒的個數，預設為4。

cluster.routing.allocation.node_concurrent_recoveries: 2
新增刪除節點或負載均衡時併發恢復執行緒的個數，預設為4。

indices.recovery.max_size_per_sec: 0
設定資料恢復時限制的頻寬，如入100mb，預設為0，即無限制。

indices.recovery.concurrent_streams: 5
設定這個引數來限制從其它分片恢復資料時最大同時開啟併發流的個數，預設為5。

discovery.zen.minimum_master_nodes: 1
設定這個引數來保證叢集中的節點可以知道其它N個有master資格的節點。預設為1，對於大的叢集來說，可以設定大一點的值（2-4）

discovery.zen.ping.timeout: 3s
設定叢集中自動發現其它節點時ping連線超時時間，預設為3秒，對於比較差的網路環境可以高點的值來防止自動發現時出錯。

discovery.zen.ping.multicast.enabled: false
設定是否開啟多播發現節點，預設是true。

discovery.zen.ping.unicast.hosts: ["host1", "host2:port", "host3[portX-portY]"]
設定叢集中master節點的初始列表，可以通過這些節點來自動發現新加入叢集的節點。

三、叢集優化

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系統上，通過執行以下命令臨時禁用交換：

sudo swapoff -a
1
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.3控制返回欄位和結果
和mysql查詢一樣，業務開發中，select * 操作幾乎是不必須的。
同理，ES中，_source 返回全部欄位也是非必須的。
要通過_source 控制欄位的返回，只返回業務相關的欄位。
網頁正文content，網頁快照html_content類似欄位的批量返回，可能就是業務上的設計缺陷。
顯然，摘要欄位應該提前寫入，而不是查詢content後再擷取處理。

5.4 分頁深度查詢和遍歷
分頁查詢使用：from+size;
遍歷使用：scroll；
並行遍歷使用：scroll+slice。
斟酌集合業務選型使用。

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

5.6 聚合分頁合理實現
聚合結果展示的時，勢必面臨聚合後分頁的問題，而ES官方基於效能原因不支援聚合後分頁。
如果需要聚合後分頁，需要自開發實現。包含但不限於：
方案一：每次取聚合結果，拿到記憶體中分頁返回。
方案二：scroll結合scroll after集合redis實現。

來源：https://www.cnblogs.com/aqicheng/p/14262484.html