之前看过很多doc_Value相关的文章，也看过elasticsearch官方的描述，但是总是感觉对doc_value如何提升聚合排序性能这块说的很简单（也许是我个人理解力的问题），总是不能深刻理解没有doc_Value的话会牺牲多大性能，再加上每次研究一半就搁置了，所以一直没能很好理解这块知识点，今天来重点复盘下。  本文不是科普文，不一定是完全正确的，大家可以讨论。   首先从elasticsearch入手，我们建立一个索引结构如下：

{
  "info": {
    "mappings": {
      "info": {
        "_all": {
          "enabled": false
        },
        "properties": {
          "age": {
            "type": "int"
          },
          "time": {
            "type": "long"
          }
        }
      }
    }
  }
}

我这里特地拿非字符串类型的值做举例，大家在用MySQL的时候大多是用值精准匹配等条件，没有涉及到分词和多值，所以一开始很多用分词举例的时候我就糊涂了，这里我用数字举例说明下。   假设我们的需求是查询time=10的各个age包含的info有多少。这是一个搜索兼聚合的需求，首先要搜出来time:[1 , 10]的结果，然后在这些doc结果里统计，他们的age各自分别占了多少个doc。语句如下：

{
  "query": {
    "term": {
      "time": 10
    }
  },
  "aggs": {
    "age_terms": {
      "terms": {
        "field": "age"
      }
    }
  }
}

假设我们的数据是这样的： docId        time           age 1               10               20 2              8                 21 3              9                 24 4              2                 23 5              10                22 6              10                22     结果也很明显了，返回doc为1，5，6的内容，聚合结果， age=20的doc_count=1,  age=22的doc_coutn=2。   demo介绍完了，说下假设没有doc_value，只有倒排索引我们要怎么实现这个效果。   首先搜索不用说了，走time字段的倒排索引，下表： 2：4 8：2 9：3 10：1，5，6 一目了然，一下就能把post_list结果拿到。   那么聚合是在1，5，6这个结果之上做的，因为聚合字段和排序字段不一样，time倒排索引中不包含age的信息，所以要想对age做聚合，就需要做类似回表的操作想办法取回每个doc对应的age值，然后在内存中遍历下算出来每个age对应的doc有几个（当然这个例子最多只有3个doc_count, 返回值只有3个doc）。   取回的方式，可以走age的倒排索引，遍历age索引的term_dictionary（不了解的同学可以理解为这就是一个排序的term列表），遍历要做的事情是什么呢：取出每个term后面的postling_list，看下list中有没有对应我搜索结果的doc_id，有的话记录下有几个，给这个term做下标记记录term的doc_count。 这个过程就比较狗了，假设term非常多，遍历一次的代价就非常高，所以在没有doc_value的情况下，遍历倒排索引就显得很差劲，倒排索引的价值本来就是避免数据遍历提升搜索性能，到了这种聚合需求上反而要用我做这么高代价的事儿，所以才需要一个出路避免这个问题。   这时候有人会说了，一个info对应一个age，那么当我遍历的时候，记录下这个doc有没有遍历过，当所有doc_id都遍历过一遍后就不遍历了，能提升一些性能吧。  首先如果运气不好，碰上你的doc要聚合的term出现在term_dictionary最后一个的时候，时间开销还是最坏情况的，其次，我这里用的是单个数值，如果一个field是多值的呢，换句话说，如果是分词的字符串呢，多值和分词其实一样，这种情况下当你遍历到一个term包含结果的某个doc_id时你不能说这个doc不会再后续的其他term中出现了，你还是要继续遍历完，所以为了满足这个需求，遍历全部term_dictionary是没跑的。   排序其实也差不多的，如果你要根据非搜索结果进行排序，一样要取出结果doc，对应排序字段的值，然后内存排序，所以内存排序聚合我觉得不是开销大的点，开销大的地方在于遍历倒排索引。   其实讲到这里我的疑惑基本就解决了。接下来再说下doc_value   doc_value通俗的讲就是正排索引（这个词儿基本上所有文章都会这么说，说的也对，就是看多了有点想吐。。），其实正排索引就是我上面列举出来的那个值列表，只不过是一个字段一个doc_value，跟倒排索引一样，不是放在一起的（这点区别mysql聚集索引的叶子节点，聚集索引叶子节点是保存了全部的值，用主键绑定的，这里也说明了Lucene是索引和数据分离的，而MySQL是索引即数据，我是这么理解）。 time的doc_value docId        time            1               10               2              8                 3              9                  4              2                  5              10                6              10                   age的doc_value docId        age 1               20 2               21 3               24 4               23 5               22 6               22   现在我们有了这样的一个结构可就厉害了，回到刚才的场景，搜索完结果是1，5，6，如果想按age进行聚合或者排序，那么只需要我们来到doc_value中，根据我们的id列表和doc_value的列表做交集拿出来结果对应的age就可以了，然后内存排序一下，实际上doc_value完全可以按照value先排好序，然后我们交集的结果就是排序结果了，都不用内存再排一次（暂时还不知道doc_value是不是根据value排过序）。     最后再说下我觉得其实可以优化的地方，之前我在问答也提问过，就是当搜索和排序/聚合使用相同字段的时候，还要不要走doc_value的问题。   因为如果是同一个字段那么完全没必要回表了，倒排索引本来就是field有序的所以排序问题解决。   其次聚合，刚才的例子中是单值的，如果是多值的话也不要紧，因为我们都知道查询条件的值了，单值的话 doc_count就等于total，多值的话 doc_count就等于其posting_list的length，多简单，省的走一次doc_value的操作。   不过那个问答回答的人太少，回答我的人的答复也蛮精彩的但是我仍然觉得这个操作是可以分开的。   求各路大神们对本文的观点做出指点和评论，或者我理解不对的地方提出指正。 对于想了解doc_value的同学希望这篇文章能解决你们的疑惑。