搜索的时候，要依靠倒排索引；排序的时候，需要依靠正排索引，看到每个document的每个field，然后进行排序，所谓的正排索引，其实就是doc values
在建立索引的时候，一方面会建立倒排索引，以供搜索用；一方面会建立正排索引，也就是doc values，以供排序，聚合，过滤等操作使用
doc values是被保存在磁盘上的，此时如果内存足够，os会自动将其缓存在内存中，性能还是会很高；如果内存不足够，os会将其写入磁盘上
倒排索引doc1: hello world you and me doc2: hi, world, how are you
分词：倒排索引
word doc1 doc2
hello *
world * *
you * *
and *
me *
hi *
how *
are *
查询：
hello you --> hello, you
hello --> doc1 you --> doc1,doc2
查询结果：
doc1: hello world you and me doc2: hi, world, how are you
正排索引sort by age
doc1: { “name”: “jack”, “age”: 27 } doc2: { “name”: “tom”, “age”: 30 }
document name age
doc1 jack 27
doc2 tom 30
（1）搜索请求发送到某一个coordinate node，构建一个priority queue，长度以paging操作from和size为准，默认为10。
根据from和size参数，构建一个priority queue，大小为from + size。
from = 10000，size = 10，构建一个10000+10 = 10010大小的队列。
（2）coordinate node将请求转发到所有shard，每个shard本地搜索，并构建一个本地的priority queue
协调节点将请求发送到index对应的primary shard（replica shard 也可以）。
（3）各个shard将自己的priority queue返回给coordinate node，并构建一个全局的priority queue
接收到请求的shard，会构建一个from+size大小的本地的priority queue，
比如构建一个10000+10 = 10010大小的priority queue
每个shard都会将自己的前10010条数据返回给coordinate node协调节点，coordinate node将所有的shard的from+size大小的priority queue进行merge。merge成一个的全局priority queue，全局排序后的queue，放到自己的queue中
此时，coordinate node可以将自己的priority queue中的数量取出要获取的数据，比如
从10000条数据开始取到10010条。
这就出现了之前提及的deep paging问题。
from+size分页太深，那么每个shard都要返回大量数据给coordinate node，消耗大量的IO、memory、CPU。
2、replica shard如何提升搜索吞吐量一次请求要打到所有shard的一个replica/primary上去，如果每个shard都有多个replica，那么同时并发过来的搜索请求可以同时打到其他的replica上去
3fetch phase 1、fetch phase工作流程（1）coordinate node构建完priority queue之后，就发送mget请求去所有shard上获取对应的document （2）各个shard将document返回给coordinate node （3）coordinate node将合并后的document结果返回给client客户端
ument返回给coordinate node （3）coordinate node将合并后的document结果返回给client客户端
[外链图片转存中…(img-SrILPmJh-1636763052136)]
2、一般搜索，如果不加from和size，就默认搜索前10条，按照_score排序
