ElasticSearch global ordinals&execution_hint

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" 
             }
         }
    }}

4、reference

https://www.elastic.co/cn/blog/improving-the-performance-of-high-cardinality-terms-aggregations-in-elasticsearch

https://elasticsearch.cn/question/1008