elasticsearch 查詢的響應需要占用 cpu、記憶體資源,在複雜業務場景,會出現慢查詢,需要花費大量的時間。
如何破局呢?增加集群硬體配置會有高昂硬體開銷。還有沒有其他方案呢?這時候會想到:快取。
elasticsearch 有哪些快取,不同快取的應用場景是什麼呢?本文給出答案。
以上問題都是實戰業務場景的問題。
filter 過濾查詢的結果快取在節點查詢快取中,以便快速查詢。
每個節點都有乙個所有分片共享的查詢快取。快取使用 lru ( least recently used 快取淘汰策略)策略,當快取已滿時,優先清理最近最少使用的查詢結果,以騰出空間存放新結果資料。
使用者無法檢視節點查詢快取的內容。
3.1.1 節點查詢快取適用場景
3.1.2 節點查詢快取記憶體上限
預設情況下,節點查詢快取最多可容納10000個查詢,最多佔總堆空間的10%。
為了確定查詢是否符合快取條件,elasticsearch 維護查詢歷史記錄以跟蹤事件的發生。
如果乙個段至少包含 10000 個文件,並且該段具有超過乙個分片的文件總數的 3% 的文件數,則按每個段進行快取。由於快取是按段劃分的,因此合併段可使快取的查詢無效。
3.1.3 節點查詢快取配置
說一下靜態配置(static)和 動態配置 (dynamic)配置的本質區別:
配置1:indices.queries.cache.size
配置2:index.queries.cache.enabled
put my_index_0003
}
3.2 分片請求快取(shard request cache)
當對乙個索引或多個索引執行搜尋請求時,每個涉及的分片都會在本地執行搜尋並將其本地結果返回到協調節點,協調節點將這些分片級結果合併為乙個「全域性」結果集。
分片級請求快取在每個分片上快取本地結果,這使得頻繁使用的搜尋請求幾乎立即返回結果。分片請求快取非常適合日誌用例場景,在這種情況下,資料不會在舊索引上更新,並且可以將常規聚合保留在快取記憶體中以供重用。
預設情況下:
3.2.1 分片請求快取失效
重新整理間隔(refresh_interval)越長,快取的條目將保持有效的時間越長。如果快取已滿,將驅逐最近最少使用的快取。
可以使用 clear_cache api手動使快取過期,舉例如下:
post /kimchy,elasticsearch/_cache/clear?request=true
3.2.2 啟停分片請求快取put my_index
}
put /my_index/_settings
如下的設定會覆蓋索引級別的快取設定。
get /my_index/_search?request_cache=true}}
}
注意:
第一:如果你的查詢使用結果有不確定的指令碼(例如,使用隨機函式或引用當前時間),則應將request_cache標誌設定為false以禁用該請求的快取。
第二:即使在索引設定中啟用了請求快取,也不會快取大小大於0(size > 0)的請求。要快取這些請求,您將需要使用 query-string 引數(詳見官方文件)。
3.2.3 快取設定
快取是在節點級別進行管理的,預設最大大小為堆的1%。可以使用以下命令在config / elasticsearch.yml 檔案中進行更改:
indices.requests.cache.size: 2%
此外,您可以使用 index.requests.cache.expire 設定為快取的結果指定ttl,但是沒有理由這樣做(提供此設定僅出於完整性考慮)。
請記住,重新整理索引後(refreshed),舊的結果將自動失效。
3.2.4 快取分片請求監控
get /_stats/request_cache?human
get /_nodes/stats/indices/request_cache?human
field data 快取包含 field data 和 global ordinals,它們均用於支援某些字段型別上的聚合。由於這些都是堆上的資料結構,因此監視快取的使用非常重要。
global ordinals 可以簡單理解為:預熱全域性序號,全域性序號可以理解為:一種資料結構,使用者 keyword 欄位的 terms 聚合等用途。
field data 快取的構建成本很高,因此預設行為是將快取載入到記憶體中。預設的快取大小是無限的,這將導致快取高速增長直到達到field data斷路器設定的限制。
如果設定了 field data 快取大小限制,同樣的,快取將開始清除快取中最新最少更新的資料。此設定可以自動避開斷路器限制,但需要根據需要重建快取。
如果達到 field data 斷路器限制,elasticsearch 底層將阻止進一步增加快取大小的請求。在這種情況下,你應該手動清除快取。
這裡要擴充套件兩個field data 斷路器 配置:
引數1:indices.breaker.fielddata.limit
引數2:indices.breaker.fielddata.overhead
3.3.1 field data 快取設定
2)固定值,如:12 gb。
3.3.2 field data 快取監控
以下兩種方法可用於監控:field data 快取及 斷路器使用情況。
get /_nodes/stats
get /_cat/fielddata
全域性檢視快取方法
get _cat/nodes?v&h=id,querycachememory,querycacheevictions,requestcachememory,requestcachehitcount,requestcachemisscount,flushtotal,flushtotaltime
post /twitter/_cache/clear?query=true
post /twitter/_cache/clear?request=true
post /twitter/_cache/clear?fielddata=true
post /kimchy,elasticsearch/_cache/clear
post /_cache/clear
快取型別
快取內容
節點請求快取
快取可維護在 filter 上下文中使用的查詢結果。
分片請求快取
快取 size = 0 時頻繁使用的查詢的結果,尤其是聚合的結果。
字段請求快取 (field data)
用於排序和支援某些字段型別上的聚合。
讀到這裡,開頭的問題的答案自然得出。
特將快取使用注意事項說明如下:
原因:避免聚合隨著使用者的翻頁(查詢)重新計算。
第一:通用 filter 過濾器具有很高的可快取性,並且計算迅速;
第二:基於評分的 query 是相比 filter 更為昂貴的查詢,並且難以快取。
參考:1、官方文件
2、3、
推薦閱讀:
重磅 | 死磕 elasticsearch 方**認知清單(2023年國慶更新版)乾貨 | 吃透elasticsearch 堆記憶體
你的 elasticsearch 難題,官方文件早就有了答案......
潛心一技、做到極致!——elastic認證工程師之路
更短時間更快習得更多乾貨!
中國近50%+elastic 認證工程師出自於此!
和全球近900+elastic 愛好者一起精進 elasticsearch!
CronJob刪除ElasticSearch日誌
目前在k8s平台內,通過pod掛載hostpath將程式形成的日誌檔案傳輸儲存到宿主機指定目錄上,然後fluentd根據指定目錄去蒐集日誌檔案 json格式 然後通過呼叫elasticsearch 以下簡稱es 的api將日誌儲存到es中,那麼問題來了,日誌檔案大了怎麼清理?1.每個工作節點上的日誌...
windows下的elasticSearch安裝
es官網 進入bin目錄,雙擊elasticsearch.bat 訪問http localhost 9200可訪問 新增ik分詞器 解壓ik分詞器包,放到es安裝目錄的plugins中的analysis ik 資料夾中 新建analysis ik 資料夾 再次啟動elasticsearch.bat,...
檢視快取大小和清除快取
public class cleandatautils return getformatsize cachesize 獲取檔案 sdcard android data 你的應用的包名 files 目錄,一般放一些長時間儲存的資料 sdcard android data 你的應用包名 cache 目錄...