23、Elasticsearch-fielddata内存使用陡增解决方案

利用searchAfter分页方式代替From-Size查询或Scroll滚动查询，解决From-Size查询存在的深度翻页问题与Scroll滚动查询存在数据量大响应慢的问题。由于searchAfter分页需要保证排序聚合唯一，当使用_id 字段进行排序聚合时，可能会导致fielddata内存使用指标陡增，从而导致集群的内存使用率上升，一旦内存使用率超过90%即会对集群的性能产生影响，进而抛出FielddataMemoryUsedBytes内存不足异常。
 

一、异常：

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]]

二、原因：

由于复杂的查询涉及到对 _id的某种内存密集型处理时，会将大量的 _id 相关数据加载到内存中的fielddata结构里，以便可以快速执行访问，但fielddata不是临时缓存，它是驻留在内存里的数据结构，垃圾回收是不会回收这部分缓存的，因此当数据量多的时候（多个索引），其大小突破会系统设定的阈值。

三、处理方案：

1、定位什么字段导致的fielddata突增：

# 显示每个节点字段所占的堆空间 并按照所占空间降序排列
GET _cat/fielddata?v&s=size:desc
# indices:查看集群中所有index的详细信息
GET _cat/indices?v&h=index,fielddata.memory_size&s=fielddata.memory_size:desc

2、修改排序聚合方案：

在达到报警水位线之前将“对text类型字段、_id 字段进行排序聚合”的业务进行修改或使用其它方案替代，保证集群的稳定性

3、清理指定索引fielddata缓存：

可能导致该索引的查询变慢，引起业务抖动，需提前和客户说明风险：

#单个： 
POST /索引名/_cache/clear?fielddata=true
#全量：
POST /_cache/clear?fielddata=true