doc es 中type_一文带你彻底弄懂ES中的doc_values和fielddata

基本概念

这两个概念比较像，所以大部分时候会放在一起说。

这两个概念源于Elasticsearch(后面简称ES)除了强大的搜索功能外，还可以支持排序，聚合之类的操作。搜索需要用到倒排索引，而排序和聚合则需要使用 "正排索引"。说白了就是一句话，倒排索引的优势在于查找包含某个项的文档，而反过来确定哪些项在单个文档里并不高效。

doc_values和fielddata就是用来给文档建立正排索引的。他俩一个很显著的区别是，前者的工作地盘主要在磁盘，而后者的工作地盘在内存。

我整理了一个表格，从不同维度比较这哥俩。

维度

doc_values

fielddata

创建时间

index时创建

使用时动态创建

创建位置

磁盘

内存(jvm heap)

优点

不占用内存空间

不占用磁盘空间

缺点

索引速度稍低

文档很多时，动态创建开销比较大，而且占内存

索引速度稍低这个是相对于fielddata方案的，其实仔细想想也可以理解。那排序举例，相对于一个在磁盘排序，一个在内存排序。谁的速度快自然不用多说。

在ES 1.x版本的官方说法是，

Doc values are now only about 10–25% slower than in-memory fielddata

虽然速度稍慢，doc_values的优势还是非常明显的。一个很显著的点就是他不会随着文档的增多引起OOM问题。正如前面说的，doc_values在磁盘创建排序和聚合所需的正排索引。这样我们就避免了在生产环境给ES设置一个很大的HEAP_SIZE，也使得JVM的GC更加高效，这个又为其它的操作带来了间接的好处。

而且，随着ES版本的升级，对于doc_values的优化越来越好，索引的速度已经很接近fielddata了，而且我们知道硬盘的访问速度也是越来越快(比如SSD)。所以 doc_values 现在可以满足大部分场景，也是ES官方重点维护的对象。

所以我想说的是，doc values相比field data还是有很多优势的。所以 ES2.x 之后，支持聚合的字段属性默认都使用doc_values，而不是fielddata。

示例

光说不练假把式。上例子吧。我下面的例子是基于ES 7.1版本。

先准备一些数据，

PUT users

{

"mappings" : {

"properties" : {

"name" : {

"type" : "text"

},

"mobile" : {

"type" : "keyword"

},

"age" : {

"type" : "integer"

}

}

}

}

这里我们新建了一个名为users的index，设置了mapping。然后插入一些测试数据，

PUT users/_doc/1

{

"name":"tom",

"mobile": "15978866921",

"age": 30

}

PUT users/_doc/2

{

"name":"jerry",

"mobile": "15978866920",

"age": 35

}

PUT users/_doc/3

{

"name":"jack",

"mobile": "15978866922",

"age": 20

}

接着我们搜索的时候，基于年龄排序，

POST users/_search

{

"query": {

"match_all": {}

},

"sort": [

{

"age": {

"order": "desc"

}

}

]

}

结果是正常的，

{

"took" : 3,

"timed_out" : false,

"_shards" : {

"total" : 1,

"successful" : 1,

"skipped" : 0,

"failed" : 0

},

"hits" : {

"total" : {

"value" : 3,

"relation" : "eq"

},

"max_score" : null,

"hits" : [

{

"_index" : "users",

"_type" : "_doc",

"_id" : "2",

"_score" : null,

"_source" : {

"name" : "jerry",

"mobile" : "15978866920",

"age" : 35

},

"sort" : [

35

]

},

{

"_index" : "users",

"_type" : "_doc",

"_id" : "1",

"_score" : null,

"_source" : {

"name" : "tom",

"mobile" : "15978866921",

"age" : 30

},

"sort" : [

30

]

},

{

"_index" : "users",

"_type" : "_doc",

"_id" : "3",

"_score" : null,

"_source" : {

"name" : "jack",

"mobile" : "15978866922",

"age" : 20

},

"sort" : [

20

]

}

]

}

}

对于非text字段类型，doc_values默认情况下是打开的。索引我们上面的操作都没有问题。现在我们把doc_values关掉再试试。

由于修改mapping需要重建索引，为了简单起见，我这里把index直接删掉重建。

关闭doc_values,

DELETE users

PUT users

{

"mappings" : {

"properties" : {

"name" : {

"type" : "text"

},

"mobile" : {

"type" : "keyword"

},

"age" : {

"type" : "integer",

"doc_values": false

}

}

}

}

重新插入数据，然后再次搜索排序，发现报错，

意思就是age字段不支持排序了，需要打开doc_values才行。

fielddata现在用的不多，我就不演示了。

原理剖析

简单分析下doc_values的原理。我们知道搜索的时候需要使用倒排索引，类似下图这样，

比如说，所以我们要查找包含brown的文档，先在词项列表中找到 brown，然后扫描所有列，可以快速找到包含 brown 的文档。

但是如果是要对搜索结果进行排序或者其它聚合操作，倒排索引这种方式就没真这么容易了，反而是类下面这种正排索引更方便。doc_values其实是Lucene在构建倒排索引时，会额外建立一个有序的正排索引(基于document => field value的映射列表)。

总结

根据经验，大部分情况下你都不需要主动打开 fielddata，doc_values能满足大部分需求。

另外，mapping中的字段我们确定以后不会基于这个字段做排序或者聚合，可以把它关掉，但是一定要非常明确你的这个操作，因为如果要重新打开doc_values，需要重建索引，这个在生产环境下还是要谨慎。