Elasticsearch常見的5個錯誤及解決策略

網羅Elasticsearch最佳實踐，實際應用場景中常見錯誤要預知和避免，以最大化提升叢集效能。

1、採用動態Mapping

如果不定義Mapping，Elasticsearch會根據輸入的資料，建立對應的Mapping，這看起來非常完美，但是Elasticsearch的動態Mapping並不總是精確的。
動態Mapping對於入門很有用，但在某些時候您需要結合業務資料指定Mapping。

舉例1：5.x版本之後，需要分詞的欄位需要設定text型別和對應的analyzer ；僅需要精確匹配的可直接設定為keyword型別。
舉例2：長文字高亮需要在text型別的基礎上，設定fast-vector-highlighter高亮方式，高亮效率能提升20倍以上。

2、聚合設定不當導致OOM

在某些聚合中，沒有足夠的記憶體來支援複雜的巢狀聚合，導致聚合結果超時甚至OOM。

舉例說明：

現有9億條資料，45個索引，每條資料大小為2k左右 在查詢時候，
首先要按照時間進行排序，然後做三次分組操作？

群友討論實際問題

聚合爆炸是計算問題，可能導致某些聚合的桶生成呈指數增長，並可能導致不受控制的記憶體使用。

Elasticsearch“terms”欄位根據您的資料構建儲存桶，但無法預測將提前建立多少儲存桶。 對於由多個子聚合組成的父聚合，這可能會有問題。 組合每個子聚合中的唯一值可能會導致建立的桶數量大幅增加。

我們來看一個例子。

假設您有一個代表運動隊的資料集。 如果你想特別關注那支球隊的前10名球員和以及他們的支援球員，那麼聚合將如下所示

1{
 2"aggs" : {
 3"play_aggs" : {
 4"terms" : {
 5"field" : "players",
 6"size" : 10
 7},
 8"aggs" : {
 9"other_aggs" : {
10"terms" : {
11"field" : "players",
12"size" : 5
13}
14}
15}
16}
17}
18}

聚合將返回前10名球員的列表以及每位頂級球員的前五名支援球員的列表 - 這樣總共將返回50個值。這個看上去簡單的查詢可以輕而易舉地消耗大量記憶體。

terms聚合可以顯示為使用每個級別的桶的樹。因此，以上聚合中每個頂級球員的桶將構成第一級，而另一個聚合中的每個支援球員的桶將構成第二級。因此，一個團隊將生產n²桶。想象一下，如果您擁有5億個文件的資料集會發生什麼。

Collection Mode用於幫助控制子聚合的執行方式。聚合的預設Collection Mode稱為深度優先，首先需要構建整個樹，然後修剪邊緣。雖然深度優先是大多數聚合的適當收集模式，但它不適用於上面的運動員聚合示例。因此，Elasticsearch允許您將特定聚合中的收集模式更改為更合適的方式。

諸如上面的示例之類的規範應該使用廣度優先收集模式，該模式一次構建和修剪樹一級以控制聚合爆炸。 此收集模式極大地幫助減少消耗的記憶體量並保持節點穩定。

1{
 2"aggs" : {
 3"play_aggs" : {
 4"terms" : {
 5"field" : "players",
 6"size" : 10,
 7"collect_mode" : "breadth_first"
 8},
 9"aggs" : {
10"other_aggs" : {
11"terms" : {
12"field" : "players",
13"size" : 5
14}
15}
16}
17}
18}
19}

推薦閱讀：

3. ES索引設定不當

3.1 叢集名稱配置

ES啟動的預設群集名稱稱為elasticsearch。 如果群集中有許多節點，最好保持命名標誌儘可能一致，例如：

1cluster.name:app_es_production
2node.name:app_es_node_001

3.2 叢集恢復設定

節點的恢復設定也很重要。 假設群集中的某些節點由於故障而重新啟動，並且某些節點在其他節點之後重啟。 為了使所有這些節點之間的資料保持一致，我們必須執行一致性程式，以使所有叢集保持一致狀態。

舉例1：只要10個資料或主節點已加入群集，即可恢復。

1gateway.recover_after_nodes：10

舉例2：叢集中期待啟動節點達到20個以及時間超過7分鐘後，叢集重啟或恢復。

1gateway.expected_nodes：20
2gateway.recover_after_time：7m

使用正確的配置，可能需要數小時的恢復縮減到只需要分鐘級，極大提高工作效率。

3.3 防腦裂配置

minimum_master_nodes對於群集穩定性非常重要。 它們有助於防止腦裂。
此設定的建議值為（N / 2）+ 1 ， 其中N是候選主節點的節點數。
有了這個，如果你有10個可以儲存資料併成為主資料的 候選主節點，那麼該值將是6。
如果您有三個專用主節點和1,000個資料節點，則該值為兩個（僅計算候選主節點）：
discovery.zen.minimum_master_nodes：2

4、叢集不做規劃，遇到問題再說

1“我需要多少儲存空間、多大的記憶體？”是使用者經常問自己的問題。

遺憾的是，沒有固定的公式，但可以採取某些步驟來協助規劃資源。
推薦方法：模擬實際用例。
步驟1：建立ES叢集。
步驟2：使用與生產設定所需的資料速率幾乎相同的資料。
步驟3：啟動節點，用真實文件填充它們，然後推送填充資料到索引分片。

在模擬實際用例過程中瞭解資源利用率非常重要，因為它允許您為節點保留適當的RAM量，配置JVM堆空間並最佳化整個測試過程。

根據模擬結果，決定實際叢集的記憶體、CPU、磁碟容量。

5、執行緒池設定不合理

ES節點具有許多執行緒池，以便改進節點內執行緒的管理方式。 但是每個執行緒可以處理多少資料存在限制。 要跟蹤此值，我們可以使用ES屬性：

1threadpool.bulk.queue_size：2000

這會向ES通知分片中的請求數，當沒有可用於處理請求的執行緒時，新請求可以在節點中排隊等待執行。 如果任務數高於此值，您將獲得RemoteTransportException。 該值越高，節點機器上所需的堆空間量就越大，並且JVM堆也將被消耗。
此外，你應該在程式碼的開發階段做好異常處理。

注意：ES官網不建議修改此值。

小結

Elasticsearch的使用過程中總會遇到這樣、那樣的問題，多總結、多思考，形成針對業務場景的有效的解決方案。
同時，也要多吸取國內外社群、論壇、部落格中的精華，取長補短。

注意：網路文獻一般沒有涉及版本，老版本ES一些配置不一定適用於6.X最新版本，但，底層的技術永遠不過時。

參考：

[1]

[2]