1、問題引出

默認(rèn)情況下，Elasticsearch 已針對(duì)大多數(shù)用例進(jìn)行了優(yōu)化，確保在寫入性能和查詢性能之間取得平衡。我們將介紹一些聚合性能優(yōu)化的可配置參數(shù)，其中部分改進(jìn)是以犧牲寫入性能為代價(jià)的。目標(biāo)是將聚合優(yōu)化招數(shù)匯總到一個(gè)易于消化的短文中，為大家的 Elasticsearch 集群聚合性能優(yōu)化提供一些指導(dǎo)。

2、聚合實(shí)戰(zhàn)問題

• 問題1：1天的數(shù)據(jù) 70W,聚合2次分桶正常查詢時(shí)間是 200ms左右, 增加了一個(gè)去重條件, 就10-13秒了,有優(yōu)化的地方不？

• 問題2：請問在很多 terms 聚合的情況下，怎樣優(yōu)化檢索？我的場景在無聚合時(shí)，吞吐量有 300，在加入 12 個(gè)聚合字段后，吞吐量不到20。

• 問題3：哪位兄弟 幫忙發(fā)一個(gè)聚合優(yōu)化的鏈接，我這個(gè)聚合 幾千萬 就好幾秒了？

3、認(rèn)知前提

3.1 Elasticsearch 聚合是不嚴(yán)格精準(zhǔn)的

原因在于：數(shù)據(jù)分散到多個(gè)分片，聚合是每個(gè)分片的取 Top X，導(dǎo)致結(jié)果不精準(zhǔn)。

可以看一下之前的文章：Elasticsearch 聚合數(shù)據(jù)結(jié)果不精確，怎么破？

3.2 從業(yè)務(wù)層面規(guī)避全量聚合

聚合結(jié)果的精準(zhǔn)性和響應(yīng)速度之間是相對(duì)矛盾的。

正常業(yè)務(wù)開發(fā)，產(chǎn)品經(jīng)理往往要求：

• 第一：快速秒級(jí)或者毫秒級(jí)聚合響應(yīng)。

• 第二：聚合結(jié)果精準(zhǔn)。

殊不知，二者不可兼得。

遇到類似兩者都要兼得的需求，建議從架構(gòu)選型和業(yè)務(wù)層面做規(guī)避處理。

3.3 刷新頻率

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

在 lucene 中，為了實(shí)現(xiàn)高索引速度，使用了segment 分段架構(gòu)存儲(chǔ)。一批寫入數(shù)據(jù)保存在一個(gè)段中，其中每個(gè)段最終落地為磁盤中的單個(gè)文件。

如下圖所示，將文檔插入 Elasticsearch 時(shí)，它們會(huì)被寫入緩沖區(qū)中，然后在刷新時(shí)定期從該緩沖區(qū)刷新到段中。刷新頻率由 refresh_interval 參數(shù)控制，默認(rèn)每1秒發(fā)生一次。也就是說，新插入的文檔在刷新到段（內(nèi)存中）之前，是不能被搜索到的。

刷新的本質(zhì)是：寫入數(shù)據(jù)由內(nèi)存 buffer 寫入到內(nèi)存段中，以保證搜索可見。

來看個(gè)例子，加深對(duì) refresh_inteval ?的理解，注釋部分就是解讀。

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

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

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

關(guān)于是否需要實(shí)時(shí)刷新：

• 如果新插入的數(shù)據(jù)需要近乎實(shí)時(shí)的搜索功能，則需要頻繁刷新。

• 如果對(duì)最新數(shù)據(jù)的檢索響應(yīng)沒有實(shí)時(shí)性要求，則應(yīng)增加刷新間隔，以提高數(shù)據(jù)寫入的效率，從而應(yīng)釋放資源輔助提高查詢性能。

關(guān)于刷新頻率對(duì)查詢性能的影響：

• 由于每刷新一次都會(huì)生成一個(gè) Lucene 段，刷新頻率越小就意味著同樣時(shí)間間隔，生成的段越多。

• 每個(gè)段都要消耗句柄和內(nèi)存。

• 每次查詢請求都需要輪詢每個(gè)段，輪詢完畢后再對(duì)結(jié)果進(jìn)行合并。

• 也就意味著：refresh_interval 越小，產(chǎn)生的段越多，搜索反而會(huì)越慢；反過來說，加大 refresh_interval，會(huì)相對(duì)提升搜索性能。

4、聚合性能優(yōu)化猛招

4.1 ? ?啟用 eager global ordinals 提升高基數(shù)聚合性能

• 適用場景：高基數(shù)聚合。

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

global ordinals 中文翻譯成全局序號(hào)，是一種數(shù)據(jù)結(jié)構(gòu)，應(yīng)用場景如下：

• 基于 keyword，ip 等字段的分桶聚合，包含：terms聚合、composite 聚合等。

• 基于text 字段的分桶聚合（前提條件是：fielddata 開啟）。

• 基于父子文檔 Join 類型的 has_child 查詢和 父聚合。

global ordinals 使用一個(gè)數(shù)值代表字段中的字符串值，然后為每一個(gè)數(shù)值分配一個(gè) bucket（分桶）。

global ordinals 的本質(zhì)是：啟用 eager_global_ordinals 時(shí)，會(huì)在刷新（refresh）分片時(shí)構(gòu)建全局序號(hào)。這將構(gòu)建全局序號(hào)的成本從搜索階段轉(zhuǎn)移到了數(shù)據(jù)索引化（寫入）階段。

創(chuàng)建索引的同時(shí)開啟：eager_global_ordinals。

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

注意：開啟 eager_global_ordinals 會(huì)影響寫入性能，因?yàn)槊看嗡⑿聲r(shí)都會(huì)創(chuàng)建新的全局序號(hào)。為了最大程度地減少由于頻繁刷新建立全局序號(hào)而導(dǎo)致的額外開銷，請調(diào)大刷新間隔 refresh_interval。

動(dòng)態(tài)調(diào)整刷新頻率的方法如下：

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

該招數(shù)的本質(zhì)是：以空間換時(shí)間。

4.2 插入數(shù)據(jù)時(shí)對(duì)索引進(jìn)行預(yù)排序

• Index sorting （索引排序）可用于在插入時(shí)對(duì)索引進(jìn)行預(yù)排序，而不是在查詢時(shí)再對(duì)索引進(jìn)行排序，這將提高范圍查詢（range query）和排序操作的性能。

• 在 Elasticsearch 中創(chuàng)建新索引時(shí)，可以配置如何對(duì)每個(gè)分片內(nèi)的段進(jìn)行排序。

• 這是 Elasticsearch 6.X 之后版本才有的特性。

Index sorting 實(shí)戰(zhàn)舉例：

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

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

注意：預(yù)排序?qū)⒃黾?Elasticsearch 寫入的成本。在某些用戶特定場景下，開啟索引預(yù)排序會(huì)導(dǎo)致大約 40%-50% 的寫性能下降。

也就是說，如果用戶場景更關(guān)注寫性能的業(yè)務(wù)，開啟索引預(yù)排序不是一個(gè)很好的選擇。

4.3 使用節(jié)點(diǎn)查詢緩存

節(jié)點(diǎn)查詢緩存（Node query cache）可用于有效緩存過濾器（filter）操作的結(jié)果。如果多次執(zhí)行同一 filter 操作，這將很有效，但是即便更改過濾器中的某一個(gè)值，也將意味著需要計(jì)算新的過濾器結(jié)果。

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

那怎么使用緩存呢？通過在 now 字段上應(yīng)用 datemath 格式將其四舍五入到最接近的分鐘/小時(shí)等，可以使此類請求更具可緩存性，以便可以對(duì)篩選結(jié)果進(jìn)行緩存。

關(guān)于 datemath 格式及用法，舉個(gè)例子來說明：

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

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"
??????????}
????????}
??????}
????}
??}
}

但是，下面的示例就可以使用節(jié)點(diǎn)查詢緩存。

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

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

更細(xì)化點(diǎn)說，如果當(dāng)前時(shí)間 now 是：16:31:29，那么range query 將匹配 my_date 介于：15:31:00 和 15:31:59 之間的時(shí)間數(shù)據(jù)。

同理，聚合的前半部分 query 中如果有基于時(shí)間查詢，或者后半部分 aggs 部分中有基于時(shí)間聚合的，建議都使用 datemath 方式做緩存處理以優(yōu)化性能。

4.4 使用分片請求緩存

聚合語句中，設(shè)置：size：0，就會(huì)使用分片請求緩存緩存結(jié)果。

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

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

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

這里有個(gè)認(rèn)知前提：Elasticsearch 查詢條件中同時(shí)有多個(gè)條件聚合，這個(gè)時(shí)候的多個(gè)聚合不是并行運(yùn)行的。

這里就有疑問：是不是可以通過 msearch 拆解多個(gè)聚合為單個(gè)子語句來改善響應(yīng)時(shí)間？

什么意思呢，給個(gè) Demo，toy_demo_003 數(shù)據(jù)來源：

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

• 示例一：常規(guī)的多條件聚合實(shí)現(xiàn)

如下響應(yīng)時(shí)間：15 ms。

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

• 示例二：msearch 拆分多個(gè)語句的聚合實(shí)現(xiàn)

如下響應(yīng)時(shí)間：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"}}}}

來個(gè)對(duì)比驗(yàn)證吧：

• 藍(lán)色：類似示例一，單個(gè)query 中包含多個(gè)聚合，聚合數(shù)分別是：1,2,5,10。

• 紅色：類似示例二，multi_search 拆解多個(gè)聚合，拆分子句個(gè)數(shù)分別為：1,2,5,10。

• 橫軸：藍(lán)色對(duì)應(yīng)聚合個(gè)數(shù)；紅色對(duì)應(yīng)子句個(gè)數(shù)；

• 縱軸：響應(yīng)時(shí)間，響應(yīng)時(shí)間越短、性能越好。

初步結(jié)論是：

• 默認(rèn)情況下聚合不是并行運(yùn)行。

• 當(dāng)為每個(gè)聚合提供自己的查詢并執(zhí)行 msearch 時(shí)，性能會(huì)有顯著提升。

• 尤其在 10 個(gè)聚合的場景下，性能提升了接近 2 倍。

因此，在 CPU 資源不是瓶頸的前提下，如果想縮短響應(yīng)時(shí)間，可以將多個(gè)聚合拆分為多個(gè)查詢，借助：msearch 實(shí)現(xiàn)并行聚合。

4.6 將聚合中的查詢條件移動(dòng)到 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"
????????}
??????}
????}
??}
}

示例一和示例二的本質(zhì)區(qū)別：

第二個(gè)查詢已將此過濾器提取到較高級(jí)別，這應(yīng)使聚合共享結(jié)果。

如下對(duì)比實(shí)驗(yàn)表明，由于 Elasticsearch 自身做了優(yōu)化，示例一（藍(lán)色）和示例二（紅色）響應(yīng)時(shí)間基本一致。

更多驗(yàn)證需要結(jié)合業(yè)務(wù)場景做一下對(duì)比驗(yàn)證，精簡起見，推薦使用第二種。

5、更多優(yōu)化參考

• 官方關(guān)于檢索性能優(yōu)化同樣適用于聚合

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

• 分片數(shù)設(shè)置多少合理？

  https://www.elastic.co/cn/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster

• 堆內(nèi)存大小設(shè)置？

  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、小結(jié)

本文的六大猛招出自：Elastic 原廠咨詢架構(gòu)師 Alexander 以及 Coolblue 公司的軟件開發(fā)工程師 Raoul Meyer。

六大猛招中的 msearch 并行聚合方式，令人眼前一亮，相比我在業(yè)務(wù)實(shí)戰(zhàn)中用的多線程方式實(shí)現(xiàn)并行，要“高級(jí)”了許多。

我結(jié)合自己的聚合優(yōu)化實(shí)踐做了翻譯和擴(kuò)展，希望對(duì)大家的聚合性能優(yōu)化有所幫助。

歡迎留言寫下您的聚合優(yōu)化實(shí)踐和思考。

和你一起，死磕 Elastic！

參考

1. https://qbox.io/blog/refresh-flush-operations-elasticsearch-guide

2. https://alexmarquardt.com/how-to-tune-elasticsearch-for-aggregation-performance/

3. https://www.elastic.co/cn/blog/index-sorting-elasticsearch-6-0

4. 《Elasticsearch 源碼解析與優(yōu)化實(shí)戰(zhàn)》

推薦

1. 基于兒童積木玩具圖解 Elasticsearch 聚合
   

2. Elasticsearch 如何實(shí)現(xiàn)查詢/聚合不區(qū)分大小寫？
   

3. Elasticsearch 高基數(shù)聚合性能提升3倍，改動(dòng)了什么？

4. Elasticsearch聚合優(yōu)化 | 聚合速度提升5倍！

5. Elasticsearch聚合后分頁深入詳解
   

6. 從實(shí)戰(zhàn)中來，到實(shí)戰(zhàn)中去——Elasticsearch 技能更快提升方法論