indices.fielddata.cache.size 控制了给 fielddata 分配的堆空间大小。 当你发起查询时，如果这些字符串之前没有被加载过，analyzed字符串的聚合将会被加载到 fielddata。如果结果中 fielddata 大小超过了指定 大小(size) ，其他的值将会被回收从而获得空间。

默认情况下，设置都是 不限制(unbounded) ，Elasticsearch 永远都不会从 fielddata 中回收数据。

这个默认设置是刻意选择的：fielddata 不是临时缓存。它是驻留内存里的数据结构，必须可以快速执行访问，而且构建它的代价十分高昂。如果每个请求都重载数据，性能会十分糟糕。

一个有界的大小会强制数据结构淘汰数据。我们会看何时应该设置这个值，但请首先阅读以下警告：

设想我们正在对日志进行索引，每天使用一个新的索引。通常我们只对过去一两天的数据感兴趣，尽管我们会保留老的索引，但我们很少需要查询它们。不过如果采用默认设置，旧索引的 fielddata 永远不会从缓存中回收！ fieldata 会保持增长直到 fielddata 发生断熔（请参阅 断路器），这样我们就无法载入更多的 fielddata。

这个时候，我们被困在了死胡同。但我们仍然可以访问旧索引中的 fielddata，也无法加载任何新的值。相反，我们应该淘汰旧的数据，并为新值获得更多空间。

为了防止发生这样的事情，可以通过在 config/elasticsearch.yml 文件中增加配置为 fielddata 设置一个上限：

indices.fielddata.cache.size:  20% 

有了这个设置，最近最少使用(LRU: least recently used)的 fielddata 会被淘汰, 为新数据腾出空间。

无论是紧盯着 fielddata 的内存使用情况， 还是看有无数据被淘汰都十分重要。高淘汰数量可以预示严重的资源问题以及性能不佳的原因。

Fielddata 的使用可以被监控：

GET /_nodes/stats/indices/fielddata?level=indices&fields=*

使用设置 ?fields=* ，可以将内存使用分配到每个字段。

精明的读者可能已经发现 fielddata 大小设置的一个问题。fielddata 大小是在数据加载 之后 检查的。 如果一个查询试图加载比可用内存更多的信息到 fielddata 中会发生什么？答案很丑陋：你会收到 内存溢出异常(OutOfMemoryException) 。

Elasticsearch 包括一个 fielddata 断熔器 ，这个设计就是为了处理上述情况。 断熔器通过内部检查（字段的类型、基数、大小等等）来估算一个查询需要的内存。它然后检查要求加载的 fielddata 是否会导致 fielddata 的总量超过堆的配置比例。

如果估算查询的大小超出限制，就会 触发 断路器，查询会被中止并返回异常。这都发生在数据加载 之前 ，也就意味着不会引起 内存溢出异常(OutOfMemoryException) 。

断路器的限制可以在文件 config/elasticsearch.yml 中指定，可以动态更新一个正在运行的集群：

PUT /_cluster/settings
{
  "persistent" : {
    "indices.breaker.fielddata.limit" : "40%" 
  }
}

最好为断路器设置一个相对保守点的值。 记住 fielddata 需要与 request 断路器共享堆内存、索引缓冲内存和过滤器缓存。Lucene 的数据被用来构造索引，以及各种其他临时的数据结构。 正因如此，它默认值非常保守，只有 60% 。过于乐观的设置可能会引起潜在的 内存溢出(OOM) 异常，这会使整个节点宕掉。

另一方面，过度保守的值只会返回查询异常，应用程序可以对异常做相应处理。异常比服务器崩溃要好。这些异常应该也能促进我们对查询进行重新评估：为什么单个查询需要超过堆内存的 60% 之多？

值得注意的是：断路器是根据总 堆内存大小 估算查询大小的，而 非 根据实际堆内存的使用情况。 这是由于各种技术原因造成的（例如，堆可能看上去是满的但实际上可能只是在等待垃圾回收，这使我们难以进行合理的估算）。但作为终端用户，这意味着设置需要保守，因为它是与 总堆内存 比较的，而 不是 可用堆内存。