Elasticsearch 緩存深入詳解

1、Elasticsearch 緩存引出

Elasticsearch 查詢的響應(yīng)需要占用 CPU、內(nèi)存資源，在復(fù)雜業(yè)務(wù)場景，會(huì)出現(xiàn)慢查詢，需要花費(fèi)大量的時(shí)間。

如何破局呢？增加集群硬件配置會(huì)有高昂硬件開銷。還有沒有其他方案呢？這時(shí)候會(huì)想到：緩存。

Elasticsearch 有哪些緩存，不同緩存的應(yīng)用場景是什么呢？本文給出答案。

2、Elasticsearch 緩存經(jīng)常被問道的問題匯總

• 怎樣知道自己的查詢時(shí)命中緩存了還是走的磁盤搜索？

• 我想每次查詢的時(shí)候直接顯示幾個(gè)小時(shí)以前的數(shù)據(jù) 而不是只有實(shí)時(shí)的，這些是要存到緩存中么？

• 看 Elasticsearch API的時(shí)候看到 /_cache/clear，這個(gè)緩存什么時(shí)候需要清理？有什么場景需要使用？

以上問題都是實(shí)戰(zhàn)業(yè)務(wù)場景的問題。

3、Elasticsearch 緩存分類

3.1 節(jié)點(diǎn)查詢緩存（Node query cache）

filter 過濾查詢的結(jié)果緩存在節(jié)點(diǎn)查詢緩存中，以便快速查找。

每個(gè)節(jié)點(diǎn)都有一個(gè)所有分片共享的查詢緩存。緩存使用 LRU （ Least Recently Used 緩存淘汰策略）策略，當(dāng)緩存已滿時(shí)，優(yōu)先清理最近最少使用的查詢結(jié)果，以騰出空間存放新結(jié)果數(shù)據(jù)。

用戶無法查看節(jié)點(diǎn)查詢緩存的內(nèi)容。

3.1.1 節(jié)點(diǎn)查詢緩存適用場景

• Term 查詢和 filter 查詢。

• 除 ?Term 查詢和 filter 查詢之外使用的查詢不符合緩存條件。

3.1.2 節(jié)點(diǎn)查詢緩存內(nèi)存上限

默認(rèn)情況下，節(jié)點(diǎn)查詢緩存最多可容納10000個(gè)查詢，最多占總堆空間的10％。

為了確定查詢是否符合緩存條件，Elasticsearch 維護(hù)查詢歷史記錄以跟蹤事件的發(fā)生。

如果一個(gè)段至少包含 10000 個(gè)文檔，并且該段具有超過一個(gè)分片的文檔總數(shù)的 3％ 的文檔數(shù)，則按每個(gè)段進(jìn)行緩存。由于緩存是按段劃分的，因此合并段可使緩存的查詢無效。

3.1.3 節(jié)點(diǎn)查詢緩存配置

說一下靜態(tài)配置（static）和 動(dòng)態(tài)配置 (dynamic）配置的本質(zhì)區(qū)別：

• 靜態(tài)配置：只能在配置文件配置，重啟后生效。
• 動(dòng)態(tài)配置：可以通過命令行（更新 setting）配置，配置后無需重啟即刻生效。

配置1：indices.queries.cache.size

• 靜態(tài)配置，需要在集群的每個(gè)數(shù)據(jù)節(jié)點(diǎn)配置。

• 含義：控制 filter 緩存的堆內(nèi)存大小。

• 接受百分比值（例如5％）或精確值（例如 512mb）。

• 默認(rèn)：為10％。

配置2：index.queries.cache.enabled

• 靜態(tài)配置，針對每個(gè)索引的配置。
• 含義：控制是否啟用節(jié)點(diǎn)查詢緩存。
• 設(shè)置時(shí)機(jī)：只能在創(chuàng)建索引或者關(guān)閉索引（close）時(shí)設(shè)置。
• 可設(shè)置：true 或者 false。
• 默認(rèn)：true。關(guān)閉緩存舉例：

PUT?my_index_0003
{
??"settings":?{
????"index.queries.cache.enabled":?false
??}
}

3.2 分片請求緩存（Shard request cache）

當(dāng)對一個(gè)索引或多個(gè)索引運(yùn)行搜索請求時(shí)，每個(gè)涉及的分片都會(huì)在本地執(zhí)行搜索并將其本地結(jié)果返回到協(xié)調(diào)節(jié)點(diǎn)，協(xié)調(diào)節(jié)點(diǎn)將這些分片級(jí)結(jié)果合并為一個(gè)“全局”結(jié)果集。

分片級(jí)請求緩存在每個(gè)分片上緩存本地結(jié)果，這使得頻繁使用的搜索請求幾乎立即返回結(jié)果。分片請求緩存非常適合日志用例場景，在這種情況下，數(shù)據(jù)不會(huì)在舊索引上更新，并且可以將常規(guī)聚合保留在高速緩存中以供重用。

默認(rèn)情況下：

• 請求緩存將僅緩存 size = 0 的搜索請求的結(jié)果，因此將不緩存hits，但將緩存hits.total，aggregations（聚合）和suggestions。

• 大多數(shù)使用 now 的查詢無法緩存。

3.2.1 分片請求緩存失效

刷新間隔（refresh_interval）越長，緩存的條目將保持有效的時(shí)間越長。如果緩存已滿，將驅(qū)逐最近最少使用的緩存。

可以使用 clear_cache API手動(dòng)使緩存過期，舉例如下：

POST?/kimchy,elasticsearch/_cache/clear?request=true

3.2.2 啟停分片請求緩存

• 設(shè)置索引時(shí)默認(rèn)停用緩存

PUT?my_index
{
??"settings":?{
????"index.requests.cache.enable":?false
??}
}

• 更新索引，啟用緩存

PUT?/my_index/_settings
{
??"index.requests.cache.enable":?true
}

• 查詢時(shí)，設(shè)置分片請求緩存

如下的設(shè)置會(huì)覆蓋索引級(jí)別的緩存設(shè)置。

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

注意：

第一：如果你的查詢使用結(jié)果有不確定的腳本（例如，使用隨機(jī)函數(shù)或引用當(dāng)前時(shí)間），則應(yīng)將request_cache標(biāo)志設(shè)置為false以禁用該請求的緩存。

第二：即使在索引設(shè)置中啟用了請求緩存，也不會(huì)緩存大小大于0（size > 0）的請求。要緩存這些請求，您將需要使用 query-string 參數(shù)（詳見官方文檔）。

3.2.3 緩存設(shè)置

緩存是在節(jié)點(diǎn)級(jí)別進(jìn)行管理的，默認(rèn)最大大小為堆的1％。可以使用以下命令在config / elasticsearch.yml 文件中進(jìn)行更改：

indices.requests.cache.size:?2%

此外，您可以使用 index.requests.cache.expire 設(shè)置為緩存的結(jié)果指定TTL，但是沒有理由這樣做（提供此設(shè)置僅出于完整性考慮）。

請記住，刷新索引后（refreshed），舊的結(jié)果將自動(dòng)失效。

3.2.4 緩存分片請求監(jiān)控

GET?/_stats/request_cache?human

GET?/_nodes/stats/indices/request_cache?human

3.3 Field data 緩存

Field data 緩存包含 field data 和 global ordinals，它們均用于支持某些字段類型上的聚合。由于這些都是堆上的數(shù)據(jù)結(jié)構(gòu)，因此監(jiān)視緩存的使用非常重要。

• field data 咱們之前文章分析過：Elasticsearch 內(nèi)部數(shù)據(jù)結(jié)構(gòu)深度解讀?

• global ordinals 可以簡單理解為：預(yù)熱全局序號(hào)，全局序號(hào)可以理解為：一種數(shù)據(jù)結(jié)構(gòu)，用戶 keyword 字段的 terms 聚合等用途。

Field data 緩存的構(gòu)建成本很高，因此默認(rèn)行為是將緩存加載到內(nèi)存中。默認(rèn)的緩存大小是無限的，這將導(dǎo)致緩存高速增長直到達(dá)到field data斷路器設(shè)置的限制。

如果設(shè)置了 field data 緩存大小限制，同樣的，緩存將開始清除緩存中最新最少更新的數(shù)據(jù)。此設(shè)置可以自動(dòng)避開斷路器限制，但需要根據(jù)需要重建緩存。

如果達(dá)到 field data 斷路器限制，Elasticsearch 底層將阻止進(jìn)一步增加緩存大小的請求。在這種情況下，你應(yīng)該手動(dòng)清除緩存。

這里要擴(kuò)展兩個(gè)Field data 斷路器 配置：

參數(shù)1：indices.breaker.fielddata.limit

• 動(dòng)態(tài)參數(shù)。
• 缺省值：堆內(nèi)存40%。

參數(shù)2：indices.breaker.fielddata.overhead

• 估計(jì)值常數(shù)，默認(rèn)：1.03

3.3.1 Field data 緩存設(shè)置

• 設(shè)置參數(shù)：indices.fielddata.cache.size。
• 參數(shù)類型：靜態(tài)參數(shù)。
• 參數(shù)含義：field data 緩存的最大值。
• 參數(shù)舉例：
  1）百分比，如：38%，代表：堆內(nèi)存38%。

? ? ? ?2）固定值，如：12 GB。

• 缺省值：無
• 設(shè)置舉例：需要在:elasticsearch.yml 中設(shè)置，重啟后生效，注意手動(dòng)設(shè)置大小要小于斷路器大小或者比例值。

3.3.2 Field data 緩存監(jiān)控

以下兩種方法可用于監(jiān)控：Field data 緩存及 斷路器使用情況。

• Field data 緩存監(jiān)控方法 1：

GET?/_nodes/stats

• Field data 緩存監(jiān)控方法 2：

GET?/_cat/fielddata

4、查詢與清理緩存

4.0 查詢緩存

全局查看緩存方法

GET?_cat/nodes?v&h=id,queryCacheMemory,queryCacheEvictions,requestCacheMemory,requestCacheHitCount,requestCacheMissCount,flushTotal,flushTotalTime

4.1 清理節(jié)點(diǎn)查詢緩存

POST?/twitter/_cache/clear?query=true

4.2 清理 request 請求緩存

POST?/twitter/_cache/clear?request=true????

4.3 清理 field data 緩存

POST?/twitter/_cache/clear?fielddata=true?

4.4 指定索引清理緩存

POST?/kimchy,elasticsearch/_cache/clear

4.5 清理全部的緩存

POST?/_cache/clear

5、Elasticsearch 三種緩存應(yīng)用場景

6、小結(jié)

讀到這里，開頭的問題的答案自然得出。

特將緩存使用注意事項(xiàng)說明如下：

• 將聚合操作與“常規(guī)”查詢處理分開。

原因：避免聚合隨著用戶的翻頁（查詢）重新計(jì)算。

• 區(qū)分 filter 過濾器 和 match 匹配子句。

第一：通用 filter 過濾器具有很高的可緩存性，并且計(jì)算迅速；

第二：基于評(píng)分的 query 是相比 filter 更為昂貴的查詢，并且難以緩存。

• 在評(píng)分之前，使用可重復(fù)使用的過濾器（filters）來縮小結(jié)果集的范圍。使用scripted fields進(jìn)行評(píng)分，但不要使用過濾器。

• Filters 過濾器或多或少地按順序執(zhí)行。ES 內(nèi)部進(jìn)行了一些查詢重寫，但通常將廉價(jià)的過濾器（執(zhí)行快）放在首位，將較昂貴的過濾器（執(zhí)行慢）放在第二位。

• 如果必須按時(shí)間戳過濾，請使用粗粒度，以確保查詢值改動(dòng)小。

參考：

1、官方文檔

2、https://opster.com/elasticsearch-glossary/elasticsearch-cache/

3、https://opensourceconnections.com

推薦閱讀：