1、global ordinals
（1）what's this?
当我们使用doc values或者fielddata存储时，在磁盘中存储的值不是真正的字段值，而是一个字典值(ordinal)。当我们进行聚合查询的时候，es会把这个字典值跟真正字段值的映射字典加载到内存中，并对结果集做映射，转化为真正的值。这份映射关系是shard级别的，为这个shard里面是所有segment服务，这也是global的体现。
（2）detail
- 字典关系是lazy init的，只有第一次使用的时候才会加载到内存中。在es的内存表现中提现成fielddata，这也是全keyword的index为什么也会有fielddata使用的原因。只会加载命中的segment的字典不会加载全部。
- 字典关系在shard被触发refresh以后就会失效。下次使用的时候需要再重新构建。所以可以提高refresh_interval的值，减少fresh频率提高字典的生存时间。
2、eager_global_ordinals
（1）what's this？
当在global ordinals的时候，refresh以后下一次查询字典就需要重新构建，在追求查询的场景下很影响查询性能。可以使用eager_global_ordinals，即在每次refresh以后即可更新字典，字典常驻内存，减少了查询的时候构建字典的耗时。
（2）使用场景
因为这份字典需要常驻内存，并且每次refresh以后就会重构，所以增大了内存以及cpu的消耗。推荐在低写高查、数据量不大的index中使用。
（3）使用
PUT my_index/_mapping
{
"properties": {
"tags": {
"type": "keyword",
"eager_global_ordinals": true
}
}}
3、execution_hint
（1）what' this?
上面介绍了global ordinal的使用场景，是doc_values以及fileddata的默认数据架构。除了这种模式，还可以选择map模式。即不再使用字典而是直接把值加载到内存中计算，减去了构建字典的耗时。当查询的结果集很小的情况下，可以使用map的模式不去构建字典。使用map还是global_ordinals的取决于构建字典的开销与加载原始字典的开销。当结果集大到一定程序，map的内存开销的代价可能抵消了构建字典的开销。
（2）how to use?
GET /_search{
"aggs" : {
"tags" : {
"terms" : {
"field" : "tags",
"execution_hint": "map"
}
}
}}
