Elasticsearch性能優(yōu)化實(shí)戰(zhàn)指南

作者：銘毅天下

背景
在當(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)之間均勻分配分片。
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)行排序。
使用舉例：

PUT /twitter
 {
     "settings" : {
         "index" : {
             "sort.field" : "date", 
             "sort.order" : "desc" 
         }
     },
     "mappings": {
        "properties": {
            "date": {
                "type": "date"
            }
        }
    }
}

目的：index sorting是優(yōu)化Elasticsearch檢索性能的非常重要的方式之一。
大白話：index sorting機(jī)制通過寫入的時(shí)候指定了某一個(gè)或者多個(gè)字段的排序方式，會(huì)極大提升檢索的性能。

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ù)量為如上公式值。
總的來說：節(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的磁盤空間（201640=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è)置方式：

PUT /twitter/_settings
{
  "index.blocks.read_only_allow_delete": null
}

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)方式：
curl -X POST "localhost:9200/kimchy/_forcemerge?only_expunge_deletes=false&max_num_segments=100&flush=true"

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)舉例：

GET /_search?preference=xyzabc123
{
    "query": {
        "match": {
            "title": "elasticsearch"
        }
    }

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í)配置：
`sudo swapoff -a``

Elasticsearch配置文件elasticsearch.yml配置：
bootstrap.memory_lock: true

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)：

PUT /twitter/_settings
{
    "index" : {
        "refresh_interval" : "1s"
    }
}

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)：

curl -XPUT 'localhost:9200/_settings' -d '{ 
     "index.merge.scheduler.max_thread_count" : 1
}

7、禁止動(dòng)態(tài)分配分片
有時(shí)，Elasticsearch將重新平衡集群中的分片。此操作可能會(huì)降低檢索的性能。
在生產(chǎn)模式下，需要時(shí)，可以通過cluster.routing.rebalance.enable設(shè)置將重新平衡設(shè)置為none。
PUT /_cluster/settings

{ 
  "transient" : {
    "cluster.routing.allocation.enable" : "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)之前禁用分配可以避免這種情況。

8、充分利用近似日期緩存效果
現(xiàn)在使用的日期字段上的查詢通常不可緩存，因?yàn)槠ヅ涞姆秶恢痹谧兓?br/>然而，就用戶體驗(yàn)而言，切換到近似日期通常是可接受的，并且能更好地使用查詢高速緩存帶來的益處。
實(shí)戰(zhàn)如下：

 GET index/_search
 {
   "query": {
     "constant_score": {
       "filter": {
         "range": {
           "my_date": {
             "gte": "now-1h/m",
             "lte": "now/m"
          }
        }
      }
    }
  }
}

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)行的搜索查詢性能。

PUT movies
 {
   "mappings": {
     "properties": {
       "cars_infos": {
         "type": "text"
       },
       "brand_name": {
         "type": "text",
        "copy_to": "cars_infos"
      },
      "engine_version": {
        "type": "text",
        "copy_to": "cars_infos"
      },
   "model ": {
        "type": "text",
        "copy_to": "cars_infos"
      },
   "color": {
        "type": "text",
        "copy_to": "cars_infos"
      }
    }
  }
}

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)：

PUT _cluster/settings
{
“transient” : {
“cluster.routing.allocation.balance.shard” : 0.60
}
}

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％。

PUT /_cluster/settings
{
  "persistent" : {
    "indices.breaker.fielddata.limit" : "60%" 
  }
}

最好為斷路器設(shè)置一個(gè)相對(duì)保守點(diǎn)的值。
《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)容：

thread_pool.search.queue_size: 500
#queue_size允許控制沒有線程執(zhí)行它們的掛起請(qǐng)求隊(duì)列的初始大小。

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)打開方法：

PUT /_cluster/settings
{
    "transient": {
        "cluster.routing.use_adaptive_replica_selection": true
    }
}

4、小結(jié)
Elasticsearch集群有許多配置設(shè)置可以減少響應(yīng)延遲，提升檢索性能。 以上只是冰山一角。

歡迎大家奇異交流，喜歡文章記得點(diǎn)個(gè)贊，感謝支持！