Lucene doc value结构自己的一点理解

前段时间在玩Lucene的时候发现 字段若想排序，则必须写入是索引使用NumericDocValuesField类型，否则不能进行排序操作。然后特地调研了下这个DocValue。不知道自己理解的是否正确，所以想在这里把我的想法和疑惑写一下，欢迎大家拍砖指正。
 
首先 只有倒排索引进行排序效率是很低的，我理解如下：
 
假设我要根据 content搜索，然后根据time字段排序，因为倒排索引是一个field对应一个docId的，所以query阶段我只能取回docId，没有更多字段的值，所以需要有一个地方获取time的值。倒排索引如下：
 
term        docId
--------------------
10              2
13              3
14              1, 5, 8
16              7,9,10
--------------------
 
这样的结构是没法直接获取到time字段的，假设现在没有doc_value 以及fieldcache（doc_value出来之前貌似都是通过这个结构做排序） 所以只有到time所在的倒排索引进行遍历，看看我这些docId的time值都对应是多少，所以这一步是要通过docId获取fieldvalue的，遍历倒排索引效率会很低，因此必须要一个正向关系来做这件事儿。
 
那么这个结构在低版本的时候是通过FieldCache 来获取的，FieldCache简单抽象的理解就是一个大数组，数组的下标表示docId，数组中的值表示这个field的value（注意 还是一个field一个数组）。上面的步骤当我需要按照time排序时，假设过滤出100个docID，就可以拿他们去数组中直接取到time值然后排序，获取排序字段的时间复杂度瞬间变成O(n) (n为doc个数)，效率比遍历倒排索引可好多了吧。
抽象的结构如下：
 
time:
--------------------------------------------------------------
| 2019 | 2018 | 2017 | 2019 | 2016 | 2015 | 2016 | 2018 |
--------------------------------------------------------------
  0          1         2        3         4        5        6        7
 
同理如果是聚合类需求，例如查看年龄大于24岁人的职业分布情况，假设职业是一个枚举并且建索引了，过滤出24岁人后，依然需要一个地方把满足条件的人的职业信息或取出来，通过上述结构可以解决这个问题
 
但是这个东西比较吃内存（doc越多，数组越长），所以后来出来了一个doc_value 替代了fieldCache，这个东西是放在磁盘上的，能够承载的空间也就比较大了。 
 
我对doc_value的理解描述完了，接下来就说我的疑问。
是不是所有排序/聚合场景都必须走doc_value?
 
问题的根源在于排序/聚合的数据需要一次回取操作（类似mysql的一次二级索引回取数据），如果过滤和排序/聚合用的是同一个字段是不是就不需要额外走doc_value了？  比如查询2019-07-18日的日志数据，按照时间排序；  查询职业为程序员、产品经理、运营、设计、hrbp的同学分别有多少人。case1中 取到docId的时候可以跟time做一个映射，然后根据time排序docId即可；case2中  因为一个值对应一个docId列表很容易就能计算出这个值下面有多少docId。 我的结论：在过滤和排序/聚合使用相同字段时，无需走doc_value