假设现在有以下的一个搜索：
对于搜索，使用倒排索引，无可争议。但是对于聚合，使用倒排索引呢？
我们知道搜索时term到document的映射，聚合或者排序是从document到term的映射。所以要聚合，我们就得找到这个10000条document的所有的term。
即从头开始一直到倒排索引结束，所有的term都有可能是处于你要查找的文档中，需要从头到尾遍历一次，举个例子：
"desc": "蝶泉乐器厂家特价直销10级全新正品163标准古筝初学者14款可选",
那么蝶泉, 乐器厂, 厂家，直销, 黑,中国等term都有可能包含在这个文档中，所以需要整个遍历一次。
如果假设有100万个document,那么它包含的term可能上千万，那么对于性能来说，不是很好的。
为什么正排索引就合适了？
我们知道正排索引是document到term的映射。我们构建正派索引类似于二维表中的每一列，即所谓的列式存储。比如：
Doc2: 雅马哈,电钢琴,黑,法国,智能,数码钢琴,数码,钢琴
如果这里有100万条document，所以这种结构，我们一次查找最多遍历1000000次，而不是遍历千万次，所以性能提升很多
倒排索引的优势在于查找包含某个项的文档，即通过Term查找对应的docid。
如此能够快速定位包含brown的文档为doc1和doc2。
但是对于从另外一个方向的相反操作并不高效，即根据docid找到该文档的指定字段（Term2）的值是什么。但是聚合、排序和明细查询等时候需要这种的访问模式。
声明遍历索引是不可取。这很慢而且难以扩展：随着词项和文档的数量增加，执行时间也会增加。为了能够解决上述问题，我们使用了Doc values，通过转置两者间的关系来解决这个问题。
搜索和聚合是相互紧密关联的。搜索使用倒排索引查找文档，聚合操作收集和聚合 doc values 里的数据。
1、DocValues是在索引时与倒排索引同时生成的，并且是不可变的。与倒排一样，保存在lucene文件中（序列化到磁盘）。
lucene文件操作依赖于操作系统的缓存来管理，而不是在 JVM 堆栈里驻留数据。 这个特点决定了在使用es时候要分配足够内存给os，保证文件处理性能，详细设置可以参照 生产环境elasticsearch的配置建议
现代 CPU 的处理速度要比磁盘快几个数量级， 这意味着减少必须从磁盘读取的数据量总是有益的，尽管需要额外的 CPU 运算来进行解压。
DocValues使用了很多压缩技巧。它会按依次检测以下压缩模式:
- 如果所有的数值各不相同（或缺失），设置一个标记并记录这些值
- 如果这些值小于 256，将使用一个简单的编码表
- 如果这些值大于256，检测是否存在一个最大公约数
- 如果没有存在最大公约数，从最小的数值开始，统一计算偏移量进行编码
这些压缩模式不是传统的通用的压缩方式，比如 DEFLATE 或是 LZ4。 因为列式存储的结构是严格且良好定义的，我们可以通过使用专门的模式来达到比通用压缩算法（如 LZ4 ）更高的压缩效果。
，字符类型通过借助顺序表（ordinal table）进行类似编码的。字符类型是去重之后存放到顺序表的，通过分配一个 ID，然后这些 ID 和数值类型的文档值一样使用。 也就是说，字符类型和数值类型一样拥有相同的压缩特性。
顺序表本身也有很多压缩技巧，比如固定长度、变长或是前缀字符编码等等。
那想要怎么达到我们想要的结果呢？fielddata。
只要我们针对需要分词的字段设置了fielddata，就可以使用该字段进行聚合，排序等。我们设置为true之后，在索引期间，就会以列式存储在内存中。为什么存在于内存呢，因为按照term聚合，需要执行更加复杂的算法和操作，如果基于磁盘或者 OS 缓存，性能会比较差。
doc values 不生成分析的字符串，然而，这些字段仍然可以使用聚合，是因为使用了fielddata 的数据结构。与 doc values 不同，fielddata 构建和管理 100% 在内存中，常驻于 JVM 内存堆。fielddata 是 所有 字段的默认设置。
1. Fielddata 是延迟加载的。如果你从来没有聚合一个分析字符串，就不会加载 fielddata 到内存中，是在查询时候构建的。
3. fielddata 会加载索引中（针对该特定字段的） 所有的文档，而不管查询是否命中。逻辑是这样：如果查询会访问文档 X、Y 和 Z，那很有可能会在下一个查询中访问其他文档。
也可以使用如下命令进行监控。
最后，如果一次性加载字段直接超过内存值会发生什么？挂掉？所以es为了防止这种情况，采用了circuit breaker（熔断机制）。
它通过内部检查（字段的类型、基数、大小等等）来估算一个查询需要的内存。它然后检查要求加载的 fielddata 是否会导致 fielddata 的总量超过堆的配置比例。如果估算查询大小超出限制，就会触发熔断，查询会被中止并返回异常。
通过设置可以只加载部分fielddata来节省内存。
加载fielddata默认是延迟加载 。 当 Elasticsearch 第一次查询某个字段时，它将会完整加载这个字段所有 Segment中的倒排索引到内存中，以便于以后的查询能够获取更好的性能。
对于小索引段来说，这个过程的需要的时间可以忽略。但如果索引很大几个GB，这个过程可能会要数秒。对于 已经习惯亚秒响应的用户很难会接受停顿数秒卡顿。
有三种方式可以解决这个延时高峰：
- 预加载 fielddata，设置提前加载。
- 预加载全局序号。一种减少内存占用的加载优化方式，类似于一种全局字典（存储string字段和其对应的全局唯一int值），这样只加载int值，然后查找字典中的对应的string字段。
一项用于减少string类型的fielddata占用内存的技术叫做序数。
假设每一个文档都有一个有限值的字段，比如性别：男 女 男孩 女孩 人妖 5中类型的字段
有很多重复值的情况，会进行global ordinal标记，比如
这样的好处就是减少重复字符串的大小，减少内存的消耗
注：一方面，doc_values比fielddata慢一点，大概10-25%（参考其他资料），但是具有更好的稳定性。另一方面，doc_values写入磁盘文件中，OS Cache先进行缓存，以提升访问doc value正排索引的性能，如果OS Cache内存大小不足够放得下整个正排索引，doc value，就会将doc value的数据写入磁盘文件中
