30 個 ElasticSearch 調(diào)優(yōu)知識點，都給你整理好了！

ES官方調(diào)優(yōu)指南

第一部分：調(diào)優(yōu)索引速度

第二部分：調(diào)優(yōu)搜索速度

第三部分：通用的一些建議

ES發(fā)布時帶有的默認(rèn)值，可為es的開箱即用帶來很好的體驗。全文搜索、高亮、聚合、索引文檔 等功能無需用戶修改即可使用,當(dāng)你更清楚的知道你想如何使用es后，你可以作很多的優(yōu)化以提高你的用例的性能,下面的內(nèi)容告訴你 你應(yīng)該/不應(yīng)該 修改哪些配置。

第一部分：調(diào)優(yōu)索引速度

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

使用批量請求批量請求將產(chǎn)生比單文檔索引請求好得多的性能。

為了知道批量請求的最佳大小，您應(yīng)該在具有單個分片的單個節(jié)點上運行基準(zhǔn)測試。首先嘗試索引100個文件，然后是200，然后是400，等等。當(dāng)索引速度開始穩(wěn)定時，您知道您達(dá)到了數(shù)據(jù)批量請求的最佳大小。在配合的情況下，最好在太少而不是太多文件的方向上犯錯。請注意，如果群集請求太大，可能會使群集受到內(nèi)存壓力，因此建議避免超出每個請求幾十兆字節(jié)，即使較大的請求看起來效果更好。

發(fā)送端使用多worker/多線程向es發(fā)送數(shù)據(jù) 發(fā)送批量請求的單個線程不太可能將Elasticsearch群集的索引容量最大化。為了使用集群的所有資源，您應(yīng)該從多個線程或進(jìn)程發(fā)送數(shù)據(jù)。除了更好地利用集群的資源，這應(yīng)該有助于降低每個fsync的成本。

請確保注意TOOMANYREQUESTS（429）響應(yīng)代碼（Java客戶端的EsRejectedExecutionException），這是Elasticsearch告訴您無法跟上當(dāng)前索引速率的方式。發(fā)生這種情況時，應(yīng)該再次嘗試暫停索引，理想情況下使用隨機指數(shù)回退。

與批量調(diào)整大小請求類似，只有測試才能確定最佳的worker數(shù)量。這可以通過逐漸增加工作者數(shù)量來測試，直到集群上的I / O或CPU飽和。

1.調(diào)大 refresh interval

默認(rèn)的index.refresh_interval是1s，這迫使Elasticsearch每秒創(chuàng)建一個新的分段。增加這個價值（比如說30s）將允許更大的部分flush并減少未來的合并壓力。

2.加載大量數(shù)據(jù)時禁用refresh和replicas

如果您需要一次加載大量數(shù)據(jù)，則應(yīng)該將index.refreshinterval設(shè)置為-1并將index.numberofreplicas設(shè)置為0來禁用刷新。這會暫時使您的索引處于危險之中，因為任何分片的丟失都將導(dǎo)致數(shù)據(jù) 丟失，但是同時索引將會更快，因為文檔只被索引一次。初始加載完成后，您可以將index.refreshinterval和index.numberofreplicas設(shè)置回其原始值。

3.設(shè)置參數(shù)，禁止OS將es進(jìn)程swap出去

您應(yīng)該確保操作系統(tǒng)不會swapping out the java進(jìn)程，通過禁止swap （https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-configuration-memory.html）

4.為filesystem cache分配一半的物理內(nèi)存

文件系統(tǒng)緩存將用于緩沖I / O操作。您應(yīng)該確保將運行Elasticsearch的計算機的內(nèi)存至少減少到文件系統(tǒng)緩存的一半。

5.使用自動生成的id（auto-generated ids）

索引具有顯式id的文檔時，Elasticsearch需要檢查具有相同id的文檔是否已經(jīng)存在于相同的分片中，這是昂貴的操作，并且隨著索引增長而變得更加昂貴。通過使用自動生成的ID，Elasticsearch可以跳過這個檢查，這使索引更快。

6.買更好的硬件

搜索一般是I/O 密集的，此時，你需要

1. 為filesystem cache分配更多的內(nèi)存
2. 使用SSD硬盤
3. 使用local storage（不要使用NFS、SMB 等remote filesystem）
4. 亞馬遜的 彈性塊存儲（Elastic Block Storage）也是極好的，當(dāng)然，和local storage比起來，它還是要慢點

如果你的搜索是 CPU-密集的，買好的CPU吧

7.加大 indexing buffer size

如果你的節(jié)點只做大量的索引，確保index.memory.indexbuffersize足夠大，每個分區(qū)最多可以提供512 MB的索引緩沖區(qū)，而且索引的性能通常不會提高。Elasticsearch采用該設(shè)置（java堆的一個百分比或絕對字節(jié)大?。⑵溆米魉谢顒臃制墓蚕砭彌_區(qū)。非?；钴S的碎片自然會使用這個緩沖區(qū)，而不是執(zhí)行輕量級索引的碎片。

默認(rèn)值是10％，通常很多：例如，如果你給JVM 10GB的內(nèi)存，它會給索引緩沖區(qū)1GB，這足以承載兩個索引很重的分片。

8.禁用fieldnames字段

fieldnames字段引入了一些索引時間開銷，所以如果您不需要運行存在查詢，您可能需要禁用它。（fieldnames：https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-field-names-field.html）

9.剩下的，再去看看 “調(diào)優(yōu) 磁盤使用”吧

（https://www.elastic.co/guide/en/elasticsearch/reference/current/tune-for-disk-usage.html）中有許多磁盤使用策略也提高了索引速度。

第二部分-調(diào)優(yōu)搜索速度

1.filesystem cache越大越好

為了使得搜索速度更快， es嚴(yán)重依賴filesystem cache

一般來說，需要至少一半的 可用內(nèi)存 作為filesystem cache，這樣es可以在物理內(nèi)存中 保有 索引的熱點區(qū)域（hot regions of the index）

2.用更好的硬件

搜索一般是I/O bound的，此時，你需要

• 為filesystem cache分配更多的內(nèi)存
• 使用SSD硬盤
• 使用local storage（不要使用NFS、SMB 等remote filesystem）
• 亞馬遜的 彈性塊存儲（Elastic Block Storage）也是極好的，當(dāng)然，和local storage比起來，它還是要慢點

如果你的搜索是 CPU-bound，買好的CPU吧

3.文檔模型（document modeling）

文檔需要使用合適的類型，從而使得 search-time operations 消耗更少的資源。咋作呢？答：避免 join操作。具體是指

• nested 會使得查詢慢 好幾倍
• parent-child關(guān)系 更是使得查詢慢幾百倍

如果 無需join 能解決問題，則查詢速度會快很多

4.預(yù)索引 數(shù)據(jù)

根據(jù)“搜索數(shù)據(jù)最常用的方式”來最優(yōu)化索引數(shù)據(jù)的方式

舉個例子：所有文檔都有price字段，大部分query 在 fixed ranges 上運行 range aggregation。你可以把給定范圍的數(shù)據(jù) 預(yù)先索引下。然后，使用 terms aggregation

5.Mappings（能用 keyword 最好了）

數(shù)字類型的數(shù)據(jù)，并不意味著一定非得使用numeric類型的字段。

一般來說，存儲標(biāo)識符的 字段（書號ISBN、或來自數(shù)據(jù)庫的 標(biāo)識一條記錄的 數(shù)字），使用keyword更好（integer，long 不好哦，親）

6.避免運行腳本

一般來說，腳本應(yīng)該避免。如果他們是絕對需要的，你應(yīng)該使用painless和expressions引擎。

7.搜索rounded 日期

日期字段上使用now，一般來說不會被緩存。但，rounded date則可以利用上query cache

rounded到分鐘等

8.強制merge只讀的index

只讀的index可以從“merge成 一個單獨的 大segment”中收益

9.預(yù)熱 全局序數(shù)（global ordinals）

全局序數(shù) 用于 在 keyword字段上 運行 terms aggregations

es不知道 哪些fields 將 用于/不用于 term aggregation，因此 全局序數(shù) 在需要時才加載進(jìn)內(nèi)存

但，可以在mapping type上，定義 eagerglobalordinals==true，這樣，refresh時就會加載 全局序數(shù)

10.預(yù)熱 filesystem cache

機器重啟時，filesystem cache就被清空。OS將index的熱點區(qū)域（hot regions of the index）加載進(jìn)filesystem cache是需要花費一段時間的。

設(shè)置 index.store.preload 可以告知OS 這些文件需要提早加載進(jìn)入內(nèi)存

11.使用索引排序來加速連接

索引排序?qū)τ谝暂^慢的索引為代價來加快連接速度非常有用。在索引分類文檔中閱讀更多關(guān)于它的信息。

12.使用preference來優(yōu)化高速緩存利用率

有多個緩存可以幫助提高搜索性能，例如文件系統(tǒng)緩存，請求緩存或查詢緩存。然而，所有這些緩存都維護(hù)在節(jié)點級別，這意味著如果連續(xù)運行兩次相同的請求，則有一個或多個副本，并使用循環(huán)（默認(rèn)路由算法），那么這兩個請求將轉(zhuǎn)到不同的分片副本，阻止節(jié)點級別的緩存幫助。

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

13.副本可能有助于吞吐量，但不會一直存在

除了提高彈性外，副本可以幫助提高吞吐量。例如，如果您有單個分片索引和三個節(jié)點，則需要將副本數(shù)設(shè)置為2，以便共有3個分片副本，以便使用所有節(jié)點。

現(xiàn)在假設(shè)你有一個2-shards索引和兩個節(jié)點。在一種情況下，副本的數(shù)量是0，這意味著每個節(jié)點擁有一個分片。在第二種情況下，副本的數(shù)量是1，這意味著每個節(jié)點都有兩個碎片。哪個設(shè)置在搜索性能方面表現(xiàn)最好？通常情況下，每個節(jié)點的碎片數(shù)少的設(shè)置將會更好。

原因在于它將可用文件系統(tǒng)緩存的份額提高到了每個碎片，而文件系統(tǒng)緩存可能是Elasticsearch的1號性能因子。同時，要注意，沒有副本的設(shè)置在發(fā)生單個節(jié)點故障的情況下會出現(xiàn)故障，因此在吞吐量和可用性之間進(jìn)行權(quán)衡。

那么復(fù)制品的數(shù)量是多少？如果您有一個具有numnodes節(jié)點的群集，那么numprimaries總共是主分片，如果您希望能夠一次處理maxfailures節(jié)點故障，那么正確的副本數(shù)是max（maxfailures，ceil（numnodes / numprimaries） - 1）。

14.打開自適應(yīng)副本選擇

當(dāng)存在多個數(shù)據(jù)副本時，elasticsearch可以使用一組稱為自適應(yīng)副本選擇的標(biāo)準(zhǔn)，根據(jù)包含分片的每個副本的節(jié)點的響應(yīng)時間，服務(wù)時間和隊列大小來選擇數(shù)據(jù)的最佳副本。這可以提高查詢吞吐量并減少搜索量大的應(yīng)用程序的延遲。

第三部分：通用的一些建議

1、不要 返回大的結(jié)果集

es設(shè)計來作為搜索引擎，它非常擅長返回匹配query的top n文檔。但，如“返回滿足某個query的 所有文檔”等數(shù)據(jù)庫領(lǐng)域的工作，并不是es最擅長的領(lǐng)域。如果你確實需要返回所有文檔，你可以使用Scroll API

2、避免 大的doc。即，單個doc 小了 會更好

given that(考慮到) http.maxcontextlength默認(rèn)==100MB，es拒絕索引操作100MB的文檔。當(dāng)然你可以提高這個限制，但，Lucene本身也有限制的，其為2GB 即使不考慮上面的限制，大的doc 會給 network/memory/disk帶來更大的壓力；

• 任何搜索請求，都需要獲取 _id 字段，由于filesystem cache工作方式。即使它不請求 _source字段，獲取大doc _id 字段消耗更大
• 索引大doc時消耗內(nèi)存會是 doc本身大小 的好幾倍
• 大doc的 proximity search, highlighting 也更加昂貴。它們的消耗直接取決于doc本身的大小

3、避免 稀疏

• 不相關(guān)數(shù)據(jù) 不要 放入同一個索引
• 一般化文檔結(jié)構(gòu)（Normalize document structures）
• 避免類型
• 在 稀疏 字段上，禁用 norms & doc_values 屬性

稀疏為什么不好？

Lucene背后的數(shù)據(jù)結(jié)構(gòu) 更擅長處理 緊湊的數(shù)據(jù)

text類型的字段，norms默認(rèn)開啟；numerics, date, ip, keyword，docvalues默認(rèn)開啟 Lucene內(nèi)部使用 integer的docid來標(biāo)識文檔 和 內(nèi)部API交互。

舉個例子：使用match查詢時生成docid的迭代器，這些docid被用于獲取它們的norm，以便計算score。當(dāng)前的實現(xiàn)是每個doc中保留一個byte用于存儲norm值。獲取norm值其實就是讀取doc_id位置處的一個字節(jié)

這非常高效，Lucene通過此值可以快速訪問任何一個doc的norm值；但，給定一個doc，即使某個field沒有值，仍需要為此doc的此field保留一個字節(jié)

docvalues也有同樣的問題。2.0之前的fielddata被現(xiàn)在的docvalues所替代了。

稀疏性 最明顯的影響是 對存儲的需求（任何doc的每個field，都需要一個byte）；但是呢，稀疏性 對 索引速度和查詢速度 也是有影響的，因為：即使doc并沒有某些字段值，但，索引時，依然需要寫這些字段，查詢時，需要skip這些字段的值

某個索引中擁有少量稀疏字段，這完全沒有問題。但，這不應(yīng)該成為常態(tài)

稀疏性影響最大的是 norms&docvalues ，但，倒排索引（用于索引 text以及keyword字段），二維點（用于索引geopoint字段）也會受到較小的影響。

如何避免稀疏呢？

1、不相關(guān)數(shù)據(jù) 不要 放入同一個索引 給個tip：索引小（即：doc的個數(shù)較少），則，primary shard也要少

2、一般化文檔結(jié)構(gòu)（Normalize document structures）

3、避免類型（Avoid mapping type） 同一個index，最好就一個mapping type。在同一個index下面，使用不同的mapping type來存儲數(shù)據(jù)，聽起來不錯，但，其實不好。given that(考慮到)每一個mapping type會把數(shù)據(jù)存入 同一個index，因此，多個不同mapping type，各個的field又互不相同，這同樣帶來了稀疏性 問題

4、在 稀疏 字段上，禁用 norms & doc_values 屬性

• norms用于計算score，無需score，則可以禁用它（所有filtering字段，都可以禁用norms）
• docvlaues用于sort&aggregations，無需這兩個，則可以禁用它 但是，不要輕率的做出決定，因為 norms&docvalues無法修改。只能reindex

秘訣1：混合 精確查詢和提取詞干（mixing exact search with stemming）

對于搜索應(yīng)用，提取詞干（stemming）都是必須的。例如：查詢 skiing時，ski和skis都是期望的結(jié)果

但，如果用戶就是要查詢skiing呢？

解決方法是：使用multi-field。同一份內(nèi)容，以兩種不同的方式來索引存儲 query.simplequerystring.quotefieldsuffix，竟然是 查詢完全匹配的

秘訣2：獲取一致性的打分

score不能重現(xiàn) 同一個請求，連續(xù)運行2次，但，兩次返回的文檔順序不一致。這是相當(dāng)壞的用戶體驗

如果存在 replica，則就可能發(fā)生這種事，這是因為：search時，replication group中的shard是按round-robin方式來選擇的，因此兩次運行同樣的請求，請求如果打到 replication group中的不同shard，則兩次得分就可能不一致

那問題來了，“你不是整天說 primary和replica是in-sync的，是完全一致的”嘛，為啥打到“in-sync的，完全一致的shard”卻算出不同的得分？

原因就是標(biāo)注為“已刪除”的文檔。如你所知，doc更新或刪除時，舊doc并不刪除，而是標(biāo)注為“已刪除”，只有等到 舊doc所在的segment被merge時，“已刪除”的doc才會從磁盤刪除掉

索引統(tǒng)計（index statistic）是打分時非常重要的一部分，但，由于 deleted doc 的存在，在同一個shard的不同copy（即：各個replica）上 計算出的 索引統(tǒng)計 并不一致

個人理解：

• 所謂 索引統(tǒng)計 應(yīng)該就是df，即 doc_freq
• 索引統(tǒng)計 是基于shard來計算的

搜索時，“已刪除”的doc 當(dāng)然是 永遠(yuǎn)不會 出現(xiàn)在 結(jié)果集中的 索引統(tǒng)計時，for practical reasons，“已刪除”doc 依然是統(tǒng)計在內(nèi)的

假設(shè)，shard A0 剛剛完成了一次較大的segment merge，然后移除了很多“已刪除”doc，shard A1 尚未執(zhí)行 segment merge，因此 A1 依然存在那些“已刪除”doc

于是：兩次請求打到 A0 和 A1 時，兩者的 索引統(tǒng)計 是顯著不同的

如何規(guī)避 score不能重現(xiàn) 的問題？使用 preference 查詢參數(shù)

發(fā)出搜索請求時候，用 標(biāo)識字符串 來標(biāo)識用戶，將 標(biāo)識字符串 作為查詢請求的preference參數(shù)。這確保多次執(zhí)行同一個請求時候，給定用戶的請求總是達(dá)到同一個shard，因此得分會更為一致（當(dāng)然，即使同一個shard，兩次請求 跨了 segment merge，則依然會得分不一致）

這個方式還有另外一個優(yōu)點，當(dāng)兩個doc得分一致時，則默認(rèn)按著doc的 內(nèi)部Lucene doc id 來排序（注意：這并不是es中的 _id 或 _uid）。但是呢，shard的不同copy間，同一個doc的 內(nèi)部Lucene doc id 可能并不相同。因此，如果總是達(dá)到同一個shard，則，具有相同得分的兩個doc，其順序是一致的

score錯了

score錯了（Relevancy looks wrong）

如果你發(fā)現(xiàn)

• 具有相同內(nèi)容的文檔，其得分不同
• 完全匹配 的查詢 并沒有排在第一位 這可能都是由 sharding 引起的
• 默認(rèn)情況下，搜索文檔時，每個shard自己計算出自己的得分。
• 索引統(tǒng)計 又是打分時一個非常重要的因素。

如果每個shard的 索引統(tǒng)計相似，則 搜索工作的很好

文檔是平分到每個primary shard的，因此 索引統(tǒng)計 會非常相似，打分也會按著預(yù)期工作。但，萬事都有個但是：

• 索引時使用了 routing（文檔不能平分到每個primary shard 啦）
• 查詢多個索引
• 索引中文檔的個數(shù) 非常少

這會導(dǎo)致：參與查詢的各個shard，各自的 索引統(tǒng)計 并不相似（而，索引統(tǒng)計對 最終的得分 又影響巨大），于是 打分出錯了（relevancy looks wrong）

那，如何繞過 score錯了（Relevancy looks wrong）？

如果數(shù)據(jù)集較小，則，只使用一個primary shard（es默認(rèn)是5個），這樣兩次查詢 索引統(tǒng)計 不會變化，因而得分也就一致啦

另一種方式是，將searchtype設(shè)置為：dfsquerythenfetech（默認(rèn)是querythenfetch）

dfsquerythen_fetch的作用是

• 向 所有相關(guān)shard 發(fā)出請求，要求 所有相關(guān)shard 返回針對當(dāng)前查詢的 索引統(tǒng)計
• 然后，coordinating node 將 merge這些 索引統(tǒng)計，從而得到 merged statistics
• coordinating node 要求 所有相關(guān)shard 執(zhí)行 query phase，于是 發(fā)出請求，這時，也帶上 merged statistics。這樣，執(zhí)行query的shard 將使用 全局的索引統(tǒng)計

大部分情況下，要求 所有相關(guān)shard 返回針對當(dāng)前查詢的 索引統(tǒng)計，這是非常cheap的。但，如果查詢中 包含 非常大量的 字段/term查詢，或者有 fuzzy查詢，此時，獲取 索引統(tǒng)計 可能并不cheap，因為 為了得到 索引統(tǒng)計 可能 term dictionary 中 所有的term都需要被查詢一遍。

英文原文：https://www.elastic.co/guide/en/elasticsearch/reference/current/how-to.html譯者：Ghost Stories 來源：http://wangnan.tech/post/elasticsearch-how-to