es 吗 查询必须有sort_Es中使用sort，aggs的时候，出现fielddata超过heap问题

It is best to configure the circuit breaker with a relatively conservative value. Remember that fielddata needs to share the heap with the request circuit breaker, the indexing memory buffer, the filter cache, Lucene data structures for open indices, and various other transient data structures. For this reason, it defaults to a fairly conservative 60%. Overly optimistic settings can cause potential OOM exceptions, which will take down an entire node.

On the other hand, an overly conservative value will simply return a query exception that can be handled by your application. An exception is better than a crash. These exceptions should also encourage you to reassess your query: whydoesa single query need more than 60% of the heap?

这意思，就是默认可以，如果出现问题，我们想到的不应该是调整这个值，而是检查下我们的查询或者其他设置，为何导致这么大的问题。

https://www.elastic.co/guide/en/elasticsearch/guide/current/_limiting_memory_usage.html#circuit-breaker

In-memory模式中，fielddata受到heap内存大小限制，虽然这个问题可以通过集群的横向扩容解决——可需要经常增加节点——而且即使加了，你还是会发现在其他一些资源利用不充分的节点上，在排序和聚合查询的时候仍然会消耗你大量的heap空间。

fielddata字段数据默认下，会频繁的在内存当中加载。但这不是唯一的方法，在索引数据时，fielddata字段数据还可以被写在磁盘中，这种方式可以提供和加载到内存中的一样的功能，而不会占用heap的内存空间。

Docvalues是在1.0.0之后加入到elasticsearch中的。通过基准测试与性能分析，各类的瓶颈——无论是elasticsearch还是lucene，都已经被发现并且已经被移除了。但是直到现在还是远远慢于字段数据放内存的in-memory方式。

1、存放在磁盘代替存放内存，可以允许你的集群负载大量fielddata字段数据而不会超量使用内存。这样，你的heap space就可以设置小一些了，对垃圾回收的速度有所帮助，理所当然的，节点也会更稳定些。

2、DocValues是索引时建立的，而不是搜索的时候。当通过非反向的反向索引搜索时候，in-memort方式，内存中的字段数据必须被频繁的读写，而doc vales 是预先建立的，并能更快的初始化。

像trade-off这种索引量大的搜索，访问fielddat