ElasticSearch中doc values和fielddata

一 为什么聚合排序不适合使用倒排序索引

假设现在有以下的一个搜索：

POST /ecommerce/music/_search

{

   "size":0,

   "query":{

       "match":{

           "desc":"吉他"

        }

    },

   "aggs":{

       "brands":{

           "terms":{"field":"brand.keyword"}

        }

    }

}

对于搜索，使用倒排索引，无可争议。但是对于聚合，使用倒排索引呢？

我们知道搜索时term到document的映射，聚合或者排序是从document到term的映射。所以要聚合，我们就得找到这个10000条document的所有的term。

即从头开始一直到倒排索引结束，所有的term都有可能是处于你要查找的文档中，需要从头到尾遍历一次，举个例子：

"brand": "蝶泉",

"desc": "蝶泉乐器厂家特价直销10级全新正品163标准古筝初学者14款可选",

"color": "黑",

"origin": "中国",

"sales": 648,

"price": 558,

"review": 5708,

"c_date": "2015-11-09"

那么蝶泉, 乐器厂, 厂家，直销, 黑,中国等term都有可能包含在这个文档中，所以需要整个遍历一次。

如果假设有100万个document,那么它包含的term可能上千万，那么对于性能来说，不是很好的。

 

为什么正排索引就合适了？

我们知道正排索引是document到term的映射。我们构建正派索引类似于二维表中的每一列，即所谓的列式存储。比如：

Doc1: 蝶泉, 乐器厂, 厂家，直销, 黑,中国

Doc2: 雅马哈,电钢琴,黑,法国,智能,数码钢琴,数码,钢琴

如果这里有100万条document，所以这种结构，我们一次查找最多遍历1000000次，而不是遍历千万次，所以性能提升很多

 

二 fielddata

我们知道，倒排文档来做聚合，排序是不合适的，那么ES引入fielddata的数据结构，其实根据倒排索引反向出来的一个正排索引，即document到term的映射。

只要我们针对需要分词的字段设置了fielddata，就可以使用该字段进行聚合，排序等。我们设置为true之后，在索引期间，就会以列式存储在内存中。为什么存在于内存呢，因为按照term聚合，需要执行更加复杂的算法和操作，如果基于磁盘或者 OS 缓存，性能会比较差。

 

2.1fielddata加载到内存的时机

fielddata加载到内又几种策略，默认是懒加载。即对一个分词的字段执行聚合或者排序的时候，加载到内存。所以他不是在索引创建期间创建的，而是查询在期间创建的。

 

2.2 监控fielddata内存使用

GET /_stats/fielddata?fields=*

GET /_nodes/stats/indices/fielddata?fields=*

GET/_nodes/stats/indices/fielddata?level=indices&fields=*

 

2.3fielddata内存管理和限制

那么基于内存，那又会带来一些问题。如果我们不对内存加以控制，如果数据量太大，很容易造成OOM。那我们应该如何控制fielddata呢？

2.3.1 缓存限制

我们可以配置fielddata内存限制，超出这个限制就清除内存中已有的fielddata数据

indices.fielddata.cache.size: 20%

默认无限制，限制内存使用，但是会导致频繁evict和reload，大量IO性能损耗，以及内存碎片和gc

2.3.2 circuitbreaker

如果一次query load的fielddata超过总内存，就会发生内存溢出，circuit breaker会估算query要加载的fielddata大小，如果超出总内存，就短路，query直接失败

indices.breaker.fielddata.limit：fielddata的内存限制，默认60%

indices.breaker.request.limit：执行聚合的内存限制，默认40%

indices.breaker.total.limit：综合上面两个，限制在70%以内

2.3.3 frequency

min: 0.01 只是加载至少1%的doc文档中出现过的term对应的文档

比如说tiger，总共有10000个文档，tiger必须在100个文档中出现。

min_segment_size: 500 少于500 文档数的segment不加载fielddata，

加载fielddata的时候，也是按照segment去进行加载的，某个segment里面的doc数量少于500个，那么这个segment的fielddata就不加载

PUT /animals/_mapping/crawler

{

   "properties":{

       "desc":{

           "type":"text",

            "fielddata": {

               "filter": {

                 "frequency": {

                        "min":0.01,

                       "min_segment_size": 500 

                   }

               }

            }

        }

    }

}

 

2.4fielddata加载机制

如果要对分词的字段执行聚合，那么每次都在查询的时候才生成fielddata并加载到内存中来，速度可能会比较慢。

所以它提供了集中load机制。

2.4.1lazy懒加载

默认就是这个加载方式，仅在需要的时候加载到内存，即只有使用到了这个分词字段用于聚合或者排序才会被加载到内存。

2.4.2 eager预加载

当一个新的段形成时，无论是刷新还是合并，可以预先加载的字段提前把段的fielddata加载到内存，当你第一次查询的时候，如果碰到在这个段上，你不需要再触发加载fielddata的操作，它们已经在内存中了

2.4.3eager_global_ordinals 全局序数预先加载

什么是全局序数？

一项用于减少string类型的fielddata占用内存的技术叫做序数。

举个例子：

假设每一个文档都有一个有限值的字段，比如性别：男 女 男孩 女孩 人妖 5中类型的字段

Doc1: 男

Doc2: 男孩

Doc3: 男

Doc4: 人妖

Doc5: 女

Doc6: 女孩

Doc7: 男孩

Doc8: 女

有很多重复值的情况，会进行global ordinal标记，比如

男：0

女：1

男孩：2

女孩：3

人妖：4

然后就会形成：

Doc1: 0

Doc2: 2

Doc3: 0

Doc4: 4

Doc5: 1

Doc6: 3

Doc7: 2

Doc8: 1

这样的好处就是减少重复字符串的大小，减少内存的消耗

 

PUT /animals/_mapping/crawler

{

   "properties":{

       "desc":{

           "type":"text",

            "fielddata": {

               "loading" : "eager"

            }

        }

    }

}

"fielddata": {

"loading" : "eager_global_ordinals"

}

2.5 fielddata例子

首先创建一个索引映射

PUT /animals

{

   "mappings": {

       "crawler":{

           "properties":{

               "desc":{

                   "type":"text"

               },

               "content":{

                   "type":"text",

                   "index": "not_analyzed"

               }

            }

        }

    }

}

然后添加数据

PUT /animals/crawler/1

{

   "desc":"red",

   "content":"monkey"

}

 

PUT /animals/crawler/2

{

   "desc":"red",

    "content":"snake"

}

 

 

PUT /animals/crawler/3

{

   "desc":"yellow",

   "content":"tiger"

}

然后开始使用分词字段desc聚合，

POST /animals/crawler/_search

{

   "size":0,

   "aggs":{

       "desc_aggs":{

           "terms":{"field":"desc"}

        }

    }

}

这个时候，会报错的。

然后我们尝试修改索引映射，在分此字段desc，添加fielddata=true

PUT /animals/_mapping/crawler

{

   "properties":{

       "desc":{

           "type":"text",

           "fielddata": true

        }

    }

}

再去聚合的时候就有结果了：

"aggregations": {

 "desc_aggs": {

     "doc_count_error_upper_bound":0,

    "sum_other_doc_count": 0,

    "buckets": [

        {

          "key": "red",

          "doc_count": 2

        },

        {

          "key": "yellow",

          "doc_count": 2

        }

     ]

  }

}

 

三 doc_value

我们知道fielddata堆内存要求很高，如果数据量太大，对于JVM来及回收来说存在一定的挑战。所以doc_value的出现我们可以使用磁盘存储，他同样是和fielddata一样的数据结构，在倒排索引基础上反向出来的正排索引，并且是预先构建，即在建倒排索引的时候，就会创建doc values。,这会消耗额外的存储空间，但是对于JVM的内存需求就会减少。总体来看，DocValues只是比fielddata慢一点，大概10-25%，则带来了更多的稳定性。

写入磁盘文件中，OS Cache先进行缓存，以提升访问doc value正排索引的性能，如果OS Cache内存大小不足够放得下整个正排索引，doc value，就会将doc value的数据写入磁盘文件中。

 

它是对不分词的字段，默认建立doc_values,即字段类型为keyword，他不会创建分词，就会默认建立doc_value，如果我们不想该字段参与聚合排序，我们可以设置doc_values=false，避免不必要的磁盘空间浪费。但是这个只能在索引映射的时候做，即索引映射建好之后不能修改。

对于类型是string的字段，一般会生成分词字段和不分词字段，不分词字段即使用keyword，所以我们在聚合的时候，可以直接使用field.keyword进行聚合，而这种默认就是使用doc_values，建立正排索引。

 

 

四 fielddata 和 doc_value的比较

4.1 相同点

# 都要创建正排索引，数据结构类似于列式存储

# 都是为了可以聚合，排序之类的操作

4.2 不同点

# 存储索引数据的方式不一样：

fielddata: 内存存储；doc_values: OS Cache+磁盘存储

# 对应的字段类型不一样

fielddata: 对应的字段类型是text; doc_values：对应的字段类型是keyword

# 针对的类型，也不一样

field_data主要针对的是分词字段；doc_values针对大是不分词字段

# 是否开启

fielddata默认不开启；doc_values默认是开启