1、問題引出

默認情況下，Elasticsearch 已針對大多數用例進行了優化，確保在寫入性能和查詢性能之間取得平衡。我們將介紹一些聚合性能優化的可配置參數，其中部分改進是以犧牲寫入性能爲代價的。目標是將聚合優化招數彙總到一個易於消化的短文中，爲大家的 Elasticsearch 集羣聚合性能優化提供一些指導。

2、聚合實戰問題

問題1：1天的數據 70W,聚合2次分桶正常查詢時間是 200ms左右, 增加了一個去重條件, 就10-13秒了,有優化的地方不？
問題2：請問在很多 terms 聚合的情況下，怎樣優化檢索？我的場景在無聚合時，吞吐量有 300，在加入 12 個聚合字段後，吞吐量不到20。
問題3：哪位兄弟幫忙發一個聚合優化的鏈接，我這個聚合幾千萬就好幾秒了？

3、認知前提

3.1 Elasticsearch 聚合是不嚴格精準的

原因在於：數據分散到多個分片，聚合是每個分片的取 Top X，導致結果不精準。

可以看一下之前的文章：Elasticsearch 聚合數據結果不精確，怎麼破？

3.2 從業務層面規避全量聚合

聚合結果的精準性和響應速度之間是相對矛盾的。

正常業務開發，產品經理往往要求：

第一：快速秒級或者毫秒級聚合響應。
第二：聚合結果精準。

殊不知，二者不可兼得。

遇到類似兩者都要兼得的需求，建議從架構選型和業務層面做規避處理。

3.3 刷新頻率

如下圖所示，Elasticsearch 中的 1 個索引由一個或多個分片組成，每個分片包含多個segment（段），每一個段都是一個倒排索引。

在 lucene 中，爲了實現高索引速度，使用了segment 分段架構存儲。一批寫入數據保存在一個段中，其中每個段最終落地爲磁盤中的單個文件。

如下圖所示，將文檔插入 Elasticsearch 時，它們會被寫入緩衝區中，然後在刷新時定期從該緩衝區刷新到段中。刷新頻率由 refresh_interval 參數控制，默認每1秒發生一次。也就是說，新插入的文檔在刷新到段（內存中）之前，是不能被搜索到的。

刷新的本質是：寫入數據由內存 buffer 寫入到內存段中，以保證搜索可見。

來看個例子，加深對 refresh_inteval 的理解，註釋部分就是解讀。

PUT test_0001/_doc/1
{
  "title":"just testing"
}
# 默認一秒的刷新頻率，秒級可見（用戶無感知）
GET test_0001/_search

DELETE test_0001
# 設置了60s的刷新頻率
PUT test_0001
{
  "settings": {
    "index":{
      "refresh_interval":"60s"
    }
  }
}

PUT test_0001/_doc/1
{
  "title":"just testing"
}
# 60s後纔可以被搜索到
GET test_0001/_search

關於是否需要實時刷新：

如果新插入的數據需要近乎實時的搜索功能，則需要頻繁刷新。
如果對最新數據的檢索響應沒有實時性要求，則應增加刷新間隔，以提高數據寫入的效率，從而應釋放資源輔助提高查詢性能。

關於刷新頻率對查詢性能的影響：

由於每刷新一次都會生成一個 Lucene 段，刷新頻率越小就意味着同樣時間間隔，生成的段越多。
每個段都要消耗句柄和內存。
每次查詢請求都需要輪詢每個段，輪詢完畢後再對結果進行合併。
也就意味着：refresh_interval 越小，產生的段越多，搜索反而會越慢；反過來說，加大 refresh_interval，會相對提升搜索性能。

4、聚合性能優化猛招

4.1 啓用 eager global ordinals 提升高基數聚合性能

適用場景：高基數聚合。

高基數聚合場景中的高基數含義：一個字段包含很大比例的唯一值。

global ordinals 中文翻譯成全局序號，是一種數據結構，應用場景如下：

基於 keyword，ip 等字段的分桶聚合，包含：terms聚合、composite 聚合等。
基於text 字段的分桶聚合（前提條件是：fielddata 開啓）。
基於父子文檔 Join 類型的 has_child 查詢和父聚合。

global ordinals 使用一個數值代表字段中的字符串值，然後爲每一個數值分配一個 bucket（分桶）。

global ordinals 的本質是：啓用 eager_global_ordinals 時，會在刷新（refresh）分片時構建全局序號。這將構建全局序號的成本從搜索階段轉移到了數據索引化（寫入）階段。

創建索引的同時開啓：eager_global_ordinals。

PUT my-index-000001
{
  "mappings": {
    "properties": {
      "tags": {
        "type": "keyword",
        "eager_global_ordinals": true
      }
    }
  }
}

注意：開啓 eager_global_ordinals 會影響寫入性能，因爲每次刷新時都會創建新的全局序號。爲了最大程度地減少由於頻繁刷新建立全局序號而導致的額外開銷，請調大刷新間隔 refresh_interval。

動態調整刷新頻率的方法如下：

PUT my-index-000001/_settings
{
  "index": {
    "refresh_interval": "30s"
  }
}

該招數的本質是：以空間換時間。

4.2 插入數據時對索引進行預排序

Index sorting （索引排序）可用於在插入時對索引進行預排序，而不是在查詢時再對索引進行排序，這將提高範圍查詢（range query）和排序操作的性能。
在 Elasticsearch 中創建新索引時，可以配置如何對每個分片內的段進行排序。
這是 Elasticsearch 6.X 之後版本纔有的特性。

Index sorting 實戰舉例：

PUT my-index-000001
{
  "settings": {
    "index": {
      "sort.field": "cur_time",
      "sort.order": "desc"
    }
  },
  "mappings": {
    "properties": {
      "cur_time": {
        "type": "date"
      }
    }
  }
}

如上示例是在：創建索引的設置部分設置待排序的字段：cur_time 以及排序方式：desc 降序。

注意：預排序將增加 Elasticsearch 寫入的成本。在某些用戶特定場景下，開啓索引預排序會導致大約 40%-50% 的寫性能下降。

也就是說，如果用戶場景更關注寫性能的業務，開啓索引預排序不是一個很好的選擇。

4.3 使用節點查詢緩存

節點查詢緩存（Node query cache）可用於有效緩存過濾器（filter）操作的結果。如果多次執行同一 filter 操作，這將很有效，但是即便更改過濾器中的某一個值，也將意味着需要計算新的過濾器結果。

例如，由於 “now” 值一直在變化，因此無法緩存在過濾器上下文中使用 “now” 的查詢。

那怎麼使用緩存呢？通過在 now 字段上應用 datemath 格式將其四捨五入到最接近的分鐘/小時等，可以使此類請求更具可緩存性，以便可以對篩選結果進行緩存。

關於 datemath 格式及用法，舉個例子來說明：

以下的示例，無法使用緩存。

PUT index/_doc/1
{
  "my_date": "2016-05-11T16:30:55.328Z"
}

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

但是，下面的示例就可以使用節點查詢緩存。

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

上述示例中的“now-1h/m” 就是 datemath 的格式。

更細化點說，如果當前時間 now 是：16:31:29，那麼range query 將匹配 my_date 介於：15:31:00 和 15:31:59 之間的時間數據。

同理，聚合的前半部分 query 中如果有基於時間查詢，或者後半部分 aggs 部分中有基於時間聚合的，建議都使用 datemath 方式做緩存處理以優化性能。

4.4 使用分片請求緩存

聚合語句中，設置：size：0，就會使用分片請求緩存緩存結果。

size = 0 的含義是：只返回聚合結果，不返回查詢結果。


GET /my_index/_search
{
  "size": 0,
  "aggs": {
    "popular_colors": {
      "terms": {
        "field": "colors"
      }
    }
  }
}

4.5 拆分聚合，使聚合並行化

這裏有個認知前提：Elasticsearch 查詢條件中同時有多個條件聚合，這個時候的多個聚合不是並行運行的。

這裏就有疑問：是不是可以通過 msearch 拆解多個聚合爲單個子語句來改善響應時間？

什麼意思呢，給個 Demo，toy_demo_003 數據來源：

基於兒童積木玩具圖解 Elasticsearch 聚合

示例一：常規的多條件聚合實現

如下響應時間：15 ms。

POST toy_demo_003/_search
{
  "size": 0,
  "aggs": {
    "hole_terms_agg": {
      "terms": {
        "field": "has_hole"
      }
    },
    "max_aggs":{
      "max":{
        "field":"size"
      }
    }
  }
}

示例二：msearch 拆分多個語句的聚合實現

如下響應時間：9 ms。

POST _msearch
{"index" : "toy_demo_003"}
{"size":0,"aggs":{"hole_terms_agg":{"terms":{"field":"has_hole"}}}}
{"index" : "toy_demo_003"}
{"size":0,"aggs":{"max_aggs":{"max":{"field":"size"}}}}

來個對比驗證吧：

藍色：類似示例一，單個query 中包含多個聚合，聚合數分別是：1,2,5,10。
紅色：類似示例二，multi_search 拆解多個聚合，拆分子句個數分別爲：1,2,5,10。
橫軸：藍色對應聚合個數；紅色對應子句個數；
縱軸：響應時間，響應時間越短、性能越好。

初步結論是：

默認情況下聚合不是並行運行。
當爲每個聚合提供自己的查詢並執行 msearch 時，性能會有顯著提升。
尤其在 10 個聚合的場景下，性能提升了接近 2 倍。

因此，在 CPU 資源不是瓶頸的前提下，如果想縮短響應時間，可以將多個聚合拆分爲多個查詢，藉助：msearch 實現並行聚合。

4.6 將聚合中的查詢條件移動到 query 子句部分

示例一：

POST my_index/_search
{
  "size": 0,
  "aggregations": {
    "1": {
      "filter": {
        "match": {
          "search_field": "text"
        }
      },
      "aggregations": {
        "items": {
          "top_hits": {
            "size": 100,
            "_source": {
              "includes": "field1"
            }
          }
        }
      }
    },
    "2": {
      "filter": {
        "match": {
          "search_field": "text"
        }
      },
      "aggregations": {
        "items": {
          "top_hits": {
            "size": 100,
            "_source": {
              "includes": "field2"
            }
          }
        }
      }
    }
  }
}

示例二：

{
  "query": {
    "bool": {
      "filter": [
        {
          "match": {
            "search_field": "text"
          }
        }
      ]
    }
  },
  "size": 0,
  "aggregations": {
    "1": {
      "top_hits": {
        "size": 100,
        "_source": {
          "includes": "field1"
        }
      }
    },
    "2": {
      "top_hits": {
        "size": 100,
        "_source": {
          "includes": "field2"
        }
      }
    }
  }
}

示例一和示例二的本質區別：

第二個查詢已將此過濾器提取到較高級別，這應使聚合共享結果。

如下對比實驗表明，由於 Elasticsearch 自身做了優化，示例一（藍色）和示例二（紅色）響應時間基本一致。

更多驗證需要結合業務場景做一下對比驗證，精簡起見，推薦使用第二種。

5、更多優化參考

官方關於檢索性能優化同樣適用於聚合
https://www.elastic.co/guide/en/elasticsearch/reference/current/tune-for-search-speed.html
分片數設置多少合理？
https://www.elastic.co/cn/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster
堆內存大小設置？
https://www.elastic.co/cn/blog/a-heap-of-trouble
禁用 swapping
https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-configuration-memory.html

6、小結

本文的六大猛招出自：Elastic 原廠諮詢架構師 Alexander 以及 Coolblue 公司的軟件開發工程師 Raoul Meyer。

六大猛招中的 msearch 並行聚合方式，令人眼前一亮，相比我在業務實戰中用的多線程方式實現並行，要“高級”了許多。

我結合自己的聚合優化實踐做了翻譯和擴展，希望對大家的聚合性能優化有所幫助。

歡迎留言寫下您的聚合優化實踐和思考。

和你一起，死磕 Elastic！

參考

https://qbox.io/blog/refresh-flush-operations-elasticsearch-guide
https://alexmarquardt.com/how-to-tune-elasticsearch-for-aggregation-performance/
https://www.elastic.co/cn/blog/index-sorting-elasticsearch-6-0
《Elasticsearch 源碼解析與優化實戰》

Elasticsearch 聚合性能優化六大猛招

1、問題引出

2、聚合實戰問題

3、認知前提

3.1 Elasticsearch 聚合是不嚴格精準的

3.2 從業務層面規避全量聚合

3.3 刷新頻率

4、聚合性能優化猛招

4.1 啓用 eager global ordinals 提升高基數聚合性能

4.2 插入數據時對索引進行預排序

4.3 使用節點查詢緩存

4.4 使用分片請求緩存

4.5 拆分聚合，使聚合並行化

4.6 將聚合中的查詢條件移動到 query 子句部分

5、更多優化參考

6、小結

參考

推薦

一個簡單的MD5加鹽

C# 代碼學習

藍橋15屆stema編程題密碼鎖-動態規劃 C++和Python最後一道題

2021看雪SDC議題回顧 | SaTC：一種全新的物聯網設備漏洞自動化挖掘方法

Kafka存儲機制

aws語音呼叫調用，告警電話

【轉】[C#] WebAPI 防止併發調用二（冥等性）

C#/.NET/.NET Core優秀項目和框架2024年4月簡報

HTTP URL 詳解

得物 ZooKeeper SLA 也可以 99.99%

服務鏈路跟蹤：Sleuth+Zipkin

阿里雲文件存儲NAS和對象存儲OSS區別對比如何選擇？

什麼是 Kubernetes？

Elasticsearch 聚合性能優化六大猛招

【重磅】TensorFlow中文社區論壇發佈

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結