23、Elasticsearch-fielddata內(nei)存使用陡增解決方案
利用searchAfter分頁方式代替From-Size查詢或Scroll滾動查詢，解決From-Size查詢存在的深度翻頁問題與Scroll滾動查詢存在數據量大響應慢的問題。由于searchAfter分頁需要保證排序聚合唯一，當使用_id 字段進行排序聚合時，可能會導致fielddata內存使用指標陡增，從而導致集群的內存使用率上升，一旦內存使用率超過90%即會對集群的性能產生影響，進而拋出FielddataMemoryUsedBytes內存不足異常。
一、異常(chang)：
java.util.concurrent.ExecutionException: CircuitBreakingException[[fielddata] Data too large, data for [_id] would be [xxxx/x.xgb], which is larger than the limit of [xxxx/x.xgb]]
二、原因(yin)：
由于復雜的(de)查詢涉及到對(dui) _id的(de)某(mou)種內存密集型處理時，會將大量的(de) _id 相關數(shu)(shu)據(ju)加載(zai)到內存中(zhong)的(de)fielddata結(jie)(jie)構里，以便可以快速執行訪問(wen)，但fielddata不(bu)是(shi)臨時緩(huan)存，它是(shi)駐留在內存里的(de)數(shu)(shu)據(ju)結(jie)(jie)構，垃圾回收是(shi)不(bu)會回收這(zhe)部分緩(huan)存的(de)，因此當數(shu)(shu)據(ju)量多的(de)時候（多個索引），其大小突破會系統設(she)定的(de)閾值。
三(san)、處(chu)理方案：
1、定位什么字段導致的fielddata突增：
# 顯示每個節點(dian)字段所(suo)占(zhan)的堆空(kong)間 并(bing)按照所(suo)占(zhan)空(kong)間降序排列(lie) GET _cat/fielddata?v&s=size:desc # indices:查看集群(qun)中(zhong)所(suo)有index的(de)詳細信息 GET _cat/indices?v&h=index,fielddata.memory_size&s=fielddata.memory_size:desc
2、修改排序聚合方案：
在達(da)到(dao)報(bao)警水位線之前將“對text類型字(zi)段、_id 字(zi)段進行(xing)(xing)排序(xu)聚合”的(de)業(ye)務進行(xing)(xing)修改或使用其它方案替代，保(bao)證集群(qun)的(de)穩(wen)定性(xing)
3、清理指定索引fielddata緩存：
可能導致該索引的查詢變慢，引起業務抖動，需提前和客戶說明風險：
#單個(ge)： POST /索引名/_cache/clear?fielddata=true #全量： POST /_cache/clear?fielddata=true
