深入聚合数据分析之text field聚合以及fielddata原理

　  对分词的field进行aggregation异常

GET /user/_search
{
  "size":0,
  "aggs": {
    "group_by_name": {
      "terms": {
        "field":"username"
      }
    }
  }
}

　　异常信息

 "type": "illegal_argument_exception",
 "reason": "Fielddata is disabled on text fields by default. Set fielddata=true on [username] in order to load fielddata in memory by uninverting the inverted index. Note that this can however use significant memory. Alternatively use a keyword field instead."

　　给分词的field，设置fielddata=true，可执行

PUT /user
{
  "mappings": {
      "properties": {
        "username": {
          "type": "text",
          "fielddata": true
        }
      }
    }
}

　　使用field.keyword，对分词的field进行聚合，可执行

GET /forum/_search
{
  "size":0,
  "aggs": {
    "group_by_name": {
      "terms": {
        "field":"author_first_name.keyword"
      }
    }
  }
}

　　分词field+fielddata的工作原理

　　doc value --> 不分词的所有field，可以执行聚合操作 --> 如果某个field不分词，那么在index-time，就会自动生成doc value --> 针对这些不分词的field执行聚合操作的时候，自动就会用doc value来执行。

　　分词field，是没有doc value的。。。在index-time，如果某个field是分词的，那么是不会给它建立doc value正排索引的，因为分词后，占用的空间过于大，所以默认是不支持分词field进行聚合的

　　分词field默认没有doc value，所以直接对分词field执行聚合操作，是会报错的

　　对于分词field，必须打开和使用fielddata，完全存在于纯内存中。。。结构和doc value类似。。。如果是ngram或者是大量term，那么必将占用大量的内存。。。

　　如果一定要对分词的field执行聚合，那么必须将fielddata=true，然后es就会在执行聚合操作的时候，现场将field对应的数据，建立一份fielddata正排索引，fielddata正排索引的结构跟doc value是类似的，但是只会将fielddata正排索引加载到内存中来，然后基于内存中的fielddata正排索引执行分词field的聚合操作

　　如果直接对分词field执行聚合，报错，提示让开启fielddata=true，告诉我们，会将fielddata uninverted index（正排索引），加载到内存，会耗费内存空间

　　为什么fielddata必须在内存？分词的字符串，需要按照term进行聚合，需要执行更加复杂的算法和操作，如果基于磁盘和os cache，那么性能会很差