一、terms聚合统计，initialise 阶段的耗时，有助于我们调整对应 aggs 的 execution_hint 参数选择？
map：过滤之后，实际纳入统计的doc数量特别少，但是字段总的term数量超级多
适用场景：
过滤完之后，纳入统计的doc很少
不适用场景：
过滤完之后，纳入统计的doc很多
global_ordinals：过滤之后，实际纳入统计的doc数量特别多，但是字段总的term数量很少
适用场景：
过滤完之后，纳入统计的doc很多，但是terms聚合字段，总的token很少（即该字段数据不离散）
不适用场景：
terms聚合字段，总的token超级多
Terms aggregation默认的计算方式并非直观感觉上的先查询，然后在查询结果上直接做聚合。
ES假定用户需要聚合的数据集是海量的，如果将查询结果全部读取回来放到内存里计算，内存消耗会非常大。因此ES利用了一种叫做global ordinals的数据结构来对聚合的字段来做bucket分配，这个ordinals用有序的数值来代表字段里唯一的一个字符串，因此为每个ordinals值分配一个bucket就等同于为每个唯一的token分配了bucket。 之后遍历查询结果的时候，可以将结果映射到各个bucket里，就可以很快的统计出每个bucket里的文档数了。
这种计算方式主要开销在构建global ordinals和分配bucket上，如果索引包含的原始文档非常多，查询结果包含的文档也很多，那么默认的这种计算方式是内存消耗最小，速度最快的。
如果指定execution_hint:map则会更改聚合执行的方式，这种方式不需要构造global ordinals，而是直接将查询结果拿回来在内存里构造一个map来计算，因此在查询结果集很小的情况下会显著的比global ordinals快。
要注意的是这中间有一个平衡点，当结果集大到一定程度的时候，map的内存开销带来的代价可能就抵消了构造global ordinals的开销，从而比global ordinals更慢，所以需要根据实际情况测试对比一下才能找好平衡点。
2、terms聚合统计，collect 阶段的耗时，有助于我们调整对应 aggs 的 collect_mode 参数选择。目前 Elasticsearch 支持 breadth_first 和 depth_first 两种方式
terms 桶基于我们的数据动态构建桶；它并不知道到底生成了多少桶。 大多数时候对单个字段的聚合查询还是非常快的， 但是当需要同时聚合多个字段时，就可能会产生大量的分组，最终结果就是占用 es 大量内存，从而导致 OOM 的情况发生。
depth_first:多层聚合时，总的桶数量是可以预测，少量的，但是纳入统计doc数量非常多。
适用场景：
F1和F2字段总的token不是很多，这样过滤之后纳入统计的doc总共需要建的桶是少量的
不适用场景：
F1和F2字段的token很多（数据非常离散）
breadth_first:多层聚合时，总的桶的数量特别多，但是最终纳入第一层统计的doc数量是非常少的。
适用场景：
F1和F2字段总的term不是很多，但是纳入前n（由size参数确定）个桶统计doc很少
不适用场景：
纳入前n个桶统计的doc很多