1.介绍

FielddataCache是什么，开始做搜索就用ES5.0以后的朋友对这个Cache应该没什么概念了，因为早期版本，Lucene没有doc values这样的数据结构。 做数据聚合和排序的时候，需要将倒排索引的数据读取出来，重新组织成一个数组缓存，也就是从倒排索引中生成出来的要自己维护这段Cache， 之后才能够高效的做排序和聚合计算。后来ES中有了FielddataCache，但转换工作很耗资源，转换好的列表就会被缓存到fielddata cache，提升速度。 但是因为这个cache是在heap内部的，海量数据聚合的时候，生成的这些fielddata可能heap都放不下，很容易引起性能问题，甚至JVM OOM(还没有熔断保护的时候)。

2.作用

默认Elasticsearch2.0 开始，在非 text 字段开启 doc_values，基于 doc_values 做排序和聚合，可以减少对FielddataCache的依赖，减少内存消耗，减少节点 OOM 的概率，由于doc_values的特性性能上也不会有多少损失，doc_value是一种正向索引结构以顺序预读的方式进行获取，所以随机获取就很慢了。

Elasticsearch（后面简称ES）除了强大的搜索功能外，还可以支持排序，聚合之类的操作。搜索需要用到倒排索引，而排序和聚合则需要使用 “正排索引”。说白了就是一句话，倒排索引的优势在于查找包含某个项的文档，而反过来确定哪些项在单个文档里并不高效。

doc_values和fielddata就是用来给文档建立正排索引的。他俩一个很显著的区别是，前者的工作地盘主要在磁盘，而后者的工作地盘在内存。

5.0 开始，text 字段默认关闭了 Fielddata 功能， Fielddata Cache 应当只用于 global ordinals。

FielddataCache失效和Node QueryCache 失效机制相同，当 segment 被合并后，才会失效。

Fielddata Cache大家做了解吧，使用它的也非常的少了，基本可以用doc_value代替了，doc_value使用不需要全部载入内存

着ES版本的升级，对于doc_values的优化越来越好，索引的速度已经很接近fielddata了，而且我们知道硬盘的访问速度也是越来越快（比如SSD）。所以 doc_values 现在可以满足大部分场景，也是ES官方重点维护的对象。

所以我想说的是，doc values相比field data还是有很多优势的。所以 ES2.x 之后，支持聚合的字段属性默认都使用doc_values，而不是fielddata。

3.配置

indices.breaker.fielddata.limit: 60% (默认heap的60%) ，如果设置了indices.fielddata.cache.size，当达到size时，cache会剔除旧的fielddata。注意，indices.breaker.fielddata.limit 必须大于 indices.fielddata.cache.size，否则只会触发fielddata circuit breaker，而不会剔除旧的fielddata。

排查：

curl -X GET "http://127.0.0.1:9200/_stats/fielddata?pretty&human"