1、優(yōu)化 Elasticsearch

1.1、服務(wù)器資源選擇

# ----------------------------------- Paths ------------------------------------
#
# Path to directory where to store the data (separate multiple locations by comma):
#
#path.data: /path/to/data
#
# Path to log files:
#
#path.logs: /path/to/logs

1.1.2、內(nèi)存設(shè)置

-Xms1g
-Xmx1g

• -Xms 31g
• -Xmx 31g

1.1.3、服務(wù)器CPU和ES內(nèi)存配比

服務(wù)器CPU和ES實(shí)例 JVM 堆內(nèi)存配比規(guī)則建議如下：

例1：高并發(fā)業(yè)務(wù)場景下，在虛擬機(jī)部署一個(gè) ES 熱數(shù)據(jù)節(jié)點(diǎn)，ES的JVM堆內(nèi)存大小設(shè)置為31GB，則虛擬機(jī)至少配置 16 核CPU，計(jì)算公式：[31/21]（[] 表示結(jié)果向上取整，下同)。

例2：高并發(fā)業(yè)務(wù)場景下，在物理機(jī)部署2個(gè) ES 熱數(shù)據(jù)節(jié)點(diǎn)，ES的JM堆內(nèi)存大小設(shè)置為31GB，則物理機(jī)至少配置 16 核CPU，計(jì)算公式：2x[31/41]。

1.2、索引設(shè)計(jì)

1.2.1、合理設(shè)置索引分片數(shù)

分片和副本的設(shè)計(jì)為 ES 提供了支持分布式和故障轉(zhuǎn)移的特性，但并不意味著分片和副本是可以無限分配的。而且注意因?yàn)樗饕穆酚蓹C(jī)制，在索引創(chuàng)建之后就無法再改變其分片的數(shù)量。

分片數(shù)不能設(shè)置太大，分片對資源是有消耗的，如下：

• 一個(gè)分片的底層即為一個(gè) Lucene 索引，會(huì)消耗一定文件句柄、內(nèi)存、以及 CPU 運(yùn)轉(zhuǎn)。
• 每一個(gè)搜索請求都需要命中索引中的每一個(gè)分片，如果每一個(gè)分片都處于不同的節(jié)點(diǎn)還好，但如果多個(gè)分片都需要在同一個(gè)節(jié)點(diǎn)上競爭使用相同的資源就有些糟糕了。
• 用于計(jì)算相關(guān)度的詞項(xiàng)統(tǒng)計(jì)信息是基于分片的。如果有許多分片，每一個(gè)都只有很少的數(shù)據(jù)會(huì)導(dǎo)致很低的相關(guān)度。

一個(gè)業(yè)務(wù)索引具體需要分配多少分片可能需要架構(gòu)師和技術(shù)人員對業(yè)務(wù)的增長有個(gè)預(yù)先的判斷，橫向擴(kuò)展應(yīng)當(dāng)分階段進(jìn)行，為下一階段準(zhǔn)備好足夠的資源。

一般來說，分片數(shù)設(shè)置遵循以下原則：

為提升性能，索引創(chuàng)建時(shí)要根據(jù)存量數(shù)據(jù)以及未來一年數(shù)據(jù)的預(yù)估增長量，規(guī)劃合理的主分片個(gè)數(shù)，單個(gè)索引的主分片數(shù)量應(yīng)不超過 128 個(gè)。計(jì)算方法如下：

說明：

• N：表示建議單個(gè)索引的主分片個(gè)數(shù)，N<=128，如果計(jì)算出來的N大于128，應(yīng)對索引進(jìn)行拆分
• S：表示單個(gè)索引為了一年的總數(shù)據(jù)量，S=存量數(shù)據(jù)+未來一年數(shù)據(jù)的預(yù)估增長量
• N=S/20，20 為建議一年后的索引單個(gè)分片的大小

同一索引的主分片和副本分片禁止部署在同一臺服務(wù)器上。

1.2.2、映射和字段設(shè)置規(guī)范

1. 應(yīng)當(dāng)根據(jù)業(yè)務(wù)需要合理規(guī)劃索引的映射，不采用動(dòng)態(tài)生成映射，采用模板創(chuàng)建索引，固定住索引字段，字段個(gè)數(shù)不超過 1000 個(gè)
2. 字符串自動(dòng)類型：text 和 keyword，精準(zhǔn)查詢和聚合技術(shù)的字段指定為 keyword 類型，分詞檢索字段指定為 text 類型
3. 數(shù)值類型盡量選擇短精度的，以節(jié)省存儲(chǔ)空間
4. 數(shù)值類型若無范圍檢索和計(jì)算需求，盡量使用 keyword 類型，可大大提高查詢效率

1.3、推遲分片分配

對于節(jié)點(diǎn)瞬時(shí)中斷的問題，默認(rèn)情況，集群會(huì)等待一分鐘來查看節(jié)點(diǎn)是否會(huì)重新加入，如果這個(gè)節(jié)點(diǎn)在此期間重新加入，重新加入的節(jié)點(diǎn)會(huì)保持其現(xiàn)有的分片數(shù)據(jù)，不會(huì)觸發(fā)新的分片分配。這樣就可以減少 ES 在自動(dòng)再平衡可用分片時(shí)所帶來的極大開銷。

通過修改參數(shù) delayed_timeout ，可以延長再均衡的時(shí)間，可以全局設(shè)置，也可以在索引級別進(jìn)行修改。如下配置某個(gè)索引的推遲分配時(shí)間：

PUT /_all/_settings 
{
   "settings": {
       "index.unassigned.node_left.delayed_timeout": "5m" 
   }
}

1.4、帶 routing（文檔 _id）查詢

Elasticsearch 是通過以下公式知道一個(gè)文檔存放在哪個(gè)分片中的：（具體解釋參考：http://www.rzrgm.cn/wenxuehai/p/18141760#_label4_0）

shard = hash(routing) % number_of_primary_shards

當(dāng)不帶 routing 查詢時(shí)，因?yàn)椴恢酪樵兊臄?shù)據(jù)具體在哪個(gè)分片上，所以會(huì)先計(jì)算出該數(shù)據(jù)存儲(chǔ)在哪個(gè)節(jié)點(diǎn)上，然后再將請求分發(fā)到具體節(jié)點(diǎn)。但當(dāng)你帶 routing 查詢時(shí)，即指定了文檔存儲(chǔ)的分片，通過這種方式，ES 只會(huì)在相關(guān)的分片上執(zhí)行查詢，從而能提高查詢效率。

1.5、寫入速度優(yōu)化

ES 的默認(rèn)配置，是綜合了數(shù)據(jù)可靠性、寫入速度、搜索實(shí)時(shí)性等因素，實(shí)際使用時(shí)，我們需要根據(jù)公司要求，進(jìn)行偏向性的優(yōu)化。針對于搜索性能要求不高，但是對寫入要求較高的場景，我們需要盡可能的選擇恰當(dāng)寫優(yōu)化策略。綜合來說，可以考慮以下幾個(gè)方面來提升寫索引的性能：

1. 加大 Translog Flush ，目的是降低 Iops、Writeblock。
2. 增加 Index Refresh 間隔，目的是減少 Segment Merge 的次數(shù)。
3. 調(diào)整 Bulk 線程池和隊(duì)列。
4. 優(yōu)化節(jié)點(diǎn)間的任務(wù)分布。
5. 優(yōu)化 Lucene 層的索引建立，目的是降低 CPU 及 IO。

1.5.1、批量數(shù)據(jù)提交

ES 提供了 Bulk API 支持批量操作，當(dāng)我們有大量的寫任務(wù)時(shí)，可以使用 Bulk 來進(jìn)行批量寫入。通用的策略如下：Bulk 默認(rèn)設(shè)置批量提交的數(shù)據(jù)量不能超過 100M，數(shù)據(jù)條數(shù)一般是根據(jù)文檔的大小和服務(wù)器性能而定的，我們可以將單次批處理的數(shù)據(jù)大小應(yīng)從 5MB～15MB 逐漸增加，當(dāng)性能沒有提升時(shí)，把這個(gè)數(shù)據(jù)量作為最大值。

1.5.2、優(yōu)化存儲(chǔ)設(shè)備

1.5.3、合理使用合并

Lucene 以段的形式存儲(chǔ)數(shù)據(jù)。當(dāng)有新的數(shù)據(jù)寫入索引時(shí)，Lucene 就會(huì)自動(dòng)創(chuàng)建一個(gè)新的段。隨著數(shù)據(jù)量的變化，段的數(shù)量會(huì)越來越多，消耗的多文件句柄數(shù)及 CPU 就越多，查詢效率就會(huì)下降。由于 Lucene 段合并的計(jì)算量龐大，會(huì)消耗大量的 I/O，所以 ES 默認(rèn)采用較保守的策略，在后臺定期進(jìn)行段合并。

1.5.4、減少 Refresh 的次數(shù)

Lucene 在新增數(shù)據(jù)時(shí)，采用了延遲寫入的策略，默認(rèn)情況下索引的 refresh_interval 為1 秒。Lucene 將待寫入的數(shù)據(jù)先寫到內(nèi)存中，超過 1 秒（默認(rèn)）時(shí)就會(huì)觸發(fā)一次 Refresh，然后 Refresh 會(huì)把內(nèi)存中的的數(shù)據(jù)刷新到操作系統(tǒng)的文件緩存系統(tǒng)中。

如果我們對搜索的實(shí)效性要求不高，可以將 Refresh 周期延長，例如 30 秒。這樣還可以有效地減少段刷新次數(shù)，但這同時(shí)意味著需要消耗更多的 Heap 內(nèi)存。

1.5.5、加大 Flush 設(shè)置

Flush 的主要目的是把文件緩存系統(tǒng)中的段持久化到硬盤，當(dāng) Translog 的數(shù)據(jù)量達(dá)到512MB 或者 30 分鐘時(shí)，會(huì)觸發(fā)一次 Flush。index.translog.flush_threshold_size 參數(shù)的默認(rèn)值是 512MB，我們可以進(jìn)行修改。增加參數(shù)值意味著文件緩存系統(tǒng)中可能需要存儲(chǔ)更多的數(shù)據(jù)，所以我們需要為操作系統(tǒng)的文件緩存系統(tǒng)留下足夠的空間。

1.5.6、減少副本的數(shù)量

ES 為了保證集群的可用性，提供了 Replicas（副本）支持，然而每個(gè)副本也會(huì)執(zhí)行分析、索引及可能的合并過程，所以 Replicas 的數(shù)量會(huì)嚴(yán)重影響寫索引的效率。

當(dāng)寫索引時(shí)，需要把寫入的數(shù)據(jù)都同步到副本節(jié)點(diǎn)，副本節(jié)點(diǎn)越多，寫索引的效率就越慢。

如果我們需要大批量進(jìn)行寫入操 作 ，可以先禁止 Replica 復(fù)制 ， 設(shè)置index.number_of_replicas: 0 關(guān)閉副本。在寫入完成后，Replica 修改回正常的狀態(tài)。

2、ES配置說明

3、索引階段性能提升

• 使用批量請求并調(diào)整其大小：每次批量數(shù)據(jù) 5–15 MB 大是個(gè)不錯(cuò)的起始點(diǎn)。
• 段和合并：Elasticsearch 默認(rèn)值是 20 MB/s，對機(jī)械磁盤應(yīng)該是個(gè)不錯(cuò)的設(shè)置。如果你用的是 SSD，可以考慮提高到 100–200 MB/s。如果你在做批量導(dǎo)入，完全不在意搜索，你可以徹底關(guān)掉合并限流。另外還可以增加 index.translog.flush_threshold_size 設(shè)置，從默認(rèn)的 512 MB 到更大一些的值，比如 1GB，這可以在一次清空觸發(fā)的時(shí)候在事務(wù)日志里積累出更大的段。
• 如果你的搜索結(jié)果不需要近實(shí)時(shí)的準(zhǔn)確度，考慮把每個(gè)索引的 index.refresh_interval 改到 30s。
• 如果你在做大批量導(dǎo)入，考慮通過設(shè)置 index.number_of_replicas: 0 關(guān)閉副本。