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

基本概念

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

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

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

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

索引速度稍低这个是相对于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，需要重建索引，这个在生产环境下还是要谨慎。