本节将详细介绍es Search API的查询主体，定制化查询条件的实现主体。
搜索请求体中查询条件使用es DSL查询语法来定义。通过使用query来定义查询体。
1GET /_search 2{ 3 "query" : { 4 "term" : { "user" : "kimchy" } 5 } 6}
es的一种分页语法。通过使用from和size参数来对结果集进行分页。
from设置第一条数据的偏移量。size设置返回的条数(针对每个分片生效)，由于es天生就是分布式的，通过设置主分片个数来进行数据水平切分，一个查询请求通常需要从多个后台节点(分片)进行数据汇聚。
From/Size方式会遇到分布式存储的一个共性问题：深度分页，也就是页数越大需要访问的数据则越大。es提供了另外一种分页方式，滚动API(Scroll)，后续会详细分析。
注意：from + size 不能超过index.max-_result_window配置项的值，其默认值为10000。
与传统关系型数据库类似，es支持根据一个或多个字段进行排序，同时支持asc升序或desc降序。另外es可以按照_sco-re(基于得分)的排序，默认值。
如果使用了排序，响应结果中每一条命中数据将包含一个响应字段sort，其类型为Object[]，表示该文档当前的排序值，该值在ES支持的第三种分页方式S-earch After中会使用到。
排序顺序
es提供了两种排序顺序，SortOrder.AS-C(asc)升序、SortOr-der.DESC(desc)降序，如果排序类型为_score，其默认排序顺序为降序(desc)，如果排序类型为字段，则默认排序顺序为升序(asc)。
排序模型选型
es支持按数组或多值字段进行排序。模式选项控制选择的数组值，以便对它所属的文档进行排序。模式选项可以有以下值：
- min 使用数组中最小的值参与排序
- max 使用数组中最大的值参与排序
- sum 使用数组中的总和参与排序
- avg 使用数组中的平均值参与排序
- median 使用数组中的中位数参与排序
如果是一个数组类型的值参与排序，通常会对该数组元素进行一些计算得出一个最终参与排序的值，例如取平均数、最大值、最小值、求和等运算。es通过排序模型mode来指定。
嵌套字段排序
es还支持在一个或多个嵌套对象内部的字段进行排序。一个嵌套查询提包含如下选项（参数）：
- path
定义要排序的嵌套对象。排序字段必须是这个嵌套对象中的一个直接字段（非嵌套字段），并且排序字段必须存在。 - filter
定义过滤上下文，定义排序环境中的过滤上下文。 - max_children
排序是要考虑根文档下子属性文档的最大个数，默认为无限制。 - nested
排序体支持嵌套。
1"sort" : [ 2 { 3 "parent.child.age" : { // @1 4 "mode" : "min", 5 "order" : "asc", 6 "nested": { // @2 7 "path": "parent", 8 "filter": { 9 "range": {"parent.age": {"gte": 21}} 10 }, 11 "nested": { // @3 12 "path": "parent.child", 13 "filter": { 14 "match": {"parent.child.name": "matt"} 15 } 16 } 17 } 18 } 19 } 20]
代码@1：排序字段名，支持级联表示字段名。
代码@2：通过nested属性定义排序嵌套语法，其中path定义当前的嵌套层级，f-ilter定义过滤上下文。
@3内部可以再通过nested属性再次嵌套定义。
missing values
由于es的索引，类型下的字段可以在索引文档时动态增加，那如果有些文档没有包含排序字段，这部分文档的顺序如何确定呢？es通过missing属性来确定，其可选值为：
- _last
默认值，排在最后。 - _first
排在最前。
ignoring unmapped fields
默认情况下，如果排序字段为未映射的字段将抛出异常。可通过unmapped_ty-pe来忽略该异常，该参数指定一个类型，也就是告诉ES如果未找该字段名的映射，就认为该字段是一个unmapped_-type指定的类型，所有文档都未存该字段的值。
Geo sorting
地图类型排序，该部分将在后续专题介绍geo类型时讲解。
默认情况下，对命中的结果会返回_so-urce字段下的所有内容。字段过滤机制允许用户按需要返回_source字段里面部分字段。其过滤设置机制已在Elasticse-arch Document Get API详解、原理与示例中已详细介绍，在这里就不重复介绍了。
使用方式如下：
1GET /_search 2{ 3 "query" : { 4 "match_all": {} 5 }, 6 "docvalue_fields" : [ 7 { 8 "field": "my_date_field", 9 "format": "epoch_millis" 10 11 } 12 ] 13}
通过使用docvalue_fields指定需要转换的字段与格式，它对于在映射文件中定义stored=false的字段同样生效。字段支持用通配符，例如"field":"myfield*"。
docvalue_fields中指定的字段并不会改变_souce字段中的值，而是使用fields返回值进行额外返回。
java实例代码片段如下（完整的Demo示例将在文末给出）：
1SearchSourceBuilder sourceBuilder = new SearchSourceBuilder(); 2sourceBuilder.query(QueryBuilders.termQuery("user", "dingw")) 3 .sort(new FieldSortBuilder("post_date").order(SortOrder.DESC)) 4 .docValueField("post_date", "epoch_millis")
其返回结果如下：
{ "took":88, "timed_out":false, "_shards":{ "total":5, "successful":5, "skipped":0, "failed":0 }, "hits":{ "total":2, "max_score":null, "hits":[ { "_index":"twitter", "_type":"_doc", "_id":"11", "_score":null, "_source":{ "post_date":"2009-11-19T14:12:12", "message":"test bulk update", "user":"dingw" }, "fields":{ "post_date":[ "1258639932000" ] }, "sort":[ 1258639932000 ] }, { "_index":"twitter", "_type":"_doc", "_id":"12", "_score":null, "_source":{ "post_date":"2009-11-18T14:12:12", "message":"test bulk", "user":"dingw" }, "fields":{ "post_date":[ "1258553532000" ] }, "sort":[ 1258553532000 ] } ] } }
post filter对查询条件命中后的文档再做一次筛选。
1GET /shirts/_search 2{ 3 "query": { 4 "bool": { 5 "filter": { 6 "term": { "brand": "gucci" } // @1 7 } 8 } 9 }, 10 "post_filter": { // @2 11 "term": { "color": "red" } 12 } 13}
首先根据@1条件对索引进行检索，然后得到匹配的文档后，再利用@2过滤条件对结果再一次筛选。
查询结果高亮显示。
Es支持的高亮分析器
用于对查询结果中对查询关键字进行高亮显示，高亮显示查询条件在查询结果中匹配的部分。
注意：高亮显示器在提取要高亮显示的术语时不能反映查询的布尔逻辑。因此对于一些复杂的布尔查询(例如嵌套的布尔查询，或使用minimum_should_mat-ch等查询)可能高亮显示会出现一些误差。
高亮显示需要字段的实际内容。如果字段没有存储(映射没有将store设置为tru-e)，则从_source中提取相关字段。
es支持三种高亮显示工具，通过为每个字段指定type来使用。
- unified highlighter
使用Lucene unified高亮显示器。首先将文本分解成句子并使用BM25算法对单个句子进行评分。支持精确的短语和多术语(模糊、前缀、正则表达式)高亮显示。这是es默认的高亮显示器。 - plain highlighter
使用Lucene标准高亮显示器。plain highlighter最适合单个字段的匹配高亮显示需求。为了准确地反映查询逻辑，它在内存中创建一个很小的索引，并通过Lucene的查询执行计划重新运行原来的查询条件，以便获取当前文档的更低级别的匹配信息。如果需要对多个字段进行高亮显示，建议还是使用unified高亮显示器或term_vector fields。
plain高亮显示器是一个实时分析处理高亮器。即用户在查询的时候，搜索引擎查询到了目标数据docid后，将需要高亮的字段数据提取到内存，再调用该字段的分析器进行处理，分析完后采用相似度算法计算得分最高的前n组并高亮段返回数据。
plain高亮器是实时分析高亮器，这种实时分析机制会让ES占用较少的IO资源同时也占用较少的存储空间（词库较全的话相比fvh方式能节省一半的存储空间），其策略是采用cpu资源来换取磁盘IO压力，在需要高亮字段较短（比如高亮文章的标题）时候速度较快，同时因IO访问的次数少，IO压力较小，有利于提高系统吞吐量。 - fast vector highlighter（fvh）
使用lucene fast vector highlingter，基于词向量，该高亮处理器必须开启term_vector=with_positions_off-sets，存储词向量、即位置与偏移量。为解决大文本字段上高亮速度性能的问题，lucene高亮模块提供了基于向量的高亮方式 fvh。fvh高亮显示器利用建索引时候保存好的词向量来直接计算高亮段落，在高亮过程中比plain高亮方式少了实时分析过程，取而代之的是直接从磁盘中将分词结果直接读取到内存中进行计算。故要使用fvh的前置条件就是在建索引时候，需要配置存储词向量，词向量需要包含词位置信息、词偏移量信息。
注意：fvh高亮器不支持span查询。如果您需要对span查询的支持，请尝试其他高亮显示，例如unified hi-ghlighter。
Offsets Strategy
获取偏移量策略。高亮显示要解决的一个核心就是高亮显示的词根以及该词根的位置（位置与偏移量）。
ES中提供了3中获取偏移量信息(Offset-s)的策略：
- The postings list
如果将index_options设置为offset-s，unified高亮器将使用该信息突出显示文档，而无需重新分析文本。它直接对索引重新运行原始查询，并从索引中提取匹配偏移量。如果字段很大，这一点很重要，因为它不需要重新分析需要高亮显示的文本。比term_vector方式占用更少的磁盘空间。 - Term vectors
如果在字段映射中将term_vector设置为with_positions_offset，unified highlighter将自动使用term_vector来高亮显示字段。它特别适用于大字段和高亮显示多词根查询(如前缀或通配符)，因为它可以访问每个文档的术语字典。fvh高亮器必须将字段映射term_vector设置为with_pos-itions_offset时才能生效。 - Plain highlighting
当没有其他选择时，统一使用这种模式。它在内存中创建一个很小的索引，并通过Lucene的查询执行计划重新运行原来的查询条件，以访问当前文档上的低级匹配信息。对于每个需要突出显示的字段和文档，都要重复此操作。Plain高亮显示器就是这种模式。
注意：对于大型文本，Plain显示器可能需要大量的时间消耗和内存。为了防止这种情况，在下一个版本中，对要分析的文本字符的最大数量将限制在100万。6.x版本默认无限制，但是可以使用索引设置参数index.highlight.max_analyzed_offset为特定索引设置。
高亮显示配置项
高亮显示的全局配置会被字段级别的覆盖。
- boundary_chars
设置边界字符串集合，默认包含：.,!? \t\n - boundary_max_scan
扫描边界字符。默认为20。 - boundary_scanner
指定如何分解高亮显示的片段,可选值为chars、sentence、word。 - chars
字符。使用由bordery_chars指定的字符作为高亮显示边界。通过boun-dary_max_scan控制扫描边界字符的距离。该扫描方式只适用于fvh。 - sentence
句子，使用Java的BreakIterator确定的下一个句子边界处的突出显示片段。您可以使用boundary_scann-er_locale指定要使用的区域设置。unified 高亮器默认行为。 - word
单词，由Java的BreakIterator确定的下一个单词边界处高亮显示的片段。 - boundary_scanner_locale
区域设置。该参数采用语言标记的形式，例如。“en - us”、“- fr”、“ja-JP”。更多信息可以在Locale语言标记文档中找到。默认值是local.roo-t。 - encoder
指示代码段是否应该编码为HTML:默认(无编码)或HTML (HTML-转义代码段文本，然后插入高亮标记)。 - fields
指定要检索高亮显示的字段，支持通配符。例如，您可以指定comme-nt_*来获得以comment_开头的所有文本和关键字字段的高亮显示。
注意：当您使用通配符时，只会匹配text、keyword类型字段。 - force_source
是否强制从_source高亮显示，默认为false。其实默认情况就是根据源字段内容(_source)内容高亮显示，即使字段是单独存储的。 - fragmenter
指定如何在高亮显示代码片段中拆分文本:可选值为simple、span。仅适用于Plain高亮显示器。默认为sp-an。 - simple
将文本分成大小相同的片段。 - span
将文本分割成大小相同的片段，但尽量避免在突出显示的术语之间分割文本。这在查询短语时很有用。 - fragment_offset
控制开始高亮显示的margin(空白)，仅适用于fvh。 - fragment_size
高亮显示的片段，默认100。 - highlight_query
高亮显示匹配搜索查询以外的查询。如果您使用rescore查询，这尤其有用，因为默认情况下高亮显示并不会考虑这些查询。通常，应该将搜索查询包含在highlight_query中。 - matched_fields
组合多个字段上的匹配项以突出显示单个字段。对于以不同方式分析相同字符串的多个字段，这是最直观的。所有matched_fields必须将term_vector设置为with_positions-_offset，但是只加载匹配项组合到的字段，所以建议该字段store设置为true。只适用于fvh。 - no_match_size
如果没有要高亮显示的匹配片段，则希望从字段开头返回的文本数量。默认值为0(不返回任何内容)。 - number_of_fragments
返回的高亮显示片段的最大数量。如果片段的数量设置为0，则不返回片段。默认为5。 - order
该值默认为none，按照字段的顺序返回高亮文档，可以设置为score(-按相关性排序)。 - phrase_limit
控制要考虑的文档中匹配短语的数量。防止fvh分析太多的短语和消耗太多的内存。在使用matched_fields时，将考虑每个匹配字段的phrase-_limit短语。提高限制会增加查询时间并消耗更多内存。只支持fvh。默认为256。 - pre_tags
用于高亮显示HTML标签，与post_-tags一起使用，默认用高亮显示文本。 - post_tags
用于高亮显示HTML标签，与pre_t-ags一起使用，默认用高亮显示文本。 - require_field_match
默认情况下，只有包含查询匹配的字段才会高亮显示。将require_fiel-d_match设置为false以突出显示所有字段。默认值为true。 - tags_schema
定义高亮显示样式，例如。 - type
指定高亮显示器，可选值：unified、plain、fvh。默认值为unified。
高亮显示demo
1public static void testSearch_highlighting() { 2 RestHighLevelClient client = EsClient.getClient(); 3 try { 4 SearchRequest searchRequest = new SearchRequest(); 5 searchRequest.indices("map_highlighting_01"); 6 SearchSourceBuilder sourceBuilder = new SearchSourceBuilder(); 7 sourceBuilder.query( 8 // QueryBuilders.matchAllQuery() 9 QueryBuilders.termQuery("context", "身份证") 10 ); 11 12 HighlightBuilder highlightBuilder = new HighlightBuilder(); 13 highlightBuilder.field("context"); 14 15 sourceBuilder.highlighter(highlightBuilder); 16 searchRequest.source(sourceBuilder); 17 System.out.println(client.search(searchRequest, RequestOptions.DEFAULT)); 18 } catch (Exception e) { 19 // TODO: handle exception 20 } 21 }
其返回值如下：
1{ 10 "hits":{ 11 13 "hits":[ 14 { 19 "_source":{ 20 "context":"城中西路可以受理外地二代身份证的办理。" 21 }, 22 "highlight":{ // @1 23 "context":[ 24 "城中西路可以受理外地二代<em>身份证</em>的办理。" 25 ] 26 } 27 } 28 ] 29 } 30}
这里主要对highlight再做一次说明，其中每一个字段返回的内容是对应原始数据的子集，最多fragmentSize个待关键字的匹配条目，通常，在页面上显示文本时，应该用该字段取代原始值，这样才能有高亮显示的效果。
重打分机制。一个查询首先使用高效的算法查找文档，然后对返回结果的top n 文档运用另外的查询算法,通常这些算法效率低效但能提供匹配精度。
resoring查询与原始查询分数的合计方式如下：
- total
两个评分相加 - multiply
将原始分数乘以rescore查询分数。用于函数查询重定向。 - avg
取平均数 - max
取最大值 - min
取最小值。
查询类型，默认值为query_then_f-etch。
- QUERY_THEN_FETCH
首先根据路由算法向相关分片（多个）发送请求，此时只返回docid与一些必要信息（例如用于排序等），然后对各个分片的结果进行汇聚，排序，然后选取客户端指定需要获取的数据条数前N条数据，然后根据docid再向各个分片请求具体的文档信息。 - QUERY_AND_FETCH
在5.4.x版本开始废弃，是直接向各个分片节点请求数据，每个分片返回客户端请求数量的文档信息，然后汇聚全部返回给客户端，返回的数据为客户端请求数量size * (路由后的分片数量)。 - DFS_QUERY_THEN_FETCH
在开始向各个节点发送请求之前，会进行一次词频、相关性的计算，后续流程与QUERY_THEN_FETCH相同，可以看出，该查询类型的文档相关性会更高，但性能比QUER-Y_THEN_FETCH要差。
滚动查询。es另外一种分页方式。虽然搜索请求返回结果的单个页面，但scroll API可以用于从单个搜索请求检索大量结果(甚至所有结果)，这与在传统数据库上使用游标的方式非常相似。
scroll api不用于实时用户请求，而是用于处理大量数据，例如为了将一个索引的内容重新索引到具有不同配置的新索引中。
如何使用scroll API
scroll API使用分为两步：
1、第一步，首先通过scroll参数，指定该滚动查询(类似于数据库的游标的存活时间)
1POST /twitter/_search?scroll=1m 2{ 3 "size": 100, 4 "query": { 5 "match" : { 6 "title" : "elasticsearch" 7 } 8 } 9}
该方法会返回一个重要的参数scrollId。
2、第二步，使用该scrollId去es服务器拉取下一批（下一页数据）
1POST /_search/scroll 2{ 3 "scroll" : "1m", 4 "scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAD4WYm9laVYtZndUQlNsdDcwakFMNjU1QQ==" 5}
循环第三步，可以循环批量处理数据。
3、第三步，清除scrollId，类似于清除数据库游标，快速释放资源。
1DELETE /_search/scroll 2{ 3 "scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAD4WYm9laVYtZndUQlNsdDcwakFMNjU1QQ==" 4}
下面给出scoll api的java版本示例程序
1public static void testScoll() { 2 RestHighLevelClient client = EsClient.getClient(); 3 String scrollId = null; 4 try { 5 System.out.println("step 1 start "); 6 // step 1 start 7 SearchRequest searchRequest = new SearchRequest(); 8 searchRequest.indices("map_highlighting_01"); 9 SearchSourceBuilder sourceBuilder = new SearchSourceBuilder(); 10 sourceBuilder.query( 11 QueryBuilders.termQuery("context", "身份证") 12 ); 13 searchRequest.source(sourceBuilder); 14 searchRequest.scroll(TimeValue.timeValueMinutes(1)); 15 SearchResponse result = client.search(searchRequest, RequestOptions.DEFAULT); 16 scrollId = result.getScrollId(); 17 // step 1 end 18 19 // step 2 start 20 if(!StringUtils.isEmpty(scrollId)) { 21 System.out.println("step 2 start "); 22 SearchScrollRequest scrollRequest = new SearchScrollRequest(scrollId); 23 scrollRequest.scroll(TimeValue.timeValueMinutes(1)); 24 while(true) { //循环遍历 25 SearchResponse scollResponse = client.scroll(scrollRequest, RequestOptions.DEFAULT); 26 if(scollResponse.getHits().getHits() == null || 27 scollResponse.getHits().getHits().length < 1) { 28 break; 29 } 30 scrollId = scollResponse.getScrollId(); 31 // 处理文档 32 scrollRequest.scrollId(scrollId); 33 } 34 // step 2 end 35 } 36 System.out.println(result); 37 } catch (Exception e) { 38 e.printStackTrace(); 39 } finally { 40 if(!StringUtils.isEmpty(scrollId)) { 41 System.out.println("step 3 start "); 42 // step 3 start 43 ClearScrollRequest clearScrollRequest = new ClearScrollRequest(); 44 clearScrollRequest.addScrollId(scrollId); 45 try { 46 client.clearScroll(clearScrollRequest, RequestOptions.DEFAULT); 47 } catch (IOException e) { 48 // TODO Auto-generated catch block 49 e.printStackTrace(); 50 } 51 // step 3 end 52 } 53 } 54 55 }
这里重点阐述一下第一次查询时，不仅返回scrollId，也会返回第一批数据。
Keeping the search context alive
scroll参数(传递给搜索请求和每个滚动请求)告诉es它应该保持搜索上下文活动多长时间。只需要足够长的时间来处理前一批结果。
每个scroll请求(带有scroll参数)设置一个新的过期时间。如果scroll请求没有传入scroll，那么搜索上下文将作为scroll请求的一部分被释放。
scroll其内部实现类似于快照，当第一次收到一个scroll请求时，就会为该搜索上下文所匹配的结果创建一个快照，随后文档的变化并不会反映到该API的结果。
sliced scroll
对于返回大量文档的scroll查询，可以将滚动分割为多个可以独立使用的片,通过slice指定。例如：
1GET /twitter/_search?scroll=1m // @1 2{ 3 "slice": { // @11 4 "id": 0, // @12 5 "max": 2 // @13 6 }, 7 "query": { 8 "match" : { 9 "title" : "elasticsearch" 10 } 11 } 12} 13GET /twitter/_search?scroll=1m // @2 14{ 15 "slice": { 16 "id": 1, 17 "max": 2 18 }, 19 "query": { 20 "match" : { 21 "title" : "elasticsearch" 22 } 23 } 24}
@1,@2两个并列的查询，按分片去查询。
@11：通过slice定义分片查询。
@12：该分片查询的ID。
@13：本次查询总片数。
这个机制非常适合多线程处理数据。
具体分片机制是，首先将请求转发到各分片节点，然后在每个节点使用匹配到的文档(hashcode(_uid)%slice片数)，然后各分片节点返回数据到协调节点。也就是默认情况下，分片是根据文档的_uid，为了提高分片过程，可以通过如下方式进行优化，并指定分片字段。
- 分片字段类型为数值型。
- 字段的doc_values设置为true。
- 每个文档中都索引了该字段。
- 该字段值只在创建时赋值，并不会更新。
- 字段的基数应该很高（相当于数据库索引选择度），这样能确保每个片返回的数据相当，数据分布较均匀。
注意，默认slice片数最大为1024，可以通过索引设置项index.max_slices_per-_scroll来改变默认值。例如：
1GET /twitter/_search?scroll=1m 2{ 3 "slice": { 4 "field": "date", 5 "id": 0, 6 "max": 10 7 }, 8 "query": { 9 "match" : { 10 "title" : "elasticsearch" 11 } 12 } 13}
