點(diǎn)擊上方“朱小廝的博客”，選擇“設(shè)為星標(biāo)”

回復(fù)”1024“獲取獨(dú)家整理的學(xué)習(xí)資料

0、背景

在當(dāng)今世界，各行各業(yè)每天都有海量數(shù)據(jù)產(chǎn)生，為了從這些海量數(shù)據(jù)中獲取想要的分析結(jié)果，需要對(duì)數(shù)據(jù)進(jìn)行提取、轉(zhuǎn)換，存儲(chǔ)，維護(hù)，管理和分析。 這已然遠(yuǎn)遠(yuǎn)超出了普通處理工具、數(shù)據(jù)庫(kù)等的實(shí)現(xiàn)能力，只有基于的分布式架構(gòu)和并行處理機(jī)制的大數(shù)據(jù)工具所才能實(shí)現(xiàn)這些功能。 Elasticsearch是響應(yīng)如前所述大多數(shù)用例的最熱門的開源數(shù)據(jù)存儲(chǔ)引擎之一。

Elasticsearch是一種分布式數(shù)據(jù)存儲(chǔ)和搜索引擎，具有容錯(cuò)和高可用性特點(diǎn)。為了充分利用其搜索功能，需要正確配置Elasticsearch。

簡(jiǎn)單的默認(rèn)配置不適合每個(gè)實(shí)際業(yè)務(wù)場(chǎng)景。實(shí)戰(zhàn)開發(fā)運(yùn)維中，個(gè)性化實(shí)現(xiàn)貼合自己業(yè)務(wù)場(chǎng)景的集群配置是優(yōu)化集群性能的必經(jīng)之路。本文集合實(shí)戰(zhàn)業(yè)務(wù)場(chǎng)景，重點(diǎn)介紹搜索密集型Elasticsearch集群的提升性能的干貨配置。

1、索引層面優(yōu)化配置

默認(rèn)情況下，6.x及之前的版本中Elasticsearch索引有5個(gè)主分片和1個(gè)副本，7.X及之后版本1主1副。 這種配置并不適用于所有業(yè)務(wù)場(chǎng)景。 需要正確設(shè)置分片配置，以便維持索引的穩(wěn)定性和有效性。

1.1、分片大小

分片大小對(duì)于搜索查詢非常重要。

• 一方面， 如果分配給索引的分片太多，則Lucene分段會(huì)很小，從而導(dǎo)致開銷增加。當(dāng)同時(shí)進(jìn)行多個(gè)查詢時(shí)，許多小分片也會(huì)降低查詢吞吐量。

• 另一方面，太大的分片會(huì)導(dǎo)致搜索性能下降和故障恢復(fù)時(shí)間更長(zhǎng)。

Elasticsearch官方建議一個(gè)分片的大小應(yīng)該在20到40 GB左右。

例如，如果您計(jì)算出索引將存儲(chǔ)300 GB的數(shù)據(jù)，則可以為該索引分配9到15個(gè)主分片。?

根據(jù)集群大小，假設(shè)群集中有10個(gè)節(jié)點(diǎn)，您可以選擇為此索引分配10個(gè)主分片，以便在集群節(jié)點(diǎn)之間均勻分配分片。

深入原理推薦：

Elasticsearch之如何合理分配索引分片？

https://www.elastic.co/cn/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster

Elasticsearch究竟要設(shè)置多少分片數(shù)？

https://qbox.io/blog/optimizing-elasticsearch-how-many-shards-per-index

1.2、數(shù)據(jù)動(dòng)態(tài)持續(xù)寫入場(chǎng)景

如果存在連續(xù)寫入到Elasticsearch集群的數(shù)據(jù)流，如：實(shí)時(shí)爬蟲互聯(lián)網(wǎng)數(shù)據(jù)寫入ES集群。則應(yīng)使用基于時(shí)間的索引以便更輕松地維護(hù)索引。

如果寫入數(shù)據(jù)流的吞吐量隨時(shí)間而變化，則需要適當(dāng)?shù)馗淖兿乱粋€(gè)索引的配置才能實(shí)現(xiàn)數(shù)據(jù)的動(dòng)態(tài)擴(kuò)展。

那么，如何查詢分散到不同的基于時(shí)間索引的所有文檔？答案是別名。可以將多個(gè)索引放入別名中，并且對(duì)該別名進(jìn)行搜索會(huì)使查詢就像在單個(gè)索引上一樣。

當(dāng)然，需要保持好平衡。注意思考：將多少數(shù)據(jù)寫入別名？別名上寫入太多小索引會(huì)對(duì)性能產(chǎn)生負(fù)面影響。

例如，是以周還是以月為單位為單位建立索引是需要結(jié)合業(yè)務(wù)場(chǎng)景平衡考慮的問題？

如果以月為單位建議索引性能最優(yōu)，那么相同數(shù)據(jù)以周為單位建立索引勢(shì)必會(huì)因?yàn)樗饕鄬?dǎo)致負(fù)面的性能問題。

1.3、Index Sorting

注意：索引排序機(jī)制是6.X版本才有的特性。

在Elasticsearch中創(chuàng)建新索引時(shí)，可以配置每個(gè)分片中的分段的排序方式。 默認(rèn)情況下，Lucene不會(huì)應(yīng)用任何排序。 index.sort.* 定義應(yīng)使用哪些字段對(duì)每個(gè)Segment內(nèi)的文檔進(jìn)行排序。

使用舉例：

目的：index sorting是優(yōu)化Elasticsearch檢索性能的非常重要的方式之一。

大白話：index sorting機(jī)制通過寫入的時(shí)候指定了某一個(gè)或者多個(gè)字段的排序方式，會(huì)極大提升檢索的性能。

更深原理：推薦閱讀：

https://www.elastic.co/cn/blog/index-sorting-elasticsearch-6-0

2、分片層面優(yōu)化配置

分片是底層基本的讀寫單元，分片的目的是分割巨大索引，讓讀寫并行執(zhí)行。寫入過程先寫入主分片，主分片寫入成功后再寫入副本分片。

副本分片的出現(xiàn)，提升了集群的高可用性和讀取吞吐率。

在優(yōu)化分片時(shí)，分片的大小、節(jié)點(diǎn)中有多少分片是主要考慮因素。副本分片對(duì)于擴(kuò)展搜索吞吐量很重要，如果硬件條件允許，則可以小心增加副本分片的數(shù)量。

容量規(guī)劃的一個(gè)很好的啟動(dòng)點(diǎn)是分配分片，“《深入理解Elasticsearch》強(qiáng)調(diào)：最理想的分片數(shù)量應(yīng)該依賴于節(jié)點(diǎn)的數(shù)量。”其數(shù)量是節(jié)點(diǎn)數(shù)量的1.5到3倍。

分配副本分片數(shù)的公式：max（max_failures，ceil（num_nodes /） num_primaries） - ?1）。

原理：如果您的群集具有num_nodes節(jié)點(diǎn)，總共有num_primaries主分片，如果您希望最多能夠同時(shí)處理max_failures節(jié)點(diǎn)故障，那么適合您的副本數(shù)量為如上公式值。

公式來源：

https://www.elastic.co/guide/en/elasticsearch/reference/master/tune-for-search-speed.html

總的來說：節(jié)點(diǎn)數(shù)和分片數(shù)、副本數(shù)的簡(jiǎn)單計(jì)算公式如下：
所需做大節(jié)點(diǎn)數(shù)=分片數(shù)*（副本數(shù)+1）。

3、Elasticsearch整體層面配置

配置Elasticsearch集群時(shí)，最主要的考慮因素之一是確保至少有一半的可用內(nèi)存進(jìn)入文件系統(tǒng)緩存，以便Elasticsearch可以將索引的hot regions保留在物理內(nèi)存中。

在設(shè)計(jì)集群時(shí)還應(yīng)考慮物理可用堆空間。 Elasticsearch建議基于可用堆空間的分片分配最多應(yīng)為20個(gè)分片/ GB，這是一個(gè)很好的經(jīng)驗(yàn)法則。

例如，具有30 GB堆的節(jié)點(diǎn)最多應(yīng)有600個(gè)分片，以保持集群的良好狀態(tài)。

一個(gè)節(jié)點(diǎn)上的存儲(chǔ)可以表述如下：節(jié)點(diǎn)可以支持的磁盤空間= 20 （堆大小單位：GB）（以GB為單位的分片大小），由于在高效集群中通常會(huì)看到大小在20到40 GB之間的分片，因此最大存儲(chǔ)空間可以支持16 GB可用堆空間的節(jié)點(diǎn)，最多可達(dá)12 TB的磁盤空間（20*16*40=12.8TB）。

邊界意識(shí)有助于為更好的設(shè)計(jì)和未來的擴(kuò)展操作做好準(zhǔn)備。

可以在運(yùn)行時(shí)以及初始階段進(jìn)行許多配置設(shè)置。

在構(gòu)建Elasticsearch索引和集群本身以獲得更好的搜索性能時(shí)，了解在運(yùn)行時(shí)哪些配置可以修改以及哪些配不可以修改是至關(guān)重要的。

3.1 動(dòng)態(tài)設(shè)置

1、設(shè)置歷史數(shù)據(jù)索引為只讀狀態(tài)。

基于時(shí)間的動(dòng)態(tài)索引的執(zhí)行階段，如果存放歷史數(shù)據(jù)的索引沒有寫操作，可以將月度索引設(shè)置為只讀模式，以提高對(duì)這些索引的搜索性能。
6.X之后的只讀索引實(shí)戰(zhàn)設(shè)置方式：

2、對(duì)只讀狀態(tài)索引，進(jìn)行段合并。

當(dāng)索引設(shè)置為只讀時(shí)，可以通過強(qiáng)制段合并操作以減少段的數(shù)量。

優(yōu)化段合并將導(dǎo)致更好的搜索性能，因?yàn)槊總€(gè)分片的開銷取決于段的計(jì)數(shù)和大小。

• 注意1：不要將段合并用于讀寫索引，因?yàn)樗鼘?dǎo)致產(chǎn)生非常大的段（每段> 5Gb）。

• 注意2：此操作應(yīng)在非高峰時(shí)間進(jìn)行，因?yàn)檫@是一項(xiàng)非常耗資源的操作。

段合并操作實(shí)戰(zhàn)方式：

3、使用preference優(yōu)化緩存利用率

有多個(gè)緩存可以幫助提高搜索性能，例如文件系統(tǒng)緩存，請(qǐng)求緩存或查詢緩存。

然而，所有這些緩存都維護(hù)在節(jié)點(diǎn)級(jí)別，這意味著如果您在擁有1個(gè)或更多副本且基于默認(rèn)路由算法集群上連續(xù)兩次運(yùn)行相同的請(qǐng)求，這兩個(gè)請(qǐng)求將轉(zhuǎn)到不同的分片副本上 ，阻止節(jié)點(diǎn)級(jí)緩存幫助。

由于搜索應(yīng)用程序的用戶一個(gè)接一個(gè)地運(yùn)行類似的請(qǐng)求是常見的，例如為了檢索分析索引的部分較窄子集，使用preference標(biāo)識(shí)當(dāng)前用戶或會(huì)話的偏好值可以幫助優(yōu)化高速緩存的使用。

preference實(shí)戰(zhàn)舉例：

4、禁止交換

可以在每個(gè)節(jié)點(diǎn)上禁用交換以確保穩(wěn)定性，并且應(yīng)該不惜一切代價(jià)避免交換。它可能導(dǎo)致垃圾收集持續(xù)數(shù)分鐘而不是毫秒，并且可能導(dǎo)致節(jié)點(diǎn)響應(yīng)緩慢甚至斷開與集群的連接。

在Elasticsearch分布式系統(tǒng)中，讓操作系統(tǒng)終止節(jié)點(diǎn)更有效。可以通過將bootstrap.memory_lock設(shè)置為True來禁用它。

Linux系統(tǒng)級(jí)配置：

Elasticsearch配置文件elasticsearch.yml配置：

5、增加刷新間隔 refresh_interval

默認(rèn)刷新間隔為1秒。這迫使Elasticsearch每秒創(chuàng)建一個(gè)分段。實(shí)際業(yè)務(wù)中，應(yīng)該根據(jù)使用情況增加刷新間隔，舉例：增加到30秒。

這樣之后，30s產(chǎn)生一個(gè)大的段，較每秒刷新大大減少未來的段合并壓力。最終會(huì)提升寫入性能并使搜索查詢更加穩(wěn)定。

更新刷新間隔實(shí)戰(zhàn)：

6、設(shè)置max_thread_count

index.merge.scheduler.max_thread_count默認(rèn)設(shè)置為

Math.max(1, Math.min(4, Runtime.getRuntime().availableProcessors() / 2))

但這適用于SSD配置。對(duì)于HDD，應(yīng)將其設(shè)置為1。

實(shí)戰(zhàn)：

7、禁止動(dòng)態(tài)分配分片

有時(shí)，Elasticsearch將重新平衡集群中的分片。此操作可能會(huì)降低檢索的性能。

在生產(chǎn)模式下，需要時(shí)，可以通過cluster.routing.rebalance.enable設(shè)置將重新平衡設(shè)置為none。

其中典型的應(yīng)用場(chǎng)景之包括：

集群中臨時(shí)重啟、剔除一個(gè)節(jié)點(diǎn)；

集群逐個(gè)升級(jí)節(jié)點(diǎn)；當(dāng)您關(guān)閉節(jié)點(diǎn)時(shí)，分配過程將立即嘗試將該節(jié)點(diǎn)上的分片復(fù)制到集群中的其他節(jié)點(diǎn)，從而導(dǎo)致大量浪費(fèi)的IO. 在關(guān)閉節(jié)點(diǎn)之前禁用分配可以避免這種情況。

更多實(shí)踐，推薦閱讀：

https://www.elastic.co/guide/en/elasticsearch/reference/5.5/restart-upgrade.html

8、充分利用近似日期緩存效果

現(xiàn)在使用的日期字段上的查詢通常不可緩存，因?yàn)槠ヅ涞姆秶恢痹谧兓?/span>

然而，就用戶體驗(yàn)而言，切換到近似日期通常是可接受的，并且能更好地使用查詢高速緩存帶來的益處。

實(shí)戰(zhàn)如下：

這里可能不大好理解，推薦深入閱讀：

https://www.elastic.co/guide/en/elasticsearch/reference/current/tune-for-search-speed.html

3.2 初始設(shè)置

1、合并多字段提升檢索性能

query_string或multi_match查詢所針對(duì)的字段越多，檢索越慢。

提高多個(gè)字段的搜索速度的常用技術(shù)是在索引時(shí)將其值復(fù)制到單個(gè)字段中。

對(duì)于經(jīng)常查詢的某些字段，請(qǐng)使用Elasticsearch的copy-to功能。

例如，汽車的品牌名稱，發(fā)動(dòng)機(jī)版本，型號(hào)名稱和顏色字段可以與復(fù)制到指令合并。它將改善在這些字段上進(jìn)行的搜索查詢性能。

2、設(shè)置分片分配到指定節(jié)點(diǎn)

實(shí)戰(zhàn)業(yè)務(wù)中經(jīng)常遇到的業(yè)務(wù)場(chǎng)景問題：如何將分片設(shè)置非均衡分配，有新節(jié)點(diǎn)配置極高，能否多分片點(diǎn)過去？

某個(gè) shard 分配在哪個(gè)節(jié)點(diǎn)上，一般來說，是由 ES 自動(dòng)決定的。以下幾種情況會(huì)觸發(fā)分配動(dòng)作：

• 1）新索引生成

• 2）索引的刪除

• 3）新增副本分片

• 4）節(jié)點(diǎn)增減引發(fā)的數(shù)據(jù)均衡

ES 提供了一系列參數(shù)詳細(xì)控制這部分邏輯，其中之一是：在異構(gòu)集群的情為具有更好硬件的節(jié)點(diǎn)的分片分配分配權(quán)重。

為了分配權(quán)重，

需要設(shè)置cluster.routing.allocation.balance.shard值，默認(rèn)值為0.45f。

數(shù)值越大越傾向于在節(jié)點(diǎn)層面均衡分片。

實(shí)戰(zhàn)：

3、調(diào)整熔斷內(nèi)存比例大小

查詢本身也會(huì)對(duì)響應(yīng)的延遲產(chǎn)生重大影響。為了在查詢時(shí)不觸發(fā)熔斷并導(dǎo)致Elasticsearch集群處于不穩(wěn)定狀態(tài)，

可以根據(jù)查詢的復(fù)雜性將indices.breaker.total.limit設(shè)置為適合您的JVM堆大小。此設(shè)置的默認(rèn)值是JVM堆的70％。

最好為斷路器設(shè)置一個(gè)相對(duì)保守點(diǎn)的值。更深原理推薦閱讀：

https://www.elastic.co/guide/cn/elasticsearch/guide/current/_limiting_memory_usage.html。

《Elastic源碼分析》作者張超指出：“Elasticsearch 7.0 增加了 indices.breaker.total.use_real_memory 配置項(xiàng)，可以更加精準(zhǔn)的分析當(dāng)前的內(nèi)存情況，及時(shí)防止 OOM 出現(xiàn)。雖然該配置會(huì)增加一點(diǎn)性能損耗，但是可以提高 JVM 的內(nèi)存使用率，增強(qiáng)了節(jié)點(diǎn)的保護(hù)機(jī)制。”

4、特定搜索場(chǎng)景，增加搜索線程池配置

默認(rèn)情況下，Elasticsearch將主要用例是搜索。在需要增加檢索并發(fā)性的情況下，可以增加用于搜索設(shè)置的線程池，與此同時(shí)，可以根據(jù)節(jié)點(diǎn)上的CPU中的核心數(shù)量多少斟酌減少用于索引的線程池。

舉例：更改配置文件elasticsearch.yml增加如下內(nèi)容：

官方：

https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-threadpool.html

5、打開自適應(yīng)副本選擇

應(yīng)打開自適應(yīng)副本選擇。該請(qǐng)求將被重定向到響應(yīng)最快的節(jié)點(diǎn)。

當(dāng)存在多個(gè)數(shù)據(jù)副本時(shí)，elasticsearch可以使用一組稱為自適應(yīng)副本選擇的標(biāo)準(zhǔn)，根據(jù)包含每個(gè)分片副本的節(jié)點(diǎn)的響應(yīng)時(shí)間，服務(wù)時(shí)間和隊(duì)列大小來選擇數(shù)據(jù)的最佳副本。

這樣可以提高查詢吞吐量并減少搜索量大的應(yīng)用程序的延遲。

這個(gè)配置默認(rèn)是關(guān)閉的，實(shí)戰(zhàn)打開方法：

4、小結(jié)

• Elasticsearch集群有許多配置設(shè)置可以減少響應(yīng)延遲，提升檢索性能。 以上只是冰山一角。更多實(shí)踐配置推薦閱讀官方文檔之鼻祖級(jí)優(yōu)化指南：

  https://www.elastic.co/guide/en/elasticsearch/reference/6.7/tune-for-search-speed.html

• 本文授權(quán)翻譯至國(guó)外Burak Alta?的博文，結(jié)合實(shí)戰(zhàn)并仔細(xì)核對(duì)官網(wǎng)最新7.2版本的配置，進(jìn)行了細(xì)節(jié)的調(diào)整和改動(dòng)，實(shí)操性更強(qiáng)。希望對(duì)你有幫助。

• 歡迎留言分享交流你在性能優(yōu)化上的經(jīng)驗(yàn)和教訓(xùn)。

推薦閱讀：
[1] ?Elasticsearch設(shè)置必讀更新清單：

https://nickcanzoneri.com/elasticsearch-settings/

[2] 英文原文：

https://medium.com/@burak.altas/how-to-optimize-elasticsearch-for-better-search-performance-283492e475f8

[3]讓Elasticsearch飛起來!——性能優(yōu)化實(shí)踐干貨

---

想知道更多？掃描下面的二維碼關(guān)注我

相關(guān)推薦：

• 《科普 | 明星公司之Netflix》

• 《看我如何作死 | 將CPU、IO打爆》

• 《看我如何作死 | 網(wǎng)絡(luò)延遲、丟包、中斷一個(gè)都沒落下》

>>>Learn More<<

點(diǎn)個(gè)"在看"唄^_^

總結(jié)

以上是生活随笔為你收集整理的干货！Elasticsearch性能优化实战指南的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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