ES基础、高级特性及整合SpringBoot

ElasticSearch是一个由Java编写的基于Lucene框架、天生支持分布式、RESTful风格的开源搜索和数据分析引擎，也是Elastic Stack的核心。Elastic Stack就是整个Elastic公司包含的所有技术栈，其中包括了最著名的ELK（ES + Logstash + Kibana），以及其他毛毛多的技术，就不提了。

搜索引擎大家应该都不陌生，打开Google输入几个关键词Google一下，就会根据相关度依次展示你搜索的内容，且会高亮标记你的搜索的关键词——ElasticSearch能够做到这件事，且不仅于此；他还提供了强大的数据分析功能：聚合，比如指标聚合中的Max、Min、Avg等典型计算功能，桶聚合中的Terms能统计指定字段的词频。

那么说到ES就不得不提他的底层框架Lucene，市面上大部分的搜索引擎都是基于Lucene实现的。顺便提一嘴创造Lucene的大神道格·卡丁（Doug Cutting），这位也创造了Hadoop（分布式计算框架）、HDFS（高容错分布式文件系统），虽然借鉴了Google算法实现，但也同样伟大。

Lucene是一个全文检索引擎，听起来就像是ES的核心，也确实如此。Lucene提供了关键的分词、倒排索引、匹配搜索功能。

首先要知道“分词”是什么。打比方说我现在要搜索附近的西餐厅，你可能会输入以下的语句：

“附近哪里卖牛排？”

“离我最近的西餐厅？”

如果你完整搜索这句话，估计啥玩意也搜不出来，除非有位和你心有灵犀的人提出了一模一样的问题。但如果把这句话分成许多个有意义的词组再搜索，“离我最近的西餐厅”分解成“最近”和“西餐厅”，就能搜出符合度较高的结果，如愿吃上近处的西餐。分词的作用就是如此，将一个句子分解成一个个有意义的词语。在英语中分词很好实现，因为每个单词间会被空格分隔开，而中文就不好说了，可能由各种词组组成。不过不用担心，咱们China有自己的“IK分词器”，后面我们就会介绍。

那么“倒排索引”又是什么？刚刚我们通过分词，将搜索的语句分成了许多个词语，保存的记录也同样需要分词并保存。例如现在库里有这样几条记录（仅代表个人喜好）：

1：好吃的川菜馆
2：凑合的湘菜馆
3：一般的西餐厅
4：好吃的陕菜馆

这几条数据如果原封不动地放在那里也没法搜索，分词后变成了这样：

1：好吃、川菜
2：凑合、湘菜
3：一般、西餐厅
4：好吃、陕菜

这样以后搜索“好吃”，就能对应到1、4两条记录，但这样好像效率也不高啊，每次搜索遍历每条记录的每个词语。因此我们还需要下一步，将出现过的词语和ID再关联起来，通过词语寻找ID：

好吃：1、4
凑合：2
一般：3
……

现在再搜索“好吃”，就能直接查到这个词语对应的记录啦，再回到文档里寻找id为1和4的记录取出来即可。MySQL的非聚集索引的创建，其实就是上诉创建倒排索引的过程，根据被索引字段的值统计所有值对应的记录id，使用该索引时只需找到id再回表查询对应记录。Lucene的倒排索引不同之处在于，他会对整个文档先进行分词，再对分词的结果创建倒排索引；而MySQL只支持对列的数据创建索引，且不支持全文索引，一般全文搜索都会使用like “%abc%”，效率是令人发指的。MySQL5.7之后支持的全文索引match…against也是基于分词和倒排索引实现的！

至此我们有了分词逻辑，也有了分词后创建得倒排索引，只需要充分用起来即可，便到了最后一步匹配搜索。还是老例子，我们搜索“离我最近的西餐厅”，分词分出了“最近”和“西餐厅”，拿着这两个词去倒排索引里寻找。匹配到“最近”对应的记录1/2/3，“西餐厅”对应的记录2/3/4，可以看到2和3出现了两次，说明这两条记录与我们搜索内容的相关性最高，经过综合打分评估以后，根据匹配度高低返回给用户。

介绍完Lucene后是不是觉得他很强大，ES的核心功能和思想基于Lucene构建，且做了极大地增强。再回到一开始说的天生支持分布式，部署过ES的小伙伴应该知道，配置文件中会让你指定集群名称、主节点名称、集群中子节点名称，可以看得出ES是天生支持集群化和分布式部署的，能够自动进行服务发现和主节点选举。这意味着只要你想，就可以无限上机器来水平扩展。但也不是越多越好哈，分片策略和复制策略也是需要考虑进去的。

ES本身也是极为简单易用的，因为其提供了RESTful API，正如我们认知中，查询文档和索引是GET请求、删除是DELETE请求、修改和发送是POST和PUT。这使得ES的入门和使用变得很简单，只需要学习基本的DSL语法（类似于SQL语句），便可以畅游ES的海洋。

说完了ElasticSearch的种种好处，我们再来总结一下为什么要使用ElasticSearch，再来和关系型数据库老大哥MySQL SOLO一下：

	MySQL	ElasticSearch
存储方式	仅允许单机存储，数据量到达百万级后需要分库分表	分布式存储，使用分片 + replica冗余存储
查询效率	聚集索引查询效率高，非聚集索引查询效率较低，全文匹配效率极低	拥有精准查询、模糊匹配、范围查询等查询方式，全文搜索效率高
分布式支持	支持主从、主主等	天生支持
事务支持	支持ACID四大特性	不支持
其他特性	支持多表关联查询	支持mapping动态映射，支持replica复制分片保证数据完整性，支持聚合计算功能

传统关系型数据库单表数据量达到百万条，操作效率就会大幅降低，而ES能够支持处理PB级别的数据（1PB = 1024TB）。刚刚做了个试验，1000w条记录的表查询非索引字段，搜索时间来到了恐怖的20多秒……但是需要事务或复杂关联逻辑的场景，MySQL一定是最好的，没有下位替代。

2 ElasticSearch基本概念

聊了这么多，气氛也热起来了，该介绍振奋人心的ElasticSearch了，下面我们就来介绍一下ES的基本概念。

2.1 ElasticSearch/Kibana/分词器的安装与部署

这篇之前讲过了哈，有兴趣的小伙伴可以看这篇 -> Linux Java常用服务安装与设置。

2.2 索引 Index

此索引非彼索引，ES中索引的概念类似于MySQL中的表，一个索引便对应着一张拥有完整字段结构约束的表。其实早期的ES索引更类似数据库，其中的Type对应着具体的表，但是这个概念并没有多大意义，反而因为一个Index中多个Type带来了许多困扰，因此在7.0版本被彻底移除。

既然Index类似于一张表，我们肯定要先创建好Index、指定每个字段的名称和类型、然后再做其他操作。但是强大的ES为我们提供了动态映射，就是个什么意思呢，你不用建索引，也不用建字段，你直接告诉他我今天就要往索引A里插一条文档B；然后你会惊奇的发现：

成功了！我事先是没有创建索引的，也可以看到结果的result字段显示“created”，意为索引在此时被创建并插入了文档。这便是ES动态映射带给我的自信，你只管插入，一切都由ES买单。当然，既然是人家自己动态生成的，那你用着也别挑了，咱们来看看索引的结构信息。

{ "testindex" : { "aliases" : { }, "mappings" : { "properties" : { "properties" : { "properties" : { "content" : { "type" : "text", "fields" : { "keyword" : { "type" : "keyword", "ignore_above" : 256 } } }, "introduction" : { "type" : "text", "fields" : { "keyword" : { "type" : "keyword", "ignore_above" : 256 } } }, "title" : { "type" : "text", "fields" : { "keyword" : { "type" : "keyword", "ignore_above" : 256 } } } } } } }, "settings" : { "index" : { "creation_date" : "1681183635630", "number_of_shards" : "1", "number_of_replicas" : "1", "uuid" : "FL9VycRcRIek2WiiXlsS5g", "version" : { "created" : "7050099" }, "provided_name" : "testindex" } } } }

不得不说，ES的动态映射是非常智能的，我们传入的几个字段都是字符串，他便自动帮我们将字段映射设置为了text + keyword类型的复合映射；简单来说就是这个字段既支持全文搜索、又支持精准匹配，是种非常理想的状态，我们自己创建索引时一般也会这样设置。

但还是存在一些问题，在使用text类型时是需要指定分词器的，之前说过ES对于中文的分词支持不佳，毕竟不是全世界都在说中国话；再看看分片策略，也不是很理想，主分片1复制分片1，等于说主数据都存在单节点上，对于单机存储的负载是很大的，且复制分片也只有1个，同时死两台机子这个索引就瘫痪了。因此还是建议自行创建索引，指定分片策略和字段映射等。

2.3 映射 Mapping

映射是索引中非常重要的概念，类似于MySQL中字段的约束，例如数据类型、分词器、是否存储、是否建立索引。其中最重要的就是数据类型，为字段建立合适和数据类型会使你的搜索快上加快。下面就介绍一些常用的数据类型及可配置属性。

2.3.1 text/keyword

text和keyword可以说是ES最核心的两种类型，在早期版本中两者被合并为String字符串类型，后来进行了拆分和优化。text和keyword最大的不同就是是否要分词，text对应需要分词，也就是text字段传入“今天星期四”，就会被分成“今天”和“星期四”两个词供匹配，搜索“今天”或“星期四”都可以匹配到该记录。而keyword字段不会进行分词，放进去什么样保存就是什么样，存“今天星期四”，查也得查“今天星期四”能找到记录。

看起来好像是text功能全面一点，但如果需要保存用户名、手机号这种信息，明显是不需要分词也不会被模糊查询，保存成keyword肯定更合理。且keyword支持聚合而text不支持，因此如果想同时享受聚合和分词查询，就可以设置一个复合类型的字段。

2.3.2 byte/short/integer/long + half_float/float/double

number类型，包括8/16/32/64位整型数，16位半精度/32位单精度/64位双精度浮点数。

2.3.3 boolean/date

boolean很简单，包括true和false。date类型类似于keyword，可以通过指定format来指定日期格式，如"format": "yyyy-MM-dd HH:mm:ss"。

2.3.4 array/object/nested/geo

俺也不会，以后再写。

数据类型介绍完还有几个可配置属性，如index属性可以指定字段是否要建立倒排索引，如果设置为false，再使用该字段进行任何查询都会失败，有些一定不会被作为查询条件的字段可以设置为不建立索引，能够节省磁盘空间。

store属性决定是否要单独存储该字段，一般我们取文档都是从"_source"中读取，那store是干嘛地呢？如果这条文档的字段我们都不想读取，只想看看有没有，就会将“_source”禁用掉，此时ES就只会对文档建立索引而不会保存原数据。但如果你又想要获取其中某一个字段的数据，就可以将store设置为true，在不存储整个文档的情况下，单独存储某个字段（好奇怪…但好吧…）。store属性默认为false，因为已经有source干这个活儿了。

P.S. 但其实我还是感觉怪怪的，因为_source有includes和excludes属性来决定是否保存某些字段，意义不是很明确。

2.4 文档 Document

建立好索引、设置完字段映射，就可以向索引中插入文档了，文档就类似于MySQL中的行数据。插入文档似乎就没什么好说的了，注意点不要写错字段名称就行，由于索引的字段添加后就无法删除，只能增加字段或者给字段追加新类型，一次插入错字段，这个字段就会跟你一辈子。错误次数多了，索引中就会多出很多莫名其妙的字段，只能通过重建索引数据迁移来强行修复，后面会介绍。

3 ElasticSearch的使用

3.1 创建索引

先来创建个索引，如之前所说，需要指定索引名称、索引配置、字段映射，这里仅介绍我使用过的方式。ES提供了RESTful API，使得操作十分清晰，就是一堆HTTP请求，加上请求体中的DSL语句，DSL语法本身其实没什么好介绍的，就是记住然后会用就行。

//创建索引 PUT /testindex { "settings" : { "number_of_shards": 4, "number_of_replicas": 1 } }

执行上面的命令，先建立索引并指定主分片和副分片数量，“number_of_shards”为主分片数量（默认为5），即该索引的数据需要分成多少个分片存储，像我们就设置了4个，就是把数据分成4片放在不同的服务器上；而“number_of_replicas”是副本数量（默认为1），设置为1意为每个主分片都需要有1个复制分片。那么现在这个索引就包含4主分片 + 4副分片共8个分片，且主分片不会保存在同一个机器上，相同的主分片和副分片也不会保存在一个机器上。这点也很好理解，ES为了安全做了这样的数据冗余，如果两个主分片在同一个机器上，这台机器故障就会导致大量数据不可用；如果主分片A和他的副分片在同一台机器上，这台机器故障A分片的所有数据都会不可用。

值得注意的是，主分片数量在设置完成后就不可再改变，而副分片数量是可以改变的，且副分片在查询时也可以被当做主分片分担查询压力。增加主分片和副分片数量固然有许多好处，比如减少单机磁盘占用量，将单机查询请求变为多线程并行请求多个分片，从而提高查询效率，但这并不意味着分片越多越好——副分片多了就意味着插入数据需要同步的分片越多，且查询请求的机器数量多了以后，网络和IO的开销会使得并行查询的效率变低。通俗地说，分片数量和查询效率的提升是对数增长关系，最开始提升分片数量确实会有效率地提升，但达到临界值后反而会降低，物极必反嘛。

//设置字段映射 PUT /testindex/_mapping { "properties" : { "datetime" : { "type" : "date", "format": "yyyy-MM-dd" }, "int": { "type": "integer", "index": true }, "textandkeyword": { "type": "text", "analyzer": "ik_max_word", "fields": { "keyword" : { "type" : "keyword", "ignore_above" : 256 } } } } }

创建好索引后需要指定字段和映射，设置好字段的名称、类型、分词器。例如上面的映射，我们给testindex索引中新增了名为“datetime”、“int”、“textandkeyword”的字段，“type”属性即为该字段的类型，“datetime”字段为“date”类型且指定了保存的格式为“yyyy-MM-dd”；“int”字段类型为“integer”32位整数，还配置了“index”属性意为该字段是否创建索引，默认为true，即默认所有字段都可以参与搜索，如果设置为false该字段就不能参与搜索。

重点想说“textandkeyword”字段，是ES中比较常见的字段类型：复合类型，可以看到他的第一个type为“text”，且指定了IK分词器，意思是这个字段会被分词存储，用于模糊查询和精确查询；但是如果只使用text，会出现精确匹配整个字段会查不到。比如我们给text类型的字段存入“今天星期四”，根据ik_max_word他会被拆分成如下的词语：

//查看分词结果 post /_analyze { "analyzer": "ik_max_word", "text": "今天星期四" } { "tokens" : [ { "token" : "今天", "start_offset" : 0, "end_offset" : 2, "type" : "CN_WORD", "position" : 0 }, { "token" : "星期四", "start_offset" : 2, "end_offset" : 5, "type" : "CN_WORD", "position" : 1 }, { "token" : "星期", "start_offset" : 2, "end_offset" : 4, "type" : "CN_WORD", "position" : 2 }, { "token" : "四", "start_offset" : 4, "end_offset" : 5, "type" : "TYPE_CNUM", "position" : 3 } ] }

拆得很好，很合理，但是唯独少了这句话本身。如果我们要精确匹配“今天星期四”，会惊奇地发现查不到，这就非常不合理了，明明是100%完全匹配的记录却查不到。

因此，在遇到某些完全不需要分词，或者也需要精准匹配、参与聚合的字段，可以设置为keyword类型，或者像上文那样设置成复合字段，既是text又是keyword；需要精确匹配时，单独查询“textandkeyword.keyword”，也就是该字段的关键词类型。keyword可以设置一个“ignore_above”属性，因为这个字段有可能长达500字，我们搜索也不可能暴打500字，因此完全没必要对整个keyword都创建索引；这时就会用到ignore_above，意为这些位数之后的字符我就忽略了，比如上文设置的“ignore_above = 256”，就是256位之后的字符不创建索引，能够大大节省磁盘空间。

创建好索引后，可以用GET /indexname来看看索引的信息：

{ "testindex" : { "aliases" : { }, "mappings" : { "properties" : { "datetime" : { "type" : "date", "format" : "yyyy-MM-dd" }, "int" : { "type" : "integer" }, "textandkeyword" : { "type" : "text", "fields" : { "keyword" : { "type" : "keyword", "ignore_above" : 256 } }, "analyzer" : "ik_max_word" } } }, "settings" : { "index" : { "creation_date" : "1681197581820", "number_of_shards" : "1", "number_of_replicas" : "2", "uuid" : "xcFNjShzSMqM5VwMTD-J3w", "version" : { "created" : "7050099" }, "provided_name" : "testindex" } } } }

很理想，和我们设置得完全一致，这不废话吗。

创建完我们用GET /_cat/indices?v&pretty看看所有索引信息，这个指令也是比较常用的，_cat和Linux里的查看差不多，就是猫一下全局状态；indices是index的复数形式，再加上pretty修饰词，意思是展示得美丽一点。

health status index uuid pri rep docs.count docs.deleted store.size pri.store.size yellow open testindex xcFNjShzSMqM5VwMTD-J3w 1 2 2 0 3.7kb 3.7kb green open .kibana_task_manager_1 85dqt05XTf2hmQloPVxCgg 1 0 2 0 31.6kb 31.6kb green open .apm-agent-configuration WKEsv_oGQhSeva9aXSw72A 1 0 0 0 283b 283b yellow open user 7orJbC_KQoa-Dkax9TDLzA 1 1 7 0 5.4kb 5.4kb green open .kibana_1 cB0TGuF1TMSSIJvrn436FA 1 0 14 1 46.9kb 46.9kb yellow open article 1lelxTi1TxC1tyHhG0ugwg 1 1 2 0 9.7kb 9.7kb yellow open user_new cIKcpMZJThSk-5E6m4H-lQ 1 1 5 0 5.1kb 5.1kb green open .tasks goX4wT5ETtaHFQT3KHQV8A 1 0 3 0 18.5kb 18.5kb

看到这有人就有疑问了，为啥那个“health”字段有人是yellow有人是green呢？还有亚健康的索引库？这得说回我们刚设置的主分片和副本分片，一般情况下会均分在集群中不同的服务器上，尴尬的是我整个集群内一台机器，就那主分片和副分片就只能都放这一台机子上了。这就会造成数据实际是没有任何冗余的，机器不可用就会导致整个索引数据不可用，所以就呈现了“yellow”的亚健康状态。细心的小伙伴也可以观察出来，pri/rep（primary主分片/replica副本分片）加起来是1的索引就是“green”完全健康状态，因为他们不需要将数据分布存储，只需存在一台机子上即可。

3.2 插入/修改/删除文档

插入和修改实际上差不太多，就是输入对应索引结构的json字符串嘛，因此合并在一起说。

插入文档语法是PUT /indexname/_doc/id，请求体是数据json，记住要符合字段映射，比如刚刚datetime字段指定了format为“yyyy-MM-dd”年月日，如果我们插入年月日时分秒，就会报"mapper_parsing_exception"，并告诉你你插入的数据和指定的格式不同，解析失败所以插入失败了；且不要插入不存在的字段，不然时间久了你的索引会出现一堆你不认识的字段。来个正确的插入示例：

PUT /testindex/_doc/3 { "datetime": "2023-04-12", //要符合format和数据类型 "int": 11, "textandkeyword": "你好吗" }

修改文档有两种修改方式，第一种是直接覆盖，第二种是只修改某些字段。覆盖就类似于重新插入整个文档，所以和插入文档语法一样使用PUT，id换成需要覆盖的文档id即可。只修改某些字段语法不太一样但也大差不差，要用POST /indexname/_update/id，请求体只写要修改的字段和值即可，注意外面还要套一层“doc”。

POST /testindex/_update/1 { "doc": { "int": 1234 } }

删除就不用多说了吧？DELETE /indexname删索引，DELETE /indexname/_doc/id删文档。

3.3 查询文档

重头戏来了，ElasticSearch既然是搜索引擎，那查询搜索自然是他最强大的核心功能，下面我们来重点介绍各种查询文档的方法。首先要记住，ES中所有查询指令都是GET /indexname/_search，这个是基础中的基础哈。

3.3.1 ids 根据ID批量查询

每个文档插入时都会指定或生成一个id，类似于关系型数据库的主键，最基础的就是根据id来查询；且这个查询是批量的，可以输入ids列表。

GET /testindex/_search { "query": { "ids": { "values": [1, 2, 3] } } }

如上述指令，所有查询最外层都要包一个“query”，再往内就是我们用到的“ids”查询，指定values列表[1, 2, 3]就可以查询到id为1/2/3的文档。

3.3.2 match 匹配查询

match查询会先将查询条件进行分词，再将分词后的词语与对应字段进行匹配，一般用于text类型的模糊查询。比如我输入“今天星期四”，就会去字段里查找含有“今天”或“星期四”的文档再返回。match大家族有许多成员，我们挨个介绍。

基础的match查询除了可以输入字段名和字段值以外，还有几个额外的属性：

GET /testindex/_search { "query": { "match": { "textandkeyword": "今天星期五" } GET /testindex/_search { "query": { "match": { "textandkeyword": { "query": "今天星期五", "operator": "and", "minimum_should_match": 2 //operator为or时设置 } } } }

如上述代码，第一种是基本形式，直接输入字段键值对，分词后进行匹配查询；“今天星期五”被ik_max_word神功分成了“今天”、“星期五”、“星期”、“五”，和索引中的“今天星期四”明显是可以匹配的，因此能查询到。

再来看看第二种形式，除了字段值query属性，我们还设置了“operator”和“ minimum_should_match”，这俩是干嘛的？刚刚介绍match查询会先对查询条件进行分词，可能会被分成毛毛多的词语，默认情况下只要匹配到其中一个词语就算你匹配成功，但如果我们需要相关度很高的结果呢？再回到例子中，如果我就想搜索星期五相关的文档，默认的搜索方式却将“今天星期四”也搜索出来了，是不是不太合理呢？

这时operator就闪亮登场了，这个属性意思是匹配操作类型，默认为or，逻辑或匹配；分词结果中任何一个词语匹配上了，都会返回结果。我们将其设置为and，就成了逻辑与匹配，所有分词都能匹配到的文档才能返回。用and搜索时，就搜不到今天星期四对应的文档了。

但这种方式又有些过于极端，用户一般不会用那么精准凝练的语言来搜索，但凡句子里带点废话就啥也搜不到了。这种情况就可以使用较为折中的minimum_should_match，意为最少应该匹配到词语，默认为1，顾名思义最少匹配到1个词语就认为是符合的，等同于逻辑或。我们将其设置为2，就又能匹配到星期四的文档了。不过要注意的是，minimum_should_match只有在operator为or时才能使用，为and时就要全部匹配上，设置这个值也没啥意义，反而会导致啥也查不到。

match_all就是查询索引库中所有文档，只会默认返回10条，可以通过指定size来指定查询条数，也可以自定义一下排序规则；但由于ES的保护机制，单次返回不能超过10000条，可以通过配置来改变最大条数或使用滚动查询，后面我们会介绍。

GET /testindex/_search { "query": { "match_all": { } }, "size": 100, "sort": [ { "datetime": { "order": "asc" } } ] }

multi_match为批量查询，可以同时指定多个字段，并在这些字段内进行匹配，match则只能在对应一个字段内进行匹配搜索。

GET /textindex/_search { "query": { "multi_match": { "query": "今天", "fields": ["title", "introduction", "content"] } } }

match_phrase短语匹配是一种更为精准的查询方式，这种查询方式需要匹配到所有的分词，且每个词的顺序要与文档中词语顺序保持一致。如文档为“今天星期四”，如果搜索“星期四今天”就搜索不到，因为虽然所有词都能匹配上，但是一个顺序是“今天”、“星期四”，一个是“星期四”、“今天”，不满足短语匹配的条件。

GET /testindex/_search { "query": { "match_phrase": { "textandkeyword": { "query": "星期四今天" //顺序不同，查询不到！！！ } } } }

match_phrase_prefix和match_phrase比较类似，只是会给最后一个分词加上指定数量的通配符。举个例子，“喜欢吃”被分词后为“喜欢”、“吃”，match_phrase_prefix会搜索“喜欢” + “吃*”，这个“*”是代表任意字符的通配符，那么我们就可以搜索到“喜欢吃饭”、“喜欢吃菜”。属性“max_expansions”是最后一个词后面通配符的数量，默认为1，也就是“吃*”，也可以设置为自己的幸运数字，但由于性能不佳不太常用。

GET /testindex/_search { "query": { "match_phrase_prefix": { "textandkeyword": { "query": "今天星期", "max_expansions": 10 } } } }

上面的查询就能查到“今天星期四”对应的文档，而match_phrase不能，因为搜索的是“今天” + “星期********”。

3.3.3 term 精准查询

term查询不会对查询条件进行分词，即你输入什么查询条件就是什么，更多用于keyword类型的查询，因为keyword也不会被分词，可以精确匹配到文档。还有terms查询，可以输入多个查询条件同时在字段中搜索。

//term单条件 GET /testindex/_search { "query": { "term": { "textandkeyword.keyword": "今天星期四" } } } //terms多条件 GET /testindex/_search { "query": { "terms": { "textandkeyword.keyword": ["今天星期四", "你好吗"] } } }

要注意的是，term查询最好使用在keyword类型的字段上，就像我们之前说的，text类型会对字段进行分词存储，不会存储字段本身；而term查询又不会对查询条件进行分词，追求的就是高精准度，text类型显然没法满足。

3.3.4 range 范围查询

range查询用于范围查询，如查询某个日期范围内、某个价格区间内的文档，有gt/gte/lt/lte（大于/大于等于/小于/小于等于）四种逻辑符。

GET /testindex/_search { "query": { "range": { "datetime": { "gte": "2023-04-11" } } } }

3.3.5 bool 布尔查询

在日常的搜索中条件不可能只有一个，通常是将多个条件组合起来查询，类似SQL语句中的“WHERE a AND b AND c”，这时就可以用bool查询来拼接条件。

bool中含有must/should/must_not/filter：

must：必须满足该条件，会进行分值计算。
should：分含有must条件和不含must条件两种情况，在不含must条件时，只要满足should条件就会返回该文档；含有must条件时，满足should条件的文档会加分，说明相关性更高，返回的优先级也会变高
must_not：必须不满足该条件。
filter：必须满足该条件，但他不会进行分值计算，且常用filter会被缓存，非常推荐使用！能使用filter代替must的场景，尽量都使用filter。

来一个示例，现在要查询date为2023-04-12之后的、textandkeyword为“你好吗”的文档，可以使用两种方式来拼接条件：

GET /testindex/_search { "profile": "true", "query": { "bool": { "must": [ { "term": { "textandkeyword.keyword": { "value": "你好吗" } } }, { "range": { "datetime": { "gte": "2023-04-12" } } } ] } } } GET /testindex/_search { "profile": "true", "query": { "bool": { "must": [ { "term": { "textandkeyword.keyword": { "value": "你好吗" } } } ], "filter": { "range": { "datetime": { "gte": "2023-04-12" } } } } } }

开启profile来查看一下两种方式的执行计划和耗时，可以看到不使用filter和使用filter的耗时相差确实很大。首先是因为filter不需要计算分数，满足条件就过不满足就爬；其次是常用过滤器会被缓存，但是第一次查询可能看不出效果，甚至must查询可能快于filter，但是第二次使用该filter条件时速度就会全方位领先。

不使用：
"time_in_nanos" : 303220

使用：
"time_in_nanos" : 166729

分页查询是非常常用的功能，用户也不想一次性看一万条记录。ES提供了两种分页方式，一种是from + size分页查询，一种是scroll滚动查询。

最常用的是用from + size，类似于SQL中的“LIMIT offset, rows”，from是开始读取的位置，size是需要读取的条数。from默认0，size默认10，意思是返回查询到的前10条，用起来还是比较简单方便的，但是存在几个问题。

这里就要先介绍两个知识点，深分页和ES的分页机制。拿MySQL的深分页问题举例，偏移量小的时候效率还是较高的，比如“LIMIT 100, 100”取第100到第200条数据，只需要查出200条再截取后100条返回。但是这种查询方式其实埋了个大雷，如果是“LIMIT 1000000, 100”，就意味着要查出1000100条记录再取后100条，服务端CPU要持续查，再一股脑塞进内存中。

知道深分页问题后，再了解一下ES分页机制，MySQL的查询是单机查询，一张表的记录只会从一台服务器的磁盘中读取；而ES就不一样了，ES是一个分布式搜索引擎，索引会被分片并存储在不同的服务器上。他遇到分页查询请求时，会从所有服务器的分片中获取符合查询条件的文档，再根据分页参数获取目标条数的文档，最后合并、排序、截取所需文档。

这样说可能还是不太明晰，来模拟一下ES的分页查询过程：

索引主分片数为4，分布在4台机器上。
构建查询条件，分页参数，如term查询 + from 10, size 10。
在4个分片中查询符合term条件的文档，并选取前10 + 10 = 20条。因为分页参数为从第10条开始向后取10条，因此需要查询20条才能满足。
合并到某一主节点进行排序，再取前20条。
根据分页参数，从第10条开始截取后10条文档。

了解了整个过程以后，我们来算算一共取了多少条文档。4个节点每个取20条一共80条，排序后再取10条。现在看起来这个数字并不大，如果from是100000，就起码要获取400000条，显然内存很容易会被打满，且每个分片传这么一堆文档网络开销也是巨大的，更不用说CPU哼哧哼哧搁那查了。

ES也深谙其道，你这分页参数大了我不得死啊？因此限制了from不能大于10000，你往10000条文档以后分页他就认为你在深分页，你别分了我不让。但万一我就要是10000条以后的数据，你总不能不让我看吧？当然也是有解决方案的。

一种是使用索引属性“index.max_result_window”解除限制，强行提高结果窗口最大值，默认不10000吗？我就给你整个100000。但是治标不治本，看是能看到了，但你也没考虑过服务器的死活，我们肯定是要寻找一种更美丽的方式的。

scroll滚动查询就出现了，这种查询方式和之前文章介绍的游标查询比较类似，就是指定一个类似fetchSize的值，服务端查好放那客户端分批取。scroll就更智能了，在你首次发起滚动查询时，会将所有符合条件的文档的id存放在内存中，再根据设置的size每次返回一部分给你，返回一次游标往后滚动一点，已经返回给你的文档id就被移除掉。且scroll还设置有过期时间，在一定时间没有使用该scroll且没有续期后，就会自动移除该scroll上下文来释放内存。

那有人就会问了，那这scroll也挺占吃内存啊，听起来效率也不是很高啊？再来和from + size方式对比一下，from + size每次查询都是一次独立的查询，意味着你翻10次页，同样的查询条件会重复10次，且获取的文档数会随着页数变深指数级变大；而scroll存放在内存中的是所有符合条件的文档id，那么只要你使用的是同一个scroll且他没有过期，每次向后滚动只会拿到id去索引里查对应文档。文档和单个id占用的内存大小自然是文档占用大，每次都重复查询term这个动作scroll也省去了，而且用id查询的效率自然是极高的——想想MySQL聚集索引和非聚集索引的区别，非聚集索引要回表和聚集索引不用，直接取就是对应记录。

这么一对比差距就很明显了吧？所以在大数据量查询场景下，我们最好是使用scroll滚动查询，一般用户的分页还是用from + size，因为scroll并不能支持指定页数的查询，只能一直滚啊滚。

scroll的使用方法就是在第一次查询时，在查询命令后面加上“?scroll=10m”，意为这次查询需要使用滚动查询，且过期时间为10分钟；方法体内指定每次查询条数size（size不可以超过10000，也就是查询窗口最大值），发起请求后会响应相对数量的文档，并额外返回一个“_scroll_id”，下次查询直接用这个id进行查询，便可以在该scroll未过期、且数据未查询完以前一直滚动。不过记得要续期哦，不然scroll过期了而你还没查完，他就不见了。

//传统分页 GET /testindex/_search { "query": { "match_all": { } }, "from": 0, "size": 100, "sort": [ { "datetime": { "order": "asc" } } ] } //滚动查询1，返回了： //"_scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAA88Wdjl2dW9EZzlTTHVoX3BfbzdvR0NFQQ==" GET /testindex/_search?scroll=10m { "query": { "match_all": { } }, "size": 1, "sort": [ { "datetime": { "order": "asc" } } ] } //滚动查询2，直接使用该scroll并续期 GET /_search/scroll { "scroll": "10m", "scroll_id": "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAA88Wdjl2dW9EZzlTTHVoX3BfbzdvR0NFQQ==" }

3.4 聚合 Aggregation

基本的增删改查说完了，还记得我们最开始说ES是搜索和数据分析引擎，现在光看到搜索了没看到数据分析，而聚合就是数据分析功能。聚合类似于MySQL的GROUP BY + 各种计算函数（sum/max/min等），对符合条件文档对应字段的值、或是脚本计算后的结果（比如一条文档中两个字段的值相加、某个字段的值乘以2倍、多个字段值求平均值）进行计算和分析。但是不建议用自定义脚本，效率很低容易给自己挖坑。常用的聚合被分为四大类：指标聚合、桶聚合、矩阵聚合和管道聚合，矩阵聚合被ES官方标记为实验性功能，未来可能会被更改或删除，因此不作介绍；管道聚合是对已计算出聚合结果的增强，属于高阶应用此篇不作介绍。本文仅介绍常用的指标聚合和桶聚合。

指标聚合主要作用于Number类型字段，一般用于计算和统计数据，如求最大值、最小值、平均值等。拿求最大值举例，对索引的“price”字段求中Max聚合，对应到SQL语句就是“SELECT MAX(price) FROM `stuff_info` GROUP BY stuff_type”，简单解释一下就是根据商品种类，求每个种类价格的最大值。

桶聚合作用就不太一样了，顾名思义桶聚合会将文档放进一个一个桶，有几个桶、每个桶放怎么样的文档，就要看使用哪种桶聚合、根据哪些查询条件了。

先来看看聚合的基本语法，从最外层向最内层介绍：

GET /indexname/_search { "aggs": { "custom_name1": { "agg_type": { "field": "column_name1" } }, "custom_name2": { "agg_type": { "field": "column_name2" } } } }

最外层的“aggs”是必须加的，表示该键值对里面的内容为聚合计算。
然后是“custom_name1”和“custom_name2”，意为自定义的聚合结果名称，因为我们可能会进行多个聚合运算，返回结果时需要显示名称。
“agg_type”就是ES提供得各种聚合，例如sum/min/max等，我们要告诉ES我们要使用哪种聚合功能嘛。
“field”内为需要做聚合的字段名称。

上面介绍得是最基础的聚合语法，还可以在聚合结果内再次聚合，例如我们先用Term聚合把每个商户文档塞到各自的桶里，再用Sum聚合求商户总营业额。

下面介绍常用的指标聚合和桶聚合。

3.4.1 最大值 Max

最大值聚合，求指定字段中的最大值。

3.4.2 最小值 Min

最小值聚合，求指定字段中的最小值。

3.4.3 平均值 Avg

平均值聚合，求指定字段的平均值。可以通过指定“missing”属性来设置默认值，该字段没有值的文档会使用设置得默认值。

3.4.4 求和 Sum

求和聚合，求指定字段值的总和。

3.4.5 求文档数 Value Count

求文档数聚合，这个听起来比较抽象，其实就是求指定字段有值的文档数。比如有些文档有“sexual”字段值，有些没有，计算sexual字段的Value Count，就可以计算出有该字段的文档数量。

3.4.6 去重统计 Cardinality

去重统计聚合，先对指定字段去重，再计算字段共有多少种值。

3.4.7 基本数据统计 Stats（Statistics）

基本数据统计聚合，能够一次计算出该字段的max/min/avg/sum/count并返回。

3.4.8 拓展数据统计 Extended Stats

扩展数据统计聚合，在基本数据统计的基础上增加了sum_of_squares（平方和）、variance（方差）、std_deviation（标准差）、std_deviation_bounds（平均值加/减两个标准差的区间）。

3.4.9 百分位统计 Percentiles

百分位统计聚合，会先将字段值进行DESC排序，并计算对应百分位的数据大小。

如统计学生成绩score字段，排序后发现记录100%处的分数为60分，50%处为80分，10%处为90分。这意味着100%的人达到了60及格线，50%的人能达到80分以上，仅有10%的人能获取90分以上。这就是百分位统计的含义，默认百分位为1.0/5.0/25.0/50.0/75.0/95.0/99.0%，也可以设置“percents”: [50, 100]，来指定查看百分位。

3.4.10 百分位排名统计 Percentiles Ranks

百分位排名统计聚合，和上面那位正好相反，上面是给出百分比，返回百分比所处的数据；这个是给出数据，返回数据所处的百分比。

比如“您的等级已超越80%用户！”，这句话眼熟吧？我们现在的等级“Level”为80，通过Percentiles Ranks就可以计算80在Level这个字段中属于什么百分位。输入80，返回20.00，说明我们处于前20%，超越了80%用户。

常用指标聚合到这就介绍完了，下面来介绍桶聚合。

3.4.11 词频聚合 Terms

统计对应字段词频，每个词对应一个桶，每次遇到对应的词就扔进对应的桶，最后根据桶数量从大到小返回前10个桶的词频大小。可以通过设置size控制返回桶数量的大小，还可以设置order来自定义文档排序规则，默认为“_count”从大到小排序。

3.4.12 过滤器聚合 Filter/Filters

过滤器聚合和bool查询中的filter差不多，可以把符合条件的文档放进一个桶里，也可以设置多个过滤器对应多个查询条件，将文档放在多个桶里。

3.4.13 范围聚合 Range

范围聚合类似于range查询，可以查询对应字段对应范围内的文档，并放在该范围的桶中，可以同时创建多个桶并设置“from + to”（注意是左闭右开哈），符合条件的文档就会放进对应的桶并返回。

3.4.14 缺失值聚合 Missing

用于统计该字段没有值文档的数量，比如排查数据时，有些字段本不应为null却出现了没有值的异常现象，就可以通过该聚合排查这种异常现象出现的场景和频次。

3.4.15 命中文档聚合 Top Hits

Top Hits也是个很好用的聚合，来看这样一种场景，我们需要分析销量最高商品品类的记录，那首先需要用Terms聚合，对商品品类字段进行词频统计，计算出出现频率最高的品类为“食品”。但是Terms聚合只会返回词频，不会返回其他任何信息，而我们得拿到食品类中一部分信息进行分析。

此时就有几个方案，如再次嵌套一个其他类型聚合，或者直接拿到这个桶里的文档。那显然直接拿文档在程序中分析比较方便直观，这时就可以用到Top Hits聚合，该聚合会直接返回桶里的文档，我们可以指定返回前1000条拿出来分析，是不是很好使。

下面这个例子为获取词频最高记录下所有文档。

GET /user/_search { "aggs": { "agg1": { "terms": { "field": "location.keyword", "size": 1, "order": { "_count": "desc" } }, "aggs": { "agg1inside": { "top_hits": { "size": 10 } } } } } }

3.5 多余字段的删除

记得我们前面提到的ES会对字段进行动态映射，插入不存在字段时会自动创建该字段并进行动态映射，但误操作创建得字段总不能就在那放着吧，前文提到ES的索引是不支持删除字段的，只能用曲线救国的方式来删掉多余的字段。需要以下几步：

创建一个副本索引myindex_temp，使用正确的索引设置和映射。
使用脚本删除原索引myindex中，误操作新增字段所有的值。如新增了wrong_column，则需要删除所有文档wrong_column对应的数据，因为如不删除，备份索引数据时会再次插入该错误的字段。
使用reindex将myindex中的数据同步到myindex_temp中，此时myindex_temp便有着正确的映射结构和文档数据。
删除myindex，创建一个新的myindex并使用正确的索引设置和映射。
将myindex_temp中的数据同步到myindex中，此时myindex便有着正确的映射结构和文档数据，问题解决了。

其实第4步也可以不用那么麻烦，直接给myindex_temp设置别名，即可当原来的索引库使用，可以节省一次数据同步的过程，毕竟索引库很大的话同步也是需要时间的，但这种方式仍然容易混淆，看大家如何考量了。使用这种方法也是无奈之举，ES严格要求了不允许删除字段，因此还是插入文档得时候多注意吧。

//删除多余字段的值 POST /test1/_update_by_query { "script": "ctx._source.remove('{wrong_column}')", "query": { "bool": { "must": [ { "exists": { "field": "wrong_column" } } ] } } } //同步数据 POST /_reindex { "source": { "index": "test1" }, "dest": { "index": "test1_temp" } }

4 整合SpringBoot

上面我们已经介绍完了ElasticSearch所有的基础操作，所有的操作都是在Kibana里，最终肯定要将其整合进我们的Web应用中。ElasticSearch的集成主要使用到了ES的高阶客户端“elasticsearch-rest-high-level-client”，在Maven中引入下面的依赖即可，一定要与所使用的ES版本一致。

<!-- ES的高阶的客户端API --> <dependency> <groupId>org.elasticsearch.client</groupId> <artifactId>elasticsearch-rest-high-level-client</artifactId> <version>7.5.0</version> </dependency>

得益于SpringBoot的自动配置，只需在yml文件中指定ES服务的ip地址即可以集群模式连接，但我们只有一台服务器，只配置一个就好。

spring: elasticsearch: rest: uris: http://192.168.8.8:9200

配置完就可以愉快地使用RestHighLevelClient操作ES服务器了！通过下面的使用，可以发现其实这个客户端也是在帮助大家组装DSL语句，这使得发出一个完整的命令就如同使用Kibana编写DSL语句一样丝滑。按照上文介绍的ES使用方法，我们用RestHighLevelClient重新实现一次。

4.1 创建索引

所有操作进行之前，都要先引入RestHighLevelClient！因此我们先注入他。

 @Autowired private RestHighLevelClient client;

想想之前使用语句是如何创建索引的：

指定索引名称 -> 设置索引属性 -> 创建映射 -> 创建完成

在高级客户端中也不例外，所有的操作都是先创建请求、构建请求体、使用客户端发送请求、接收响应结果，无非是不同的操作对应不同的请求方式，下面我们便要介绍创建索引使用得请求类型“CreateIndexRequest”。

由于绝大部分操作都要落到对应的索引库上，因此请求类需要设置索引库名称，可以通过构造方法指定，也可以通过调用方法来指定。在初始化CreateIndexRequest时便指定了待创建索引的名称，接下来则需要指定索引属性，手动设置主分片数和副本分片数；ES提供了快捷构造Settings的方法，其内部实现其实就是TreeMap，放置属性对应的键值对即可，在此不作赘述。

下面是创建映射，其实也没什么难点，整个过程就是在构建请求体的json字符串，Kibana里怎么写这里还怎么写就行，有兴趣的小伙伴可以debug一下代码，看看整个请求体构建得过程和参数。要记得告诉客户端你使用得参数类型供解析，我们这里为“XContentType.JSON”。

看看代码实现：

 @PostMapping("/createIndex") public Result<?> insertUserDetail(@RequestBody JSONObject json) { if (json.isEmpty()) { return Result.error("请指定索引信息"); } if (Strings.isNullOrEmpty(json.getString("shards"))) { return Result.error("请自定义分片信息"); } if (Strings.isNullOrEmpty(json.getString("replica"))) { return Result.error("请自定义分片信息"); } String indexName = json.getString("indexName"); if (Strings.isNullOrEmpty(indexName)) { return Result.error("请设置索引名称"); } //创建请求 CreateIndexRequest request = new CreateIndexRequest(indexName); //配置分片信息 Settings setting = Settings.builder() .put("index.number_of_shards", 1) .put("index.number_of_replicas", 1) //指定索引默认分词器 //.put("index.analysis.analyzer.default.type", "ik_max_word"); .build(); request.settings(setting); //配置映射信息 String mappingString = json.fluentRemove("shards") .fluentRemove("replica") .fluentRemove("indexName") .toString(); request.mapping(mappingString, XContentType.JSON); //这种方法在组装映射属性时太复杂，不推荐 //LinkedHashMap<String, Object> map = Maps.newLinkedHashMap(); //json.entrySet().forEach(a -> { // String key = a.getKey(); // String value = a.getValue().toString(); // map.put(key, value); //}); try { CreateIndexResponse response = client.indices().create(request, RequestOptions.DEFAULT); boolean acknowledged = response.isAcknowledged(); boolean shardsAcknowledged = response.isShardsAcknowledged(); //boolean fragment = response.isFragment(); if (acknowledged && shardsAcknowledged) { return Result.ok("ok"); } else { return Result.error("创建索引出现异常"); } } catch (IOException e) { log.error("创建索引 {} 出现异常: {}", indexName, e); return Result.error("创建索引出现异常"); }

上述代码还包括了入参校验等，整个过程清晰明了，就是在创建对应请求 -> 构建请求体 -> 利用客户端发送请求 -> 获取响应，最后在响应中获取一下是否创建成功即可。唯一需要注意的是使用客户端对应的操作，这个也好理解。

创建索引：client.indices().create()

插入文档：client.index()

查询文档：client.search()

我们写好请求体利用Postman发送请求：

{ "indexName": "test1", "shards": 1, "replica": 1, "properties": { "username": { "type": "keyword", "index": true }, "sexual": { "type": "short", "index": false }, "location": { "type": "text", "index": true, "analyzer": "ik_smart", "fields": { "keyword": { "type": "keyword", "index": true } } }, "phonenumber": { "type": "keyword" } } }

发送请求后返回了个ok，再去Kibana看看索引信息，一点毛病没有。

{ "test1" : { "aliases" : { }, "mappings" : { "properties" : { "location" : { "type" : "text", "fields" : { "keyword" : { "type" : "keyword" } }, "analyzer" : "ik_smart" }, "phonenumber" : { "type" : "keyword" }, "sexual" : { "type" : "short", "index" : false }, "username" : { "type" : "keyword" } } }, "settings" : { "index" : { "creation_date" : "1681680443532", "number_of_shards" : "1", "number_of_replicas" : "1", "uuid" : "EGJn10oKQGetDwrK_spIiw", "version" : { "created" : "7050099" }, "provided_name" : "test1" } } } }

4.2 插入/修改/删除文档

插入文档对应的是IndexRequest，指定索引库名称，构建插入文档json，想指定文档id就调用id()方法传入，不想就让客户端自动生成。

修改和删除文档的请求是UpdateRequest和DeleteRequest，就是这么简单。修改指的是增量修改，覆盖修改和插入文档操作一致，指定被覆盖的文档id即可；指定id和需要修改的字段doc，这个doc就是在构建IndexRequest，其中包含了需要修改字段的键值对。删除则只需传入文档id即可。

 @PostMapping("/insertUserDetail") public Result<?> insertUserDetail(@RequestBody EsUser user) { //指定索引库名称进行操作 IndexRequest indexRequest = new IndexRequest("user"); indexRequest.source(JSONObject.toJSONString(user), XContentType.JSON); //更新文档 //UpdateRequest updateRequest = new UpdateRequest(); //updateRequest.id(id); //updateRequest.doc(); //client.update(updateRequest, RequestOptions.DEFAULT); try { client.index(indexRequest, RequestOptions.DEFAULT); } catch (IOException e) { log.error("插入user索引出现异常: {}", e); return Result.error("插入user索引出现异常"); } return Result.ok("ok"); }

4.3 查询文档

查询文档使用SearchRequest，和其他操作唯一的不同点就是要构建查询条件，说到底其实也是用ES API来组装条件json。整个过程就是创建查询请求、构建查询条件、发送请求、获取响应，是不是很眼熟？所以说RestHighLevelClient的使用很丝滑便捷，所有请求的结构都是一致的。

用match_all查询一下索引中所有的文档，先创建查询文档请求并指定索引、构建查询源、构建match_all查询条件、将查询条件传入查询源、将查询源传入查询请求、使用客户端发送请求。整个过程用代码实现一下：

 @PostMapping("/queryAllUser") public Result<?> queryAllUser() { //指定索引库名称进行操作 SearchRequest searchRequest = new SearchRequest("user"); //组装查询条件并赋值 SearchSourceBuilder search = new SearchSourceBuilder(); //match_all //MatchAllQueryBuilder builder1 = QueryBuilders.matchAllQuery(); MatchAllQueryBuilder builder = new MatchAllQueryBuilder(); search.query(builder); searchRequest.source(search); try { SearchResponse response = client.search(searchRequest, RequestOptions.DEFAULT); SearchHits hits = response.getHits(); HashMap<String, Object> resMap = Maps.newHashMapWithExpectedSize(2); LinkedList<EsUser> resList = Lists.newLinkedList(); for (SearchHit hit : hits.getHits()) { String str = hit.getSourceAsString(); log.info("hit: {}", str); EsUser esUser = JSONObject.parseObject(str, EsUser.class); resList.add(esUser); } resMap.put("count", hits.getTotalHits()); resMap.put("data", resList); return Result.ok(resMap); } catch (IOException e) { log.error("查询user索引出现异常: {}", e); return Result.error("查询user索引出现异常"); } }

match_all方法的构建可以使用QueryBuilders建造器或者直接new，建造器里集成了所有查询方法，使用起来方便好记一些。构建好MatchAllQueryBuilder后传入SearchSourceBuilder，查询条件便组装好了，将组装后的查询条件传给查询请求，就可以获取到相应结果。

response中我们可以获取很多有用的信息，最重要的便是查询命中文档SearchHits，从其中可以拿到命中文档列表SearchHit[]，遍历该列表就可以获取命中文档。获取json字符串形式的文档source并解析成实体类，再想怎么使用就怎么使用吧。

再来构建个复杂一点的查询方法，我们构建个bool查询方法，创建terms查询并作为过滤器传入bool。但是看到代码大家会发现，整个逻辑也就那么回事，就是把json转换成调用API。

 SearchRequest request = new SearchRequest(); request.indices("user"); SearchSourceBuilder builder = new SearchSourceBuilder(); //filter条件构建 BoolQueryBuilder bool = new BoolQueryBuilder(); TermsQueryBuilder terms = new TermsQueryBuilder("location", locations); bool.filter(terms); builder.query(bool); request.source(builder);

整了这么些我们把Kibana请求写法和API写法对比一下，先写一个完整的请求体，包括了查询方法、分页参数、排序方法。

GET /testindex/_search { "query": { "match_all": { } }, "from": 0, "size": 100, "sort": [ { "datetime":{ "order": "asc" } } ] }

再对应到高阶客户端API。

 //指定索引库名称进行操作 SearchRequest searchRequest = new SearchRequest("user"); //组装查询条件并赋值 SearchSourceBuilder search = new SearchSourceBuilder(); MatchAllQueryBuilder builder = new MatchAllQueryBuilder(); search.query(builder); //分页参数 Integer pageSize = json.getInteger("pageSize"); Integer pageNo = (json.getInteger("pageNo") - 1) * pageSize; search.from(pageNo).size(pageSize); search.sort("datetime", SortOrder.DESC); searchRequest.source(search);

对比一下得出了以下几点：

GET /indexName/_search等各种索引操作类型，对应了SearchRequest的创建，创建了操作类型和操作索引。
最外层大括号，即整个请求体，对应了SearchSourceBuilder。
查询方法、分页参数、排序规则等的创建，即是在填充SearchSourceBuilder。
具体的查询方法，例如match_all，对应了MatchAllQueryBuilder等一众查询方法。

你能想到ElasticSearch的所有操作，都能用RestHighLevelClient实现！以后再构建请求时只需要记住，把该加的东西加在正确的地方。那我们再举一反三一下，用滚动查询时应该如何构建？Kibana里指定滚动查询是在GET方法后面加上?scroll=10m，刚刚说指定请求是使用SearchRequest，其中也确实有个scroll()方法来指定滚动查询生效时间，可以说是一通百通了。

//创建游标查询，指定存活时间 searchRequest.scroll(new Scroll(new TimeValue(10, TimeUnit.MINUTES)));

4.4 聚合

最后来介绍聚合在高阶客户端中的实现，和查询流程其实差不多，也是构建聚合再传入，主要讲讲如何获取聚合结果。我们先构建个Terms聚合，从response中获取聚合结果集合看看。

 //bucket聚合构建，词频统计 TermsAggregationBuilder agg = AggregationBuilders.terms("location").field("location.keyword"); builder.aggregation(agg); request.source(builder); //获取聚合结果 List<Aggregation> aggregations = response.getAggregations().asList();

试着遍历这个集合，你会发现没法从里面的Aggregation获取任何有用的信息。这是为啥？由于我们可能会创建很多个聚合，而聚合又有毛毛多的种类，ES显然不愿意每个聚合类型都提供一个GET方法，而是鼓励大家获取每个聚合结果后自行作类型转换——首先是因为Aggregation是所有聚合类型的父类，直接转换不会出现编译错误。其次是这种方式胜在操作者心知肚明，根据自定义的聚合名称获取聚合，再转换成使用得聚合类型，风险是相对较小的；假定你使用了Terms聚合，却不小心使用了比如getSum()（不存在这个方法！！！是虚构的！！！）获取了Sum聚合，编译期不会出现问题，在获取结果时因为我们使用的聚合根本不是Sum，运行时就可能会引起bug，最好还是将bug暴露在编译期哈。

举个栗子，我们使用Terms聚合来统计地区词频，如果传入location参数统计指定地区、不传入则统计所有地区。即下面这段代码逻辑，如果指定地区就构建filter并传入，先查询再对查询结果进行聚合。

 //如指定地区则返回指定地区 //未指定则返回所有地区 String location = json.getString("location"); if (!Strings.isNullOrEmpty(location)) { log.info("查询指定地区"); BoolQueryBuilder bool = new BoolQueryBuilder(); TermQueryBuilder term = new TermQueryBuilder("location.keyword", location); bool.filter(term); builder.query(bool); }

Terms聚合结果里有许多个桶Bucket，Bucket里存放了字段名和词频，我们构建Terms聚合并获取结果组装返回。

//bucket聚合构建，词频统计 TermsAggregationBuilder agg = AggregationBuilders.terms("location").field("location.keyword"); builder.aggregation(agg); request.source(builder); //获取结果 Terms terms = (Terms) aggregations.get("location"); bucketMap = Maps.newHashMapWithExpectedSize(10); for (Terms.Bucket bucket : terms.getBuckets()) { bucketMap.put(bucket.getKeyAsString(), bucket.getDocCount()); } aggList.put(terms.getName(), bucketMap);

最后的返回值如下：

 "aggs": { "location": { "陕西省西安市": "2", "广州省深圳市": "1", "天津市": "1", "北京市": "1", "影分身": "1", "湖北省武汉市": "1" } }

至此ES基础、高级特性及整合SpringBoot圆满完结了，相信你已经掌握了ES的基本原理、基本操作、SpringBoot高级客户端的整合，其实还有很多知识点可以讲，包括强大的脚本功能（脚本确实是一把双刃剑，效率低下但用起来很爽，可以突破ES提供的基础DSL语法，利用Groovy自定义查询、算分、插入逻辑）、分片策略（多主分片和副本分片如何合理分布在集群内不同机器上，实现索引的高可用）、路由策略（新增文档时如何指定新增到哪台机器上、查询时如何根据路由实现快速查询）、性能调优等技巧，本人学艺不精就不卖弄了，以后学到了再跟大家分享。

原创文章，作者：优速盾-小U，如若转载，请注明出处：https://www.cdnb.net/bbs/archives/31003