elasticsearch 優化
從硬件上 ：
- 使用SSD 硬盤，解決io導致的瓶頸。
- 增大內存 但不超過32G(單實例建議設置31G) ，elasticsearch 設置不超過機器內存的60%。
- 如果負載過高，增加cpu核心數。
從軟件上：
- 減少集群的副本數量， 一般集群有1-2兩個副本即可，最多有3個副本。
Elasticsearch 默認副本數量為 3 個，雖然這樣會提高集群的可用性，增加搜索的並發數，但是同時也會影響寫入索引的效率。
在索引過程中，需要把更新的文檔發到副本節點上，等副本節點生效后在進行返回結束。使用 Elasticsearch 做業務搜索的時候，建議副本數目還是設置為 3 個，但是像內部 ELK 日志系統、分布式跟蹤系統中，完全可以將副本數目設置為 1 個。
-
根據業務量設定分片的數量（默認分片是為5個，分片是為了解決一個索引過大），多分片會導致io壓力。
-
一個索引不要過大--》分索引（按日分，按周分）
-
減少索引的document里的字段，在跟需要查詢的用戶確認他們需要的字段，然后將一些不需要的字段清除。將filebeat的一些name字段，version字段刪除。
-
針對不使用的index，進行close。我們需要的時候再進行open，可以節約內存和減輕系統的壓力。
curl -XPOST 127.0.0.1:9200/index_name/_close
curl -XPOST 127.0.0.1:9200/index_name/_open
-
增加 Refresh 時間間隔
為了提高索引性能，Elasticsearch 在寫入數據時候，采用延遲寫入的策略，即數據先寫到內存中，當超過默認 1 秒 （index.refresh_interval）會進行一次寫入操作，就是將內存中 segment 數據刷新到操作系統中，此時我們才能將數據搜索出來，所以這就是為什么 Elasticsearch 提供的是近實時搜索功能，而不是實時搜索功能。
當然像我們的內部系統對數據延遲要求不高的話，我們可以通過延長 refresh 時間間隔，可以有效的減少 segment 合並壓力，提供索引速度。在做全鏈路跟蹤的過程中，我們就將 index.refresh_interval 設置為 30s，減少 refresh 次數。
同時，在進行全量索引時，可以將 refresh 次數臨時關閉，即 index.refresh_interval 設置為 -1，數據導入成功后再打開到正常模式，比如 30s。
如果我們的業務是要求的實時性比較高的，將index.refresh_interval 設置為 -1 -
不使用swap(虛擬內存)
為什么要禁用？禁用swap
-
使用elastisearch 自動生成的id(_id)
也就是我們的document的字段里面不要有_id字段，讓該字段由elasticsearch自動生成。這樣索引更快。
從用戶使用層
- 用戶層：用戶去搜索的時候需要避免返回比較大的結果集，通過設置默認的搜索時間段，來盡量避免返回較大的結果集。
- 用戶進行搜索的時候盡量使用過濾器（Filter）這樣可以從縮小搜索范圍。比如我們在查詢報錯日志時，我們通過level字段篩選出ERROR等級，然后再進行搜索，這樣對系統的壓力可以減小，並且搜索速度更快。
文檔：
官網：
https://www.elastic.co/guide/en/elasticsearch/reference/current/tune-for-indexing-speed.html
優化方案：
https://elasticsearch.cn/article/6202