转自：http://blog.csdn.net/chennanymy/article/details/52504386?locationNum=3
Filter Cache（Query Cache）：
https://www.elastic.co/guide/en/elasticsearch/reference/1.6/index-modules-cache.html
Query Cache也称为Filter Cache，顾名思义它的作用就是对一个查询中包含的过滤器执行结果进行缓存。
比如我们常用的term，terms，range过滤器都会在满足某种条件后被缓存，注意，这里的bool过滤器是不会被缓存的，但bool过滤器包含的子query clause会被缓存，我们可以用下面的命令来查询Query Cache的情况。
Request Cache（Shard query cache）
https://www.elastic.co/guide/en/elasticsearch/reference/1.6/index-modules-shard-query-cache.html
当一个查询发送到ES集群的某个节点上时，这个节点会把该查询扩散到其他节点并在相应分片上执行，我们姑且把在分片上执行的结果叫“本地结果集“，这些本地结果集最终会汇集到最初请求到达的那个协调节点，这些“分片级”的结果集会合并成“全局”结果集返回给调用端。
Request Cache模块就是为了缓存这些“分片级”的本地结果集，但是目前只会缓存查询中参数size=0的请求，所以就不会缓存hits 而是缓存 hits.total，aggregations和suggestions
Fielddata
https://www.elastic.co/guide/en/elasticsearch/reference/1.6/index-modules-fielddata.html
一谈到Fielddata我们不得不提到doc_values，这两者的作用都是一样：能够让我们在inverted index（倒排索引）的基础之上做aggregation、sort或者在查询中通过script访问doc属性，这里我们不讨论doc_values，主要讲下Fielddata，doc values相关知识请戳：http://blog.csdn.net/chennanymy/article/details/52555055
想必大家都知道倒排索引这种结构，如果我们仅仅依靠倒排是很难在查询中做到排序和统计的，因为它并不是像关系型数据库那样采用“列式存储”，而是基于一个“词”到“文档”的倒排。
Fielddata是专门针对分词的字段在query-time（查询期间）的数据结构的缓存。当我们第一次在一个分词的字段上执行聚合、排序或通过脚本访问的时候就会触发该字段Fielddata Cache的加载，这种缓存是“segment”级别的，当有新的segment打开时旧的缓存不会重新加载，而是直接把新的segement对应的Fielddata Cache加载到内存。
加载Fielddata Cache是一个非常昂贵的操作，一旦Fielddata被加载到内存，那么在该Fielddata Cache对应的Segement生命周期范围内都会驻留在内存中。也就是说当段合并时会触发合并后更大段的Fielddata Cache加载。
Fielddata会消耗大部分的JVM堆内存，特别是当加载“高基数”的分词字段时（那些分词后存在大量不同词的字段），针对这种字段的聚合排序其实是非常没有意义的，我们更多的要去考虑是否能用not_analyzed代替（这样就可以使用doc_values实现聚合、排序）。
