ElasticSearch基础

在学习ElasticSearch之前，先简单了解一下Lucene：

Doug Cutting开发
是apache软件基金会4 jakarta项目组的一个子项目
是一个开放源代码的全文检索引擎工具包
不是一个完整的全文检索引擎，而是一个全文检索引擎的架构，提供了完整的查询引擎和索引引擎，部分文本分析引擎（英文与德文两种西方语言）
当前以及最近几年最受欢迎的免费Java信息检索程序库。

Lucene和ElasticSearch的关系：

ElasticSearch是基于Lucene 做了一下封装和增强

全文搜索： 对非结构化数据顺序扫描很慢，我们是否可以进行优化？把我们的非结构化数据想办法弄得有一定结构不就行了吗？

将非结构化数据中的一部分信息提取出来，重新组织，使其变得有一定结构，然后对此有一定结构的数据进行搜索，从而达到搜索相对较快的目的。

这种方式就构成了全文检索的基本思路。这部分从非结构化数据中提取出的然后重新组织的信息，我们称之为索引。

一、ElasticSearch简介

Elaticsearch，简称为es，是一个开源的高扩展的分布式全文检索引擎，它可以近乎实时的存储、检索数据;本身扩展性很好，可以扩展到上百台服务器，处理PB级别的数据。es使用java开发并使用Lucene作为其核心来实现所有索引和搜索的功能，但是它的目的是通过简单的RESTful API来隐藏Lucene的复杂性，从而让全文搜索变得简单。

基于RESTful web接口。

历史

多年前，一个叫做Shay Banon的刚结婚不久的失业开发者，由于妻子要去伦敦学习厨师，他便跟着也去了。在他找工作的过程中，为了给妻子构建一个食谱的搜索引擎，他开始构建一个早期版本的Lucene。

直接基于Lucene工作会比较困难，所以Shay开始抽象Lucene代码以便lava程序员可以在应用中添加搜索功能。他发布了他的第一个开源项目，叫做“Compass”。

后来Shay找到一份工作，这份工作处在高性能和内存数据网格的分布式环境中，因此高性能的、实时的、分布式的搜索引擎也是理所当然需要的。然后他决定重写Compass库使其成为一个独立的服务叫做Elasticsearch。

第一个公开版本出现在2010年2月，在那之后Elasticsearch已经成为Github上最受欢迎的项目之一。一家主营Elasticsearch的公司就此成立，他们一边提供商业支持一边开发新功能，不过Elasticsearch将永远开源且对所有人可用。

谁在使用：

1、维基百科,类似百度百科，全文检索,高亮,搜索推荐/2
2、The Guardian (国外新闻网站) ,类似搜狐新闻,用户行为日志(点击,浏览,收藏,评论) +社交网络数据(对某某新闻的相关看法) ,数据分析,给到每篇新闻文章的作者,让他知道他的文章的公众反馈(好,坏,热门，垃圾,鄙视，崇拜)
3、Stack Overflow (国外的程序异常讨论论坛) , IT问题,程序的报错,提交上去,有人会跟你讨论和回答,全文检索,搜索相关问题和答案,程序报错了,就会将报错信息粘贴到里面去,搜索有没有对应的答案
4、GitHub (开源代码管理),搜索 上千亿行代码
5、电商网站,检索商品
6、日志数据分析, logstash采集日志, ES进行复杂的数据分析, ELK技术, elasticsearch+logstash+kibana
7、商品价格监控网站,用户设定某商品的价格阈值,当低于该阈值的时候,发送通知消息给用户,比如说订阅牙膏的监控,如果高露洁牙膏的家庭套装低于50块钱,就通知我,我就去买
8、BI系统,商业智能, Business Intelligence。比如说有个大型商场集团，BI ,分析一下某某区域最近3年的用户消费 金额的趋势以及用户群体的组成构成,产出相关的数张报表, **区,最近3年,每年消费金额呈现100%的增长,而且用户群体85%是高级白领，开-个新商场。ES执行数据分析和挖掘, Kibana进行数据可视化
9、国内:站内搜索(电商,招聘,门户,等等),IT系统搜索(OA,CRM,ERP,等等),数据分析(ES热门
的一一个使用场景)

ES和Solr

ElasticSearch简介

Elasticsearch是一个实时分布式搜索和分析引擎。 它让你以前所未有的速度处理大数据成为可能。
它用于全文搜索、结构化搜索、分析以及将这三者混合使用:
维基百科使用Elasticsearch提供全文搜索并高亮关键字,以及输入实时搜索(search-asyou-type)和搜索纠错(did-you-mean)等搜索建议功能。
英国卫报使用Elasticsearch结合用户日志和社交网络数据提供给他们的编辑以实时的反馈,以便及时了解公众对新发表的文章的回应。
StackOverflow结合全文搜索与地理位置查询,以及more-like-this功能来找到相关的问题和答案。
Github使用Elasticsearch检索1300亿行的代码。
但是Elasticsearch不仅用于大型企业，它还让像DataDog以及Klout这样的创业公司将最初的想法变成可扩展的解决方案。
Elasticsearch可以在你的笔记本上运行,也可以在数以百计的服务器上处理PB级别的数据。

Elasticsearch是一个基于Apache Lucene™的开源搜索引擎。无论在开源还是专有领域, Lucene可被认为是迄今为止最先进、性能最好的、功能最全的搜索引擎库。
但是, Lucene只是一个库。 想要使用它,你必须使用Java来作为开发语言并将其直接集成到你的应用中,更糟糕的是, Lucene非常复杂,你需要深入了解检索的相关知识来理解它是如何工作的。
Elasticsearch也使用Java开发并使用Lucene作为其核心来实现所有索引和搜索的功能,但是它的目的是通过简单的RESTful API来隐藏Lucene的复杂性,从而让全文搜索变得简单。

Solr简介

Solr是Apache下的一个顶级开源项目,采用Java开发,它是基于Lucene的全文搜索服务器。Solr提供了比Lucene更为丰富的查询语言,同时实现了可配置、可扩展，并对索引、搜索性能进行了优化
Solr可以独立运行,运行在letty. Tomcat等这些Selrvlet容器中 , Solr 索引的实现方法很简单,用POST方法向Solr服务器发送一个描述Field及其内容的XML文档, Solr根据xml文档添加、删除、更新索引。Solr 搜索只需要发送HTTP GET请求,然后对Solr返回xml、json等格式的查询结果进行解析,组织页面布局。
Solr不提供构建UI的功能, Solr提供了一个管理界面,通过管理界面可以查询Solr的配置和运行情况。
Solr是基于lucene开发企业级搜索服务器,实际上就是封装了lucene.
Solr是一个独立的企业级搜索应用服务器,它对外提供类似于Web-service的API接口。用户可以通过http请求,向搜索引擎服务器提交-定格式的文件,生成索引;也可以通过提出查找请求,并得到返回结果。

ElasticSearch与Solr比较

总结

1、es基本是开箱即用(解压就可以用,非常简单。Solr安装略微复杂一丢丢!
2、Solr 利用Zookeeper进行分布式管理,而Elasticsearch自身带有分布式协调管理功能。
3、Solr 支持更多格式的数据,比如JSON、XML、 CSV ,而Elasticsearch仅支持json文件格式。
4、Solr 官方提供的功能更多,而Elasticsearch本身更注重于核心功能，高级功能多有第三方插件提供，例如图形化界面需要kibana友好支撑
5、Solr 查询快,但更新索引时慢(即插入删除慢) ，用于电商等查询多的应用;

ES建立索引快(即查询慢) ，即实时性查询快，用于facebook新浪等搜索。
Solr是传统搜索应用的有力解决方案，但Elasticsearch更适用于新兴的实时搜索应用。

6、Solr比较成熟，有一个更大，更成熟的用户、开发和贡献者社区，而Elasticsearch相对开发维护者较少,更新太快,学习使用成本较高。

二、ElasticSearch安装

将ElasticSearch及相关工具安装在同一个目录下

Windows下安装ElasticSearch

1、安装

下载地址：https://www.elastic.co/cn/downloads/

解压即可
2、熟悉目录

• bin 启动文件目录

• config 配置文件目录

  • elasticsearch.ym1 elasticsearch 的配置文件。默认端口（9200）、跨域支持可在这里配置。
  • log4j2 日志配置文件
  • jvm.options java虚拟机相关的配置(默认启动占1g内存，内存不够需要自己调整)

• lib 相关jar包

• modules 功能模块目录

• plugins 插件目录 比如ik分词器插件可以安装在这里

3、启动

双击bin目录下的elasticsearch.bat

默认会监听9200端口

一个人就是一个集群! ，即启动的ElasticSearch服务，默认就是一个集群模式启动，且默认集群名为elasticsearch

可视化工具elasticsearch-head

这个head，我们只是把它当做可视化数据展示工具，之后所有的查询都在kibana中进行
因为不支持json格式化，不方便

需要提前安装nodejs

1、下载地址

https://github.com/mobz/elasticsearch-head
2、安装

解压即可（尽量将ElasticSearch相关工具放在同一目录下）
3、启动

cd elasticsearch-head
# 安装依赖
npm install
# 运行
npm run start

默认运行于9100端口

http://localhost:9100/

存在跨域问题（可视化界面运行于9100端口，ES运行于9200）

同源（端口，主机，协议三者都相同）

https://blog.csdn.net/qq_38128179/article/details/84956552

开启跨域（在elasticsearch解压目录config下elasticsearch.yml中添加）

#开启跨域
http.cors.enabled: true
# 所有人访问
http.cors.allow-origin: "*"

重启elasticsearch,再次用浏览器访问9100端口

如何理解上图：

如果你是初学者
索引 可以看做 “数据库”
类型 可以看做 “表”（6.x，从7.x逐渐被淘汰）
文档 可以看做 “库中的数据（表中的行）”

了解ELK

ELK是Elasticsearch、Logstash、 Kibana三大开源框架首字母大写简称。市面上也被称为Elastic Stack。
其中Elasticsearch是一个基于Lucene、分布式、通过Restful方式进行交互的近实时搜索平台框架。像类似百度、谷歌这种大数据全文搜索引擎的场景都可以使用Elasticsearch作为底层支持框架，可见Elasticsearch提供的搜索能力确实强大
Logstash是ELK的中央数据流引擎,用于从不同目标(文件/数据存储/MQ )收集的不同格式数据,经过过滤后支持输出到不同目的地(文件/MQ/redis/elasticsearch/kafka等)。
Kibana可以将elasticsearch的数据通过友好的页面展示出来 ,提供实时分析的功能。

市面上很多开发只要提到ELK能够一致说出它是一个日志分析架构技术栈总称 ,但实际上ELK不仅仅适用于日志分析,它还可以支持其它任何数据分析和收集的场景,日志分析和收集只是更具有代表性。

收集清洗数据(Logstash) ==> 搜索、存储(ElasticSearch) ==> 展示(Kibana)

安装kibana

Kibana是一个针对ElasticSearch的开源分析及可视化平台,用来搜索、查看交互存储在Elasticsearch索引中的数据。使用Kibana ,可以通过各种图表进行高级数据分析及展示。Kibana让海量数据更容易理解。它操作简单,基于浏览器的用户界面可以快速创建仪表板( dashboard )实时显示Elasticsearch查询动态。设置Kibana非常简单。无需编码或者额外的基础架构,几分钟内就可以完成Kibana安装并启动Elasticsearch索引监测。
1、下载地址:

下载的版本需要与ElasticSearch版本对应

https://www.elastic.co/cn/downloads/

历史版本下载：https://www.elastic.co/cn/downloads/past-releases/
2、安装

解压即可（尽量将ElasticSearch相关工具放在统一目录下）

3、kibana汉化(可选，配置更新后需重启kibana)

编辑器打开kibana解压目录/config/kibana.yml，添加

i18n.locale: "zh-CN"

4、启动

运行bin下启动脚本kibana.bat

访问localhost:5601

5、开发工具

可以使用 Kibana进行测试（也可以用Postman、curl、head、谷歌浏览器插件）

通过http请求实现

docker方式安装ES

安装ElasticSearch的镜像

docker pull registry.docker-cn.com/library/elasticsearch

4、运行ElasticSearch

-e ES_JAVA_OPTS=“-Xms256m -Xmx256m” 表示占用的最大内存为256m,默认是2G

# 查看id
 docker images
			...						IMAGE ID
			...						671bb2d7da44                             
#根据id启动容器
docker run -e ES_JAVA_OPTS="-Xms256m -Xmx256m" -d -p 9200:9200 -p 9300:9300 --name ES01 671bb2d7da44

5、测试是否启动成功

访问9200端口：http://192.168.179.131:9200/ 查看是否返回json数据

{
  "name" : "onB-EUU",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "j3SXX6tdThWUomW3tAvDFg",
  "version" : {
    "number" : "5.6.9",
    "build_hash" : "877a590",
    "build_date" : "2018-04-12T16:25:14.838Z",
    "build_snapshot" : false,
    "lucene_version" : "6.6.1"
  },
  "tagline" : "You Know, for Search"
}

三、ElasticSearch核心概念

基本概念

es是面向文档的，一切内容都是json。

和关系型数据库相似概念类比

Relational DB	ElasticSearch
数据库（database）	索引（indices）
表（tables）	types <慢慢会被弃用!>
行（rows）一条记录	文档 documents 一条记录
字段/列（columns）	字段fields

elasticsearch（集群）中可以包含多个索引（数据库） ,每个索引中可以包含多个类型（表） ,每个类型下又包含多个文档（行，一条记录） ,每个文档中又包含多个字段（列）。

逻辑设计:

一个索引类型中，包含多个文档，比如说文档1，文档2。当我们索引一篇文档时，可以通过这样的顺序找到它：索引 => 类型 => 文档ID ，通过这个组合我们就能索引到某个具体的文档。 注意：ID不必是整数，实际上它是个字符串。

文档（”行“）

之前说elasticsearch是面向文档的，那么就意味着索引和搜索数据的最小单位是文档，elasticsearch中，文档有几个重要属性:

• 自我包含，一篇文档同时包含字段和对应的值，也就是同时包含key:value !
• 可以是层次型的，一个文档中包含自文档，复杂的逻辑实体就是这么来的! {就是一个json对象 ! fastjson进行自动转换 !}
• 灵活的结构，文档不依赖预先定义的模式，我们知道关系型数据库中，要提前定义字段才能使用，在elasticsearch中，对于字段是非常灵活的，有时候,我们可以忽略该字段，或者动态的添加一个新的字段。

类型（“表”）

提前规定文档的逻辑映射，既每个字段应该放什么类型的数据。更像是面向对象编程中类的定义

尽管我们可以随意的新增或者忽略某个字段，但是，每个字段的类型非常重要，比如一个年龄字段类型，可以是字符串也可以是整形。因为elasticsearch会保存字段和类型之间的映射及其他的设置。这种映射具体到每个映射的每种类型，这也是为什么在elasticsearch中，类型有时候也称为映射类型。

类型是文档的逻辑容器，就像关系型数据库一样，表格是行的容器。类型中对于字段的定义称为映射，比如name映射为字符串类型。我们说文档是无模式的，它们不需要拥有映射中所定义的所有字段，比如新增一个字段，那么elasticsearch是怎么做的呢?

elasticsearch会自动的将新字段加入映射，但是这个字段的不确定它是什么类型，elasticsearch就开始猜，如果这个值是18，那么elasticsearch会认为它是整形。但是elasticsearch也可能猜不对，所以最安全的方式就是提前定义好所需要的映射，这点跟关系型数据库殊途同归了，先定义好字段，然后再使用，别整什么幺蛾子。

索引（“库”）

索引是映射类型的容器， elasticsearch中的索引是一个非常大的文档集合。 索引存储了映射类型的字段和其他设置。然后它们被存储到了各个分片上了。

创建新索引

**物理设计:**节点和分片

elasticsearch在后台把每个索引划分成多个分片，每分分片可以在集群中的不同服务器间迁移

类似于hdfs数据块的概念。似乎分布式存储要么全部复制当备份（集群），要么重新划分存储单元

一个集群至少有一个节点，而一个节点就是一个elasricsearch进程，节点可以有多个索引，如果你创建索引，那么索引将会有个5个分片(primary shard ,又称主分片)构成的，每一个主分片会有一个副本(replica shard，又称复制分片)。

上图是一个有3个节点的集群，可以看到主分片和对应的复制分片都不会在同一个节点内，这样有利于某个节点挂掉了，数据也不至于失。实际上，一个分片是一个Lucene索引（一个ElasticSearch索引包含多个Lucene索引） ，一个包含倒排索引的文件目录，倒排索引的结构使得elasticsearch在不扫描全部文档的情况下，就能告诉你哪些文档包含特定的关键字,

主分片和副本在图中标记为p0_p5和r0r5。同一序号的p和r不放一起？（有什么算法？）

索引（名词）：
如前所述，一个 索引 类似于传统关系数据库中的一个 数据库 ，是一个存储关系型文档的地方。 索引 (index) 的复数词为 indices 或 indexes 。

索引（动词）：

索引一个文档 就是存储一个文档到一个 索引 （名词）中以便它可以被检索和查询到。这非常类似于 SQL 语句中的 INSERT 关键词，除了文档已存在时新文档会替换旧文档情况之外。

倒排索引（Lucene索引底层）

为了创建倒排索引，我们通过分词器将每个文档的内容域拆分成单独的词（我们称它为词条或 Term），创建一个包含所有不重复词条的排序列表，然后列出每个词条出现在哪个文档。

文档：

Java is the best programming language.
PHP is the best programming language.
Javascript is the best programming language.

简单说就是 按（文章关键字，对应的文档<0个或多个>）形式建立索引，根据关键字就可直接查询对应的文档（含关键字的），无需查询每一个文档

结果如下所示：

Term          Doc_1    Doc_2   Doc_3  
-------------------------------------  
Java        |   X   |        |  
is          |   X   |   X    |   X  
the         |   X   |   X    |   X  
best        |   X   |   X    |   X  
programming |   x   |   X    |   X  
language    |   X   |   X    |   X  
PHP         |       |   X    |  
Javascript  |       |        |   X  
-------------------------------------  

把单词拆开做成列表。根据单词查文档，（想起来控制反转也是控制权反转hhh）

其中主要有如下几个核心术语需要理解：

• 词条（Term）： 索引里面最小的存储和查询单元，对于英文来说是一个单词，对于中文来说一般指分词后的一个词。
• 词典（Term Dictionary）： 或字典，是词条 Term 的集合。搜索引擎的通常索引单位是单词，单词词典是由文档集合中出现过的所有单词构成的字符串集合，单词词典内每条索引项记载单词本身的一些信息以及指向“倒排列表”的指针。
• 倒排表（Post list）： 一个文档通常由多个词组成，倒排表记录的是某个词在哪些文档里出现过以及出现的位置。每条记录称为一个倒排项（Posting）。倒排表记录的不单是文档编号，还存储了词频等信息。
• 倒排文件（Inverted File）： 所有单词的倒排列表往往顺序地存储在磁盘的某个文件里，这个文件被称之为倒排文件，倒排文件是存储倒排索引的物理文件。

词典和倒排文件是分两部分存储的，词典在内存中而倒排文件存储在磁盘上。

每个分片都是倒排索引，多个倒排索引构成索引（数据库）

• 狂神倒排索引讲的有争议，看其他人

四、IK分词器(elasticsearch插件)

IK分词器：中文分词器

分词：即把一段中文或者别的划分成一个个的关键字，我们在搜索时候会把自己的信息进行分词，会把数据库中或者索引库中的数据进行分词，然后进行一一个匹配操作，默认的中文分词是将每个字看成一个词（不使用用IK分词器的情况下），比如“我爱狂神”会被分为”我”，”爱”，”狂”，”神” ，这显然是不符合要求的，所以我们需要安装中文分词器ik来解决这个问题。

IK提供了两个分词算法: ik_smart和ik_max_word ,其中ik_smart为最少切分, ik_max_word为最细粒度划分!

是ik这个插件分词器提供了两个分词算法，不是es默认分词器提供了两个

1、下载

版本要与ElasticSearch版本对应

下载地址：https://github.com/medcl/elasticsearch-analysis-ik/releases
2、安装

ik文件夹是自己创建的

解压到ElasticSearch的plugins目录ik文件夹下（没有则手动新建）
3、重启ElasticSearch

4、可以使用 ElasticSearch的list命令查看插件

E:\ElasticSearch\elasticsearch-7.6.1\bin>elasticsearch-plugin list

5、使用kibana测试

ik_smart：最少切分

ik_max_word：最细粒度划分（穷尽词库的可能）

从上面看，感觉分词都比较正常，但是大多数，分词都满足不了我们的想法，如下例

那么，我们需要手动将该词添加到分词器的词典当中

6、添加自定义的词添加到扩展字典中

编辑elasticsearch目录/plugins/ik/config/IKAnalyzer.cfg.xml

创建字典文件，添加字典内容，编码方式为utf-8

重启ElasticSearch，再次使用kibana测试

五、Rest风格命令使用

一种软件架构风格,而不是标准,只是提供了一组设计原则和约束条件。它主要用于客户端和服务器交互类的软件。基于这个风格设计的软件可以更简洁，更有层次，更易于实现缓存等机制。

基本Rest命令说明：

method	url地址	描述
PUT（创建,修改）	localhost:9200/索引名称/类型名称/文档id	创建文档（指定文档id）
POST（创建）	localhost:9200/索引名称/类型名称	创建文档（随机文档id）
POST（修改）	localhost:9200/索引名称/类型名称/文档id/_update	修改文档
DELETE（删除）	localhost:9200/索引名称/类型名称/文档id	删除文档
GET（查询）	localhost:9200/索引名称/类型名称/文档id	查询文档通过文档ID
POST（查询）	localhost:9200/索引名称/类型名称/文档id/_search	查询所有数据

在kibana测试环境中，url可以按照规则随意写，会操作对应的文档。索引名、类型名、文档id可以拿来就用，就像python变量

一些预设的url

• _update
• _search
• _analyze 分词器查询

字段数据类型

• 字符串类型

  • text、keyword
    • text：支持分词，全文检索,支持模糊、精确查询,不支持聚合,排序操作;text类型的最大支持的字符长度无限制,适合大字段存储
    • keyword：不进行分词（不拆开），直接索引、支持模糊、支持精确匹配，支持聚合、排序操作。keyword类型的最大支持的长度为——32766个UTF-8类型的字符,可以通过设置ignore_above指定自持字符长度，超过给定长度后的数据将不被索引，无法通过term精确匹配检索返回结果。

• 数值型

  • long、Integer、short、byte、double、float、half float、scaled float

• 日期类型

  • date

• 布尔类型

  • boolean

• 二进制类型

  • binary

等等…

操作

1、创建一个索引，添加

量一样

2、指定字段的类型（PUT）

类似于建库（建立索引和字段对应类型），也可看做规则的建立

PUT /test2
{
	"mappings": {    
		"properties": {
        	"name": {
            	"type": "text"      
            },
            "age":{
            	"type": "long"
            }, 
            "birthday":{
            	"type": "date"
            }    
        }  
    }
}

3、获取建立的规则

GET test2

4、获取默认信息

_doc 默认类型（default type），type 在未来的版本中会逐渐弃用，因此产生一个默认类型进行代替
即不提前设定type,在使用时直接用_doc，会自动为字段配置类型

如果自己的文档字段没有被指定，那么ElasticSearch就会给我们默认配置字段类型

扩展：通过get _cat/ 可以获取ElasticSearch的当前的很多信息！

5、修改

两种方案

①旧的（使用put覆盖原来的值）

版本+1（_version字段增加）
但是如果漏掉某个字段没有写，那么更新是没有写的字段 ，会消失

PUT /test3/_doc/1
{
	"name" : "流柚是我的大哥",
    "age" : 18,
    "birth" : "1999-10-10"
}
    
GET /test3/_doc/1

PUT /test3/_doc/1
{
	"name" : "流柚"
}

GET /test3/_doc/1

②新的（使用post的update）

不是正常的Restful风格，但灵活性更高

version不会改变
需要注意doc
不会丢失字段

POST /test3/_doc/1/_update
{
	"doc":{
    	"name" : "post修改，version不会加一",
        "age" : 2  
    }
}

查看

GET /test3/_doc/1

6、删除

DELETE /test1

7、查询（简单条件）

GET /test3/_doc/_search?q=name:流柚

8、复杂查询

传入一个对象定义查询条件

test3索引中的内容

①查询

• match：匹配（会使用分词器解析（先分析文档，然后进行查询））
  • 可以匹配多个关键字，直接用空格隔开，会用or查询
• _source：过滤字段
• sort：排序
• form、size 分页

GET /blog/user/_search   
{      
	"query":{ 
    	"match":{
        	"name":"流"
        }
    },
    "_source": ["name","desc"],
    "sort": [
    	{
        	"age": {
            "order": "asc"
            }
        }
    ],
    "from": 0,
    "size": 1
}

命中的结果在hits中，查询出的_score表示匹配度

②多条件查询（bool）

• must 相当于 and
• should 相当于 or
• must_not 相当于 not (… and …)
• filter 过滤
  • gte 大于
  • lt 小于

boost

minimum_should_match

GET /blog/user/_search
{  	"
	query":{
    	"bool": {
        	"must": [
            	{
                	"match":{
                    	"age":3
                    }
                },
                {
                	"match": {
                    "name": "流"
                    }
                }
            ],
            "filter": {
            	"range": {
                	"age": {
                    	"gte": 1,
                        "lte": 3
                    }                
                }
            }
        }
    }
}

③匹配数组

貌似不能与其它字段一起使用
可以多关键字查（空格隔开）— 匹配字段也是符合的
match 会使用分词器解析（先分析文档，然后进行查询）
搜词

// 匹配数组 貌似不能与其它字段一起使用

// 可以多关键字查（空格隔开）

// match 会使用分词器解析（先分析文档，然后进行查询）

GET /blog/user/_search
{	
	"query":{
    	"match":{
        	"desc":"年龄 牛 大"
        }
    }
}

分词查询

在查询时是否用分词器解析

④term精确查询

term 直接通过 倒排索引 指定词条查询
适合查询 number、date、keyword ，不适合text

// 精确查询（必须全部都有，而且不可分，即按一个完整的词查询）

// term 直接通过 倒排索引 指定的词条 进行精确查找的，速度比match快

GET /blog/user/_search
{  	
	"query":{
    	"term":{
        	"desc":"年 "
        }
    }
}

⑤text和keyword

text：
    支持分词，全文检索、支持模糊、精确查询,不支持聚合,排序操作;
    text类型的最大支持的字符长度无限制,适合大字段存储；
keyword：
    不进行分词，直接索引、支持模糊、支持精确匹配，支持聚合、排序操作。
    keyword类型的最大支持的长度为——32766个UTF-8类型的字符,可以通过设置ignore_above指定自持字符长度，超过给定长度后的数据将不被索引，无法通过term精确匹配检索返回结果。

测试keyword和text是否支持分词

// text 支持分词
// keyword 不支持分词

// 设置索引类型

PUT /test
{
  "mappings": {
    "properties": {
      "text":{
        "type":"text"
      },
      "keyword":{
        "type":"keyword"
      }
    }
  }
}

// 设置字段数据

PUT /test/_doc/1
{
  "text":"测试keyword和text是否支持分词",
  "keyword":"测试keyword和text是否支持分词"
}

测试

GET /test/_doc/_search
{
  "query":{
   "match":{
      "text":"测试"
   }
  }
}// 查的到


GET /test/_doc/_search
{
  "query":{
   "match":{
      "keyword":"测试"
   }
  }
}// 查不到，必须是 "测试keyword和text是否支持分词" 才能查到

使用分词器_analyze进行分词

GET _analyze
{
  "analyzer": "keyword",
  "text": ["测试liu"]
}// 不会分词，即 测试liu 整个作为查询条件

GET _analyze
{
  "analyzer": "standard",
  "text": ["测试liu"]
}// 分为 测 试 liu


GET _analyze
{
  "analyzer":"ik_max_word",
  "text": ["测试liu"]
}// 分为 测试 liu 用了ik中文分词器的规则作为查询条件

和term的理解：

term与match是查询时查询条件会不会被分词然后再去查询

keyword与text是被存储这个类型的字段，文本内容会不会被分词器解析然后再被查询

⑥高亮查询

GET blog/user/_search
{  
	"query": {
    	"match": {
        	"name":"流"
        }
    }
    ,
    "highlight": {
    	"fields": {
        	"name": {}
        }
    }
}

默认将结果用em标签包裹

GET blog/user/_search
{
	"query": {
    	"match": {
        	"name":"流"
        }
    }
    ,
    "highlight": {
    	"pre_tags": "
", 
        "post_tags": "
",
        "fields": {
        	"name": {}
        }
    }
}

会在匹配到的值上加上前缀和后缀

六、SpringBoot整合

去文档看高级客户端

导入依赖

<properties>
	<java.version>1.8java.version>
    
    <elasticsearch.version>7.6.1elasticsearch.version>
properties>

导入elasticsearch、fastjson、lombok(直接用idea)

• es版本号不用写明？

<dependency>
	<groupId>org.springframework.bootgroupId>
    <artifactId>spring-boot-starter-data-elasticsearchartifactId>
dependency>

<dependency>    
	<groupId>com.alibabagroupId>
    <artifactId>fastjsonartifactId>
    <version>1.2.70version>
dependency>


<dependency>
	<groupId>org.projectlombokgroupId>
    <artifactId>lombokartifactId>
    <optional>trueoptional>
dependency>

创建并编写配置类

@Configuration
public class ElasticSearchConfig { 
// 注册 rest高级客户端     
	@Bean
    public RestHighLevelClient restHighLevelClient(){
    	RestHighLevelClient client = new RestHighLevelClient(
            	RestClient.builder(new HttpHost("127.0.0.1",9200,"http"))
        );       
        return client;
    }
}

4、创建并编写实体类

@Data
@NoArgsConstructor
@AllArgsConstructor
public class User implements Serializable {
	private static final long serialVersionUID = -3843548915035470817L;
    private String name;
    private Integer age;
}

5、测试

注入 RestHighLevelClient

@Autowiredpublic RestHighLevelClient restHighLevelClient;

1

ElasticSearch 的 Client

ElasticSearch 官方提供了 3 个 Client，具体如下：

• org.elasticsearch.client.transport.TransportClient
• org.elasticsearch.client.RestClient
• org.elasticsearch.client.RestHighLevelClient

AbstractElasticsearchConfiguration 接口位于org.springframework.data.elasticsearch.config 包下，可以按照如下方式来使用：

@Configuration
public class ESConfigutration extends AbstractElasticsearchConfiguration {
 
    @Override
    public RestHighLevelClient elasticsearchClient() {
        final ClientConfiguration clientConfiguration = ClientConfiguration.builder()
                .connectedTo("192.168.110.128:9200")
                .build();
        return RestClients.create(clientConfiguration).rest();
    }
}

如上面的代码，自定义一个配置类，继承 AbstractElasticsearchConfiguration 接口，并实现接口中定义的方法 RestHighLevelClient elasticsearchClient()。

上面的 ClientConfiguration 用来配置 ElasticSearch 客户端的属性，比如可以配置代理、连接超时时长以及 socket 超时时长等，上面的代码示例中只配置了 ElasticSearch 服务的地址和端口号。

索引的操作

1、索引的创建

// 测试索引的创建， Request PUT liuyou_index
@Test
public void testCreateIndex() throws IOException {
	CreateIndexRequest request = new CreateIndexRequest("liuyou_index");
    CreateIndexResponse response = restHighLevelClient.indices().create(request, RequestOptions.DEFAULT);    		System.out.println(response.isAcknowledged());// 查看是否创建成功    
    System.out.println(response);// 查看返回对象    
    restHighLevelClient.close();
}

2、索引的获取，并判断其是否存在

// 测试获取索引，并判断其是否存在
@Test
	public void testIndexIsExists() throws IOException {
    	GetIndexRequest request = new GetIndexRequest("index");
        boolean exists = restHighLevelClient.indices().exists(request, RequestOptions.DEFAULT);    
        System.out.println(exists);// 索引是否存在    
        restHighLevelClient.close();
    }

3、索引的删除

// 测试索引删除
@Test
public void testDeleteIndex() throws IOException {    
	DeleteIndexRequest request = new DeleteIndexRequest("liuyou_index");
    AcknowledgedResponse response = restHighLevelClient.indices().delete(request, RequestOptions.DEFAULT);  
    System.out.println(response.isAcknowledged());// 是否删除成功   
    restHighLevelClient.close();
}

文档的操作

1、文档的添加

// 测试添加文档(先创建一个User实体类，添加fastjson依赖)
@Testpublic void testAddDocument() throws IOException {
	// 创建一个User对象    
	User liuyou = new User("liuyou", 18);
    // 创建请求    
    IndexRequest request = new IndexRequest("liuyou_index");
    // 制定规则 PUT /liuyou_index/_doc/1    
    request.id("1");
    // 设置文档ID 
    request.timeout(TimeValue.timeValueMillis(1000));
    // request.timeout("1s")    
    // 将我们的数据放入请求中  
    request.source(JSON.toJSONString(liuyou), XContentType.JSON); 
    // 客户端发送请求，获取响应的结果    
    IndexResponse response = restHighLevelClient.index(request, RequestOptions.DEFAULT);
    System.out.println(response.status());
    // 获取建立索引的状态信息 CREATED    
    System.out.println(response);
    // 查看返回内容 
    //IndexResponse[index=liuyou_index,type=_doc,id=1,version=1,result=created,seqNo=0,primaryTerm=1,shards={"total":2,"successful":1,"failed":0}]}

2、文档信息的获取

// 测试获得文档信息
@Test
public void testGetDocument() throws IOException { 
    GetRequest request = new GetRequest("liuyou_index","1");  
    GetResponse response = restHighLevelClient.get(request, RequestOptions.DEFAULT);   
    System.out.println(response.getSourceAsString());// 打印文档内容   
    System.out.println(request);// 返回的全部内容和命令是一样的   
    restHighLevelClient.close();
}

3、文档的获取，并判断其是否存在

// 获取文档，判断是否存在 get /liuyou_index/_doc/1
@Test
public void testDocumentIsExists() throws IOException { 
    GetRequest request = new GetRequest("liuyou_index", "1");  
    // 不获取返回的 _source的上下文了    
    request.fetchSourceContext(new FetchSourceContext(false));   
    request.storedFields("_none_");   
    boolean exists = restHighLevelClient.exists(request, RequestOptions.DEFAULT);   
    System.out.println(exists);
}

4、文档的更新

// 测试更新文档内容
@Test
public void testUpdateDocument() throws IOException {
    UpdateRequest request = new UpdateRequest("liuyou_index", "1"); 
    User user = new User("lmk",11);   
    request.doc(JSON.toJSONString(user),XContentType.JSON); 
    UpdateResponse response = restHighLevelClient.update(request, RequestOptions.DEFAULT); 
    System.out.println(response.status()); // OK    
    restHighLevelClient.close();
}

5、文档的删除

// 测试删除文档
@Test
public void testDeleteDocument() throws IOException { 
    DeleteRequest request = new DeleteRequest("liuyou_index", "1"); 
    request.timeout("1s");    
    DeleteResponse response = restHighLevelClient.delete(request, RequestOptions.DEFAULT); 
    System.out.println(response.status());// OK
}

6、文档的查询

// 查询
// SearchRequest 搜索请求
// SearchSourceBuilder 条件构造
// HighlightBuilder 高亮
// TermQueryBuilder 精确查询
// MatchAllQueryBuilder
// xxxQueryBuilder ...
@Test
public void testSearch() throws IOException {
    // 1.创建查询请求对象   
    SearchRequest searchRequest = new SearchRequest();  
    // 2.构建搜索条件  
    SearchSourceBuilder searchSourceBuilder = new SearchSourceBuilder(); 
    // (1)查询条件 使用QueryBuilders工具类创建  
    // 精确查询    
    TermQueryBuilder termQueryBuilder = QueryBuilders.termQuery("name", "liuyou");  
    //       
    // 匹配查询
    //      
    MatchAllQueryBuilder matchAllQueryBuilder = QueryBuilders.matchAllQuery(); 
    // (2)其他<可有可无>：（可以参考 SearchSourceBuilder 的字段部分）  
    // 设置高亮    
    searchSourceBuilder.highlighter(new HighlightBuilder());  
    //     
    // 分页 
    //     
    searchSourceBuilder.from();
    //      
    searchSourceBuilder.size(); 
    searchSourceBuilder.timeout(new TimeValue(60, TimeUnit.SECONDS));
    // (3)条件投入   
    searchSourceBuilder.query(termQueryBuilder);  
    // 3.添加条件到请求   
    searchRequest.source(searchSourceBuilder); 
    // 4.客户端查询请求   
    SearchResponse search = restHighLevelClient.search(searchRequest, RequestOptions.DEFAULT); 
    // 5.查看返回结果    
    SearchHits hits = search.getHits();  
    System.out.println(JSON.toJSONString(hits));    
    System.out.println("=======================");   
    for (SearchHit documentFields : hits.getHits()) {  
        System.out.println(documentFields.getSourceAsMap());  
    }
}
// 查询
// SearchRequest 搜索请求
// SearchSourceBuilder 条件构造
// HighlightBuilder 高亮
// TermQueryBuilder 精确查询
// MatchAllQueryBuilder
// xxxQueryBuilder ...
@Test
public void testSearch() throws IOException {
    // 1.创建查询请求对象  
    SearchRequest searchRequest = new SearchRequest();   
    // 2.构建搜索条件  
    SearchSourceBuilder searchSourceBuilder = new SearchSourceBuilder();   
    // (1)查询条件 使用QueryBuilders工具类创建  
    // 精确查询 
    TermQueryBuilder termQueryBuilder = QueryBuilders.termQuery("name", "liuyou");   
    //      
    // 匹配查询
    //     
    MatchAllQueryBuilder matchAllQueryBuilder = QueryBuilders.matchAllQuery();    
    // (2)其他<可有可无>：（可以参考 SearchSourceBuilder 的字段部分）
    // 设置高亮   
    searchSourceBuilder.highlighter(new HighlightBuilder());  
    //        
    // 分页 
    //        searchSourceBuilder.from();   
    //        searchSourceBuilder.size();  
    searchSourceBuilder.timeout(new TimeValue(60, TimeUnit.SECONDS)); 
    // (3)条件投入    
    searchSourceBuilder.query(termQueryBuilder);  
    // 3.添加条件到请求   
    searchRequest.source(searchSourceBuilder); 
    // 4.客户端查询请求  
    SearchResponse search = restHighLevelClient.search(searchRequest, RequestOptions.DEFAULT);  
    // 5.查看返回结果  
    SearchHits hits = search.getHits();    
    System.out.println(JSON.toJSONString(hits)); 
    System.out.println("=======================");  
    for (SearchHit documentFields : hits.getHits()) {      
        System.out.println(documentFields.getSourceAsMap()); 
    }
}

前面的操作都无法批量添加数据

// 上面的这些api无法批量增加数据（只会保留最后一个source）@Testpublic void test() throws IOException {    IndexRequest request = new IndexRequest("bulk");// 没有id会自动生成一个随机ID    request.source(JSON.toJSONString(new User("liu",1)),XContentType.JSON);    request.source(JSON.toJSONString(new User("min",2)),XContentType.JSON);    request.source(JSON.toJSONString(new User("kai",3)),XContentType.JSON);    IndexResponse index = restHighLevelClient.index(request, RequestOptions.DEFAULT);    System.out.println(index.status());// created}

7、批量添加数据

// 特殊的，真的项目一般会 批量插入数据@Testpublic void testBulk() throws IOException {    BulkRequest bulkRequest = new BulkRequest();    bulkRequest.timeout("10s");    ArrayList users = new ArrayList<>();    users.add(new User("liuyou-1",1));    users.add(new User("liuyou-2",2));    users.add(new User("liuyou-3",3));    users.add(new User("liuyou-4",4));    users.add(new User("liuyou-5",5));    users.add(new User("liuyou-6",6));    // 批量请求处理    for (int i = 0; i < users.size(); i++) {        bulkRequest.add(                // 这里是数据信息                new IndexRequest("bulk")                        .id(""+(i + 1)) // 没有设置id 会自定生成一个随机id                        .source(JSON.toJSONString(users.get(i)),XContentType.JSON)        );    }    BulkResponse bulk = restHighLevelClient.bulk(bulkRequest, RequestOptions.DEFAULT);    System.out.println(bulk.status());// ok}

ElasticSearch实战

防京东商城搜索（高亮）
1、工程创建（springboot）

创建过程略

目录结构

img
2、基本编码
①导入依赖

    1.8    7.6.1                    org.jsoup        jsoup        1.10.2                    com.alibaba        fastjson        1.2.70                    org.springframework.boot        spring-boot-starter-data-elasticsearch                    org.springframework.boot        spring-boot-starter-thymeleaf                    org.springframework.boot        spring-boot-starter-web                    org.springframework.boot        spring-boot-devtools        runtime        true                    org.springframework.boot        spring-boot-configuration-processor        true                    org.projectlombok        lombok        true                    org.springframework.boot        spring-boot-starter-test        test    

②导入前端素材

略
③编写 application.preperties配置文件

更改端口，防止冲突server.port=9999# 关闭thymeleaf缓存spring.thymeleaf.cache=false

1

④测试controller和view

@Controllerpublic class IndexController { @GetMapping({“/”,“index”}) public String index(){ return “index”; }}

1

访问 localhost:9999

img

到这里可以先去编写爬虫，编写之后，回到这里

⑤编写Config

@Configurationpublic class ElasticSearchConfig { @Bean public RestHighLevelClient restHighLevelClient(){ RestHighLevelClient client = new RestHighLevelClient( RestClient.builder( new HttpHost(“127.0.0.1”,9200,“http”) ) ); return client; }}

1

⑥编写service

因为是爬取的数据，那么就不走Dao，以下编写都不会编写接口，开发中必须严格要求编写

ContentService

@Servicepublic class ContentService { @Autowired private RestHighLevelClient restHighLevelClient; // 1、解析数据放入 es 索引中 public Boolean parseContent(String keyword) throws IOException { // 获取内容 List contents = HtmlParseUtil.parseJD(keyword); // 内容放入 es 中 BulkRequest bulkRequest = new BulkRequest(); bulkRequest.timeout(“2m”); // 可更具实际业务是指 for (int i = 0; i < contents.size(); i++) { bulkRequest.add( new IndexRequest(“jd_goods”) .id(“”+(i+1)) .source(JSON.toJSONString(contents.get(i)), XContentType.JSON) ); } BulkResponse bulk = restHighLevelClient.bulk(bulkRequest, RequestOptions.DEFAULT); restHighLevelClient.close(); return !bulk.hasFailures(); } // 2、根据keyword分页查询结果 public List> search(String keyword, Integer pageIndex, Integer pageSize) throws IOException { if (pageIndex < 0){ pageIndex = 0; } SearchRequest jd_goods = new SearchRequest(“jd_goods”); // 创建搜索源建造者对象 SearchSourceBuilder searchSourceBuilder = new SearchSourceBuilder(); // 条件采用：精确查询 通过keyword查字段name TermQueryBuilder termQueryBuilder = QueryBuilders.termQuery(“name”, keyword); searchSourceBuilder.query(termQueryBuilder); searchSourceBuilder.timeout(new TimeValue(60, TimeUnit.SECONDS));// 60s // 分页 searchSourceBuilder.from(pageIndex); searchSourceBuilder.size(pageSize); // 高亮 // … // 搜索源放入搜索请求中 jd_goods.source(searchSourceBuilder); // 执行查询，返回结果 SearchResponse searchResponse = restHighLevelClient.search(jd_goods, RequestOptions.DEFAULT); restHighLevelClient.close(); // 解析结果 SearchHits hits = searchResponse.getHits(); List> results = new ArrayList<>(); for (SearchHit documentFields : hits.getHits()) { Map sourceAsMap = documentFields.getSourceAsMap(); results.add(sourceAsMap); } // 返回查询的结果 return results; }}

1

⑦编写controller

@Controllerpublic class ContentController { @Autowired private ContentService contentService; @ResponseBody @GetMapping(“/parse/{keyword}”) public Boolean parse(@PathVariable(“keyword”) String keyword) throws IOException { return contentService.parseContent(keyword); } @ResponseBody @GetMapping(“/search/{keyword}/{pageIndex}/{pageSize}”) public List> parse(@PathVariable(“keyword”) String keyword, @PathVariable(“pageIndex”) Integer pageIndex, @PathVariable(“pageSize”) Integer pageSize) throws IOException { return contentService.search(keyword,pageIndex,pageSize); }}

1

⑧测试结果
1、解析数据放入 es 索引中

img

img
2、根据keyword分页查询结果

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7RzrCflr-1638619379750)(https://www.kuangstudy.com/bbs/2020-11-24-ElasticSearch7.x%E5%AD%A6%E4%B9%A0%E7%AC%94%E8%AE%B0/image-20201203180102264.png)]
3、爬虫（jsoup）

数据获取：数据库、消息队列、爬虫、…

①搜索京东搜索页面，并分析页面

http://search.jd.com/search?keyword=java

1

审查页面元素

页面列表id：J_goodsList

目标元素：img、price、name

②爬取数据（获取请求返回的页面信息，筛选出可用的）
创建HtmlParseUtil，并简单编写

public class HtmlParseUtil {    
    public static void main(String[] args) throws IOException {    
        /// 使用前需要联网 
        // 请求url 
        String url = "http://search.jd.com/search?keyword=java";   
        // 1.解析网页(jsoup 解析返回的对象是浏览器Document对象) 
        Document document = Jsoup.parse(new URL(url), 30000);  
        // 使用document可以使用在js对document的所有操作  
        // 2.获取元素（通过id）  
        Element j_goodsList = document.getElementById("J_goodsList");  
        // 3.获取J_goodsList ul 每一个 li    
        Elements lis = j_goodsList.getElementsByTag("li");
        // 4.获取li下的 img、price、name   
        for (Element li : lis) {
            String img = li.getElementsByTag("img").eq(0).attr("src");// 获取li下 第一张图片     
            String name = li.getElementsByClass("p-name").eq(0).text();  
            String price = li.getElementsByClass("p-price").eq(0).text();
            System.out.println("=======================");   
            System.out.println("img : " + img);
            System.out.println("name : " + name); 
            System.out.println("price : " + price);
        }
    }
}

原因是啥？

一般图片特别多的网站，所有的图片都是通过延迟加载的



// 打印标签内容
Elements lis = j_goodsList.getElementsByTag("li");System.out.println(lis);

打印所有li标签，发现img标签中并没有属性src的设置，只是data-lazy-ing设置图片加载的地址

img
创建HtmlParseUtil、改写

更改图片获取属性为 data-lazy-img

与实体类结合，实体类如下

@Data
@AllArgsConstructor
@NoArgsConstructor
public class Content implements Serializable {
    private static final long serialVersionUID = -8049497962627482693L;
    private String name;
    private String img;
    private String price;
}

封装为方法

public class HtmlParseUtil {
    public static void main(String[] args) throws IOException {
        System.out.println(parseJD("java"));
    }
    public static List<Content> parseJD(String keyword) throws IOException {
        /// 使用前需要联网
        // 请求url
        String url = "http://search.jd.com/search?keyword=" + keyword;
        // 1.解析网页(jsoup 解析返回的对象是浏览器Document对象)
        Document document = Jsoup.parse(new URL(url), 30000);
        // 使用document可以使用在js对document的所有操作
        // 2.获取元素（通过id）
        Element j_goodsList = document.getElementById("J_goodsList");
        // 3.获取J_goodsList ul 每一个 li
        Elements lis = j_goodsList.getElementsByTag("li");
//        System.out.println(lis);
        // 4.获取li下的 img、price、name
        // list存储所有li下的内容
        List<Content> contents = new ArrayList<Content>();
        for (Element li : lis) {
            // 由于网站图片使用懒加载，将src属性替换为data-lazy-img
            String img = li.getElementsByTag("img").eq(0).attr("data-lazy-img");// 获取li下 第一张图片
            String name = li.getElementsByClass("p-name").eq(0).text();
            String price = li.getElementsByClass("p-price").eq(0).text();
            // 封装为对象
            Content content = new Content(name,img,price);
            // 添加到list中
            contents.add(content);
        }
//        System.out.println(contents);
        // 5.返回 list
        return contents;
    }
}

4、搜索高亮

在3、的基础上添加内容

①ContentService

// 3、 在2的基础上进行高亮查询

public List<Map<String, Object>> highlightSearch(String keyword, Integer pageIndex, Integer pageSize) throws IOException {    
    SearchRequest searchRequest = new SearchRequest("jd_goods");    
    SearchSourceBuilder searchSourceBuilder = new SearchSourceBuilder();    
    // 精确查询，添加查询条件    
    TermQueryBuilder termQueryBuilder = QueryBuilders.termQuery("name", keyword);    			
    searchSourceBuilder.timeout(new TimeValue(60, TimeUnit.SECONDS));    
    searchSourceBuilder.query(termQueryBuilder);    
    // 分页    
    searchSourceBuilder.from(pageIndex);    
    searchSourceBuilder.size(pageSize);    
    // 高亮 =========
    HighlightBuilder highlightBuilder = new HighlightBuilder();    
    highlightBuilder.field("name");    
    highlightBuilder.preTags("");    
    highlightBuilder.postTags("");    
    searchSourceBuilder.highlighter(highlightBuilder);    
    // 执行查询
    searchRequest.source(searchSourceBuilder);    
    SearchResponse searchResponse = restHighLevelClient.search(searchRequest, RequestOptions.DEFAULT);    
    // 解析结果 
    SearchHits hits = searchResponse.getHits();    
    List<Map<String, Object>> results = new ArrayList<>();    
    for (SearchHit documentFields : hits.getHits()) {        
        // 使用新的字段值（高亮），覆盖旧的字段值        
        Map<String, Object> sourceAsMap = documentFields.getSourceAsMap();        
        // 高亮字段        
        Map<String, HighlightField> highlightFields = documentFields.getHighlightFields();        			
        HighlightField name = highlightFields.get("name");        
        // 替换        
        if (name != null){            
            Text[] fragments = name.fragments();            
            StringBuilder new_name = new StringBuilder();            
            for (Text text : fragments) {                
                new_name.append(text);
            }
            sourceAsMap.put("name",new_name.toString());
        }
        results.add(sourceAsMap);    
    }    
    return results;
}

1

②ContentController

@ResponseBody@GetMapping(“/h_search/{keyword}/{pageIndex}/{pageSize}”)public List> highlightParse(@PathVariable(“keyword”) String keyword, @PathVariable(“pageIndex”) Integer pageIndex, @PathVariable(“pageSize”) Integer pageSize) throws IOException { return contentService.highlightSearch(keyword,pageIndex,pageSize);}

1

③结果展示

img
5、前后端分离（简单使用Vue）

删除Controller 方法上的 @ResponseBody注解

img
①下载并引入Vue.min.js和axios.js

如果安装了nodejs，可以按如下步骤，没有可以到后面素材处下载

npm install vue
npm install axios

②修改静态页面
引入js

<script th:src="@{/js/vue.min.js}">script><script th:src="@{/js/axios.min.js}">script>

修改后的index.html

狂神说Java-ES仿京东实战

测试

img
安装包及前端素材

链接：https://pan.baidu.com/s/1M5uWdYsCZyzIAOcgcRkA_A
提取码：qk8p
复制这段内容后打开百度网盘手机App，操作更方便哦
疑惑：
1、使用term（精确查询）时，我发现三个问题，问题如下：

字段值必须是一个词（索引中存在的词），才能匹配

    问题：中文字符串，term查询时无法查询到数据（比如，“编程”两字在文档中存在，但是搜索不到）

    原因：索引为配置中文分词器（默认使用standard，即所有中文字符串都会被切分为单个中文汉字作为单词），所以没有超过1个汉字的词，也就无法匹配，进而查不到数据

    解决：创建索引时配置中文分词器，如

    PUT example
    {
      "mappings": {
        "properties": {
          "name":{
            "type": "text",
            "analyzer": "ik_max_word"  // ik分词器
          }
        }
      }
    }

​ 查询的英文字符只能是小写，大写都无效
​
​ 查询时英文单词必须是完整的

SpringBoot的检索

3、Elastic的快速入门

2、测试

下载POSTMAN，并使用POSTMAN测试

1、插入数据

PUT请求+请求体

PUT /megacorp/employee/1
{
    "first_name" : "John",
    "last_name" :  "Smith",
    "age" :        25,
    "about" :      "I love to go rock climbing",
    "interests": [ "sports", "music" ]
}

2、检索文档

重点：GET请求+URI+index+type+ID

GET /megacorp/employee/1

3、轻量检索

重点：GET请求+index+type+_search+条件（非必须）

搜索所有雇员： _search

GET /megacorp/employee/_search

高亮搜索：URL参数

GET /megacorp/employee/_search?q=last_name:Smith

4、使用查询表达式

重点：GET+URI+index+type+_search+请求体【match】

Query-string 搜索通过命令非常方便地进行临时性的即席搜索 ，但它有自身的局限性（参见 轻量 搜索 ）。Elasticsearch 提供一个丰富灵活的查询语言叫做 查询表达式 ，它支持构建更加复杂和健壮的查询。

领域特定语言 （DSL）， 指定了使用一个 JSON 请求。我们可以像这样重写之前的查询所有 Smith 的搜索 ：

GET /megacorp/employee/_search
{
    "query" : {
        "match" : {
            "last_name" : "Smith"
        }
    }
}

返回结果与之前的查询一样，但还是可以看到有一些变化。其中之一是，不再使用 query-string 参数，而是一个请求体替代。这个请求使用 JSON 构造，并使用了一个 match 查询（属于查询类型之一，后续将会了解）。

5、更加复杂的查询

重点：GET+URI+index+type+_search + 请求体【match+filter】

现在尝试下更复杂的搜索。 同样搜索姓氏为 Smith 的雇员，但这次我们只需要年龄大于 30 的。查询需要稍作调整，使用过滤器 filter ，它支持高效地执行一个结构化查询。

GET /megacorp/employee/_search
{
    "query" : {
        "bool": {
            "must": {
                "match" : {
                    "last_name" : "smith" 
                }
            },
            "filter": {
                "range" : {
                    "age" : { "gt" : 30 } 
                }
            }
        }
    }
}

我们添加了一个 过滤器 用于执行一个范围查询，并复用之前的 match 查询。现在结果只返回了一个雇员，叫 Jane Smith，32 岁。

6、全文搜索

重点：GET+index+type+_search+请求体【match】 ==》看相关性得分

截止目前的搜索相对都很简单：单个姓名，通过年龄过滤。现在尝试下稍微高级点儿的全文搜索——一项传统数据库确实很难搞定的任务。

搜索下所有喜欢攀岩（rock climbing）的雇员：

GET /megacorp/employee/_search
{
    "query" : {
        "match" : {
            "about" : "rock climbing"
        }
    }
}

显然我们依旧使用之前的 match 查询在about 属性上搜索 “rock climbing” 。得到两个匹配的文档：

{
   ...
   "hits": {
      "total":      2,
      "max_score":  0.16273327,
      "hits": [
         {
            ...
            "_score":         0.16273327, 
            "_source": {
               "first_name":  "John",
               "last_name":   "Smith",
               "age":         25,
               "about":       "I love to go rock climbing",
               "interests": [ "sports", "music" ]
            }
         },
         {
            ...
            "_score":         0.016878016, 
            "_source": {
               "first_name":  "Jane",
               "last_name":   "Smith",
               "age":         32,
               "about":       "I like to collect rock albums",
               "interests": [ "music" ]
            }
         }
      ]
   }
}

“_score”:相关性得分

Elasticsearch 默认按照相关性得分排序，即每个文档跟查询的匹配程度。第一个最高得分的结果很明显：John Smith 的 about 属性清楚地写着 “rock climbing” 。

但为什么 Jane Smith 也作为结果返回了呢？原因是她的 about 属性里提到了 “rock” 。因为只有 “rock” 而没有 “climbing” ，所以她的相关性得分低于 John 的。

这是一个很好的案例，阐明了 Elasticsearch 如何 在 全文属性上搜索并返回相关性最强的结果。Elasticsearch中的 相关性 概念非常重要，也是完全区别于传统关系型数据库的一个概念，数据库中的一条记录要么匹配要么不匹配。

7、短语搜索

重点：GET+index+type+_search+请求体【match_phrase 】

找出一个属性中的独立单词是没有问题的，但有时候想要精确匹配一系列单词或者短语 。 比如， 我们想执行这样一个查询，仅匹配同时包含 “rock” 和 “climbing” ，并且 二者以短语 “rock climbing” 的形式紧挨着的雇员记录。

为此对 match 查询稍作调整，使用一个叫做 match_phrase 的查询：

GET /megacorp/employee/_search
{
    "query" : {
        "match_phrase" : {
            "about" : "rock climbing"
        }
    }
}

返回的信息

{
   ...
   "hits": {
      "total":      1,
      "max_score":  0.23013961,
      "hits": [
         {
            ...
            "_score":         0.23013961,
            "_source": {
               "first_name":  "John",
               "last_name":   "Smith",
               "age":         25,
               "about":       "I love to go rock climbing",
               "interests": [ "sports", "music" ]
            }
         }
      ]
   }
}

8、高亮搜索

重点：GET+index+type+_search+请求体【match_phrase+highlight】==>返回关键字加了em标签

许多应用都倾向于在每个搜索结果中 高亮 部分文本片段，以便让用户知道为何该文档符合查询条件。在 Elasticsearch 中检索出高亮片段也很容易。

再次执行前面的查询，并增加一个新的 highlight 参数：

GET /megacorp/employee/_search
{
    "query" : {
        "match_phrase" : {
            "about" : "rock climbing"
        }
    },
    "highlight": {
        "fields" : {
            "about" : {}
        }
    }
}

当执行该查询时，返回结果与之前一样，与此同时结果中还多了一个叫做 highlight 的部分。这个部分包含了 about 属性匹配的文本片段，并以 HTML 标签  封装：

{
   ...
   "hits": {
      "total":      1,
      "max_score":  0.23013961,
      "hits": [
         {
            ...
            "_score":         0.23013961,
            "_source": {
               "first_name":  "John",
               "last_name":   "Smith",
               "age":         25,
               "about":       "I love to go rock climbing",
               "interests": [ "sports", "music" ]
            },
            "highlight": {
               "about": [
                  "I love to go rock climbing" 
               ]
            }
         }
      ]
   }
}

9、分析

重点：GET+index+type+_search+请求体【aggs-field】

aggs：聚合

终于到了最后一个业务需求：支持管理者对雇员目录做分析。 Elasticsearch 有一个功能叫聚合（aggregations），允许我们基于数据生成一些精细的分析结果。聚合与 SQL 中的 GROUP BY 类似但更强大。

举个例子，挖掘出雇员中最受欢迎的兴趣爱好：

GET /megacorp/employee/_search
{
  "aggs": {
    "all_interests": {
      "terms": { "field": "interests" }
    }
  }
}

会报错

Fielddata is disabled on text fields by default. Set fielddata=true on [inte

默认情况下，字段数据在文本字段上禁用。设置字段数据= TRUE

首先开启数据结构

PUT megacorp/_mapping/employee/
{
  "properties": {
    "interests": { 
      "type":     "text",
      "fielddata": true
    }
  }
}

然后在进行请求

{
   ...
   "hits": { ... },
   "aggregations": {
      "all_interests": {
         "buckets": [
            {
               "key":       "music",
               "doc_count": 2
            },
            {
               "key":       "forestry",
               "doc_count": 1
            },
            {
               "key":       "sports",
               "doc_count": 1
            }
         ]
      }
   }
}

可以看到，两位员工对音乐感兴趣，一位对林地感兴趣，一位对运动感兴趣。这些聚合并非预先统计，而是从匹配当前查询的文档中即时生成。

如果想知道叫 Smith 的雇员中最受欢迎的兴趣爱好，可以直接添加适当的查询来组合查询：

GET /megacorp/employee/_search
{
  "query": {
    "match": {
      "last_name": "smith"
    }
  },
  "aggs": {
    "all_interests": {
      "terms": {
        "field": "interests"
      }
    }
  }
}

all_interests 聚合已经变为只包含匹配查询的文档：

 ...
  "all_interests": {
     "buckets": [
        {
           "key": "music",
           "doc_count": 2
        },
        {
           "key": "sports",
           "doc_count": 1
        }
     ]
  }

聚合还支持分级汇总 。比如，查询特定兴趣爱好员工的平均年龄：

GET /megacorp/employee/_search
{
    "aggs" : {
        "all_interests" : {
            "terms" : { "field" : "interests" },
            "aggs" : {
                "avg_age" : {
                    "avg" : { "field" : "age" }
                }
            }
        }
    }
}

输出基本是第一次聚合的加强版。依然有一个兴趣及数量的列表，只不过每个兴趣都有了一个附加的 avg_age 属性，代表有这个兴趣爱好的所有员工的平均年龄。

即使现在不太理解这些语法也没有关系，依然很容易了解到复杂聚合及分组通过 Elasticsearch 特性实现得很完美。可提取的数据类型毫无限制。

4、SpringBoot+ElasticSearch

1、新建项目SpringBoot+Web+Nosql–>ElasticSearch

2、springBoot默认支持两种技术和ES进行交互

​ 1、Jest【需要导入使用】

​ 利用JestClient和服务器的9200端口进行http通信

​ 2、SpringData ElasticSearch【默认】

​ 1）、客户端:Client节点信息: clusterNodes: clusterName

​ 2）、ElasticsearchTemplate操作es

​ 3）、编写ElasticsearchRepository子接口

1、Jest

1、注释SpringDataElasticSearch的依赖，并导入Jest【5.xx】的相关依赖

        


        
        <dependency>
            <groupId>io.searchboxgroupId>
            <artifactId>jestartifactId>
            <version>5.3.3version>
        dependency>

2、修改配置文件application.yml

spring:
  elasticsearch:
    jest:
      uris: http://192.168.179.131:9200

3、创建 bean.Article

import io.searchbox.annotations.JestId;

public class Article {

    @JestId
    private Integer id;
    private String autor;
    private String title;
    private String content;

	//Getters and Setters...
}

4、运行程序

5、编写Jest Cilent的测试类

向wdjr-article中插入数据

@Autowired
JestClient jestClient;

@Test
public void contextLoads() {
    //1、给Es中索引（保存）一个文档
    Article article = new Article();
    article.setId(2);
    article.setTitle("好消息");
    article.setAutor("zhangsan");
    article.setContent("Hello World");
    //构建一个索引功能
    Index index = new Index.Builder(article).index("wdjr").type("article").build();

    try {
        //执行
        jestClient.execute(index);
    } catch (IOException e) {
        e.printStackTrace();
    }

}

查询数据

@Test
public void search(){
    //查询表达式
    String json = "{\n" +
            "    \"query\" : {\n" +
            "        \"match\" : {\n" +
            "            \"content\" : \"Hello\"\n" +
            "        }\n" +
            "    }\n" +
            "}";
    //构建搜索操作
    Search search = new Search.Builder(json).addIndex("wdjr").addType("article").build();

    //执行
    try {
        SearchResult result = jestClient.execute(search);
        System.out.println(result.getJsonString());
    } catch (IOException e) {
        e.printStackTrace();
    }

}

2、SpringData-Elastic

1、下载对应版本的ElasticSearch

如果版本不适配，会报错，解决方案：升级SpringBoot版本，或者安装合适的ES

spring data elasticsearch	elasticsearch
3.1.x	6.2.2
3.0.x	5.5.0
2.1.x	2.4.0
2.0.x	2.2.0
1.3.x	1.5.2

3、编写配置文件

<dependency>
    <groupId>org.springframework.bootgroupId>
    <artifactId>spring-boot-starter-data-elasticsearch<artifactId>
dependency>

spring:
  data:
    elasticsearch:
      repositories:
        enabled: true
      cluster-name: elasticsearch
      cluster-nodes: 192.168.179.131:9301

4、运行主程序

5、操作ElasticSearch有两种方式

1）、编写一个ElasticsearchRepositry

​ 2）、编写一个ElasticsearchTemplate

6、ElasticsearchRepositry的操作

1）、新建一个bean/Book类

@Data
@Document(indexName = "wdjr",type="book")
public class Book {

    private Integer id;
    private String bookName;
    private String auto;
}

2）、新建一个repositry/BookRepositry

public interface BookRepositry extends ElasticsearchRepository<Book,Integer> {
	//自定义查询方法
    public List<Book> findByBookNameLike(String bookName);
}

3）、编写测试类

@Autowired
BookRepositry bookRepositry;
@Test
public void testSearch(){
    for (Book book : bookRepositry.findByBookNameLike("金")) {
        System.out.println(book);
    }

}

集群

ES 集群由一个或多个 Elasticsearch 节点组成，每个节点配置相同的 cluster.name 即可加入集群，默认值为 “elasticsearch”。

一个 Elasticsearch 服务启动实例就是一个节点（Node）。节点通过 node.name 来设置节点名称，如果不设置则在启动时给节点分配一个随机通用唯一标识符作为名称。

①发现机制

那么有一个问题，ES 内部是如何通过一个相同的设置 cluster.name 就能将不同的节点连接到同一个集群的？答案是 Zen Discovery。

Zen Discovery 是 Elasticsearch 的内置默认发现模块（发现模块的职责是发现集群中的节点以及选举 Master 节点）。它提供单播和基于文件的发现，并且可以扩展为通过插件支持云环境和其他形式的发现。

Zen Discovery 与其他模块集成，例如，节点之间的所有通信都使用 Transport 模块完成。节点使用发现机制通过 Ping 的方式查找其他节点。

Elasticsearch 默认被配置为使用单播发现，以防止节点无意中加入集群。只有在同一台机器上运行的节点才会自动组成集群。

如果集群的节点运行在不同的机器上，使用单播，你可以为 Elasticsearch 提供一些它应该去尝试连接的节点列表。

当一个节点联系到单播列表中的成员时，它就会得到整个集群所有节点的状态，然后它会联系 Master 节点，并加入集群。

这意味着单播列表不需要包含集群中的所有节点， 它只是需要足够的节点，当一个新节点联系上其中一个并且说上话就可以了。

如果你使用 Master 候选节点作为单播列表，你只要列出三个就可以了。这个配置在 elasticsearch.yml 文件中：

discovery.zen.ping.unicast.hosts: ["host1", "host2:port"]  

节点启动后先 Ping ，如果 discovery.zen.ping.unicast.hosts 有设置，则 Ping 设置中的 Host ，否则尝试 ping localhost 的几个端口。

Elasticsearch 支持同一个主机启动多个节点，Ping 的 Response 会包含该节点的基本信息以及该节点认为的 Master 节点。

选举开始，先从各节点认为的 Master 中选，规则很简单，按照 ID 的字典序排序，取第一个。如果各节点都没有认为的 Master ，则从所有节点中选择，规则同上。

这里有个限制条件就是 discovery.zen.minimum_master_nodes ，如果节点数达不到最小值的限制，则循环上述过程，直到节点数足够可以开始选举。

最后选举结果是肯定能选举出一个 Master ，如果只有一个 Local 节点那就选出的是自己。

如果当前节点是 Master ，则开始等待节点数达到 discovery.zen.minimum_master_nodes，然后提供服务。

如果当前节点不是 Master ，则尝试加入 Master 。Elasticsearch 将以上服务发现以及选主的流程叫做 Zen Discovery 。

由于它支持任意数目的集群（ 1- N ），所以不能像 Zookeeper 那样限制节点必须是奇数，也就无法用投票的机制来选主，而是通过一个规则。

只要所有的节点都遵循同样的规则，得到的信息都是对等的，选出来的主节点肯定是一致的。

但分布式系统的问题就出在信息不对等的情况，这时候很容易出现脑裂（Split-Brain）的问题。

大多数解决方案就是设置一个 Quorum 值，要求可用节点必须大于 Quorum（一般是超过半数节点），才能对外提供服务。

而 Elasticsearch 中，这个 Quorum 的配置就是 discovery.zen.minimum_master_nodes 。

②节点的角色

每个节点既可以是候选主节点也可以是数据节点，通过在配置文件 …/config/elasticsearch.yml 中设置即可，默认都为 true。

node.master: true  //是否候选主节点  
node.data: true    //是否数据节点  

数据节点负责数据的存储和相关的操作，例如对数据进行增、删、改、查和聚合等操作，所以数据节点（Data 节点）对机器配置要求比较高，对 CPU、内存和 I/O 的消耗很大。

通常随着集群的扩大，需要增加更多的数据节点来提高性能和可用性。

候选主节点可以被选举为主节点（Master 节点），集群中只有候选主节点才有选举权和被选举权，其他节点不参与选举的工作。

主节点负责创建索引、删除索引、跟踪哪些节点是群集的一部分，并决定哪些分片分配给相关的节点、追踪集群中节点的状态等，稳定的主节点对集群的健康是非常重要的。

一个节点既可以是候选主节点也可以是数据节点，但是由于数据节点对 CPU、内存核 I/O 消耗都很大。

所以如果某个节点既是数据节点又是主节点，那么可能会对主节点产生影响从而对整个集群的状态产生影响。

因此为了提高集群的健康性，我们应该对 Elasticsearch 集群中的节点做好角色上的划分和隔离。可以使用几个配置较低的机器群作为候选主节点群。

主节点和其他节点之间通过 Ping 的方式互检查，主节点负责 Ping 所有其他节点，判断是否有节点已经挂掉。其他节点也通过 Ping 的方式判断主节点是否处于可用状态。

虽然对节点做了角色区分，但是用户的请求可以发往任何一个节点，并由该节点负责分发请求、收集结果等操作，而不需要主节点转发。

这种节点可称之为协调节点，协调节点是不需要指定和配置的，集群中的任何节点都可以充当协调节点的角色。

③脑裂现象

同时如果由于网络或其他原因导致集群中选举出多个 Master 节点，使得数据更新时出现不一致，这种现象称之为脑裂，即集群中不同的节点对于 Master 的选择出现了分歧，出现了多个 Master 竞争。

“脑裂”问题可能有以下几个原因造成：

• 网络问题： 集群间的网络延迟导致一些节点访问不到 Master，认为 Master 挂掉了从而选举出新的 Master，并对 Master 上的分片和副本标红，分配新的主分片。
• 节点负载： 主节点的角色既为 Master 又为 Data，访问量较大时可能会导致 ES 停止响应（假死状态）造成大面积延迟，此时其他节点得不到主节点的响应认为主节点挂掉了，会重新选取主节点。
• 内存回收： 主节点的角色既为 Master 又为 Data，当 Data 节点上的 ES 进程占用的内存较大，引发 JVM 的大规模内存回收，造成 ES 进程失去响应。

为了避免脑裂现象的发生，我们可以从原因着手通过以下几个方面来做出优化措施：

• 适当调大响应时间，减少误判。 通过参数 discovery.zen.ping_timeout 设置节点状态的响应时间，默认为 3s，可以适当调大。

如果 Master 在该响应时间的范围内没有做出响应应答，判断该节点已经挂掉了。调大参数（如 6s，discovery.zen.ping_timeout:6），可适当减少误判。

• 选举触发。 我们需要在候选集群中的节点的配置文件中设置参数 discovery.zen.munimum_master_nodes 的值。

这个参数表示在选举主节点时需要参与选举的候选主节点的节点数，默认值是 1，官方建议取值(master_eligibel_nodes2)+1，其中 master_eligibel_nodes 为候选主节点的个数。

这样做既能防止脑裂现象的发生，也能最大限度地提升集群的高可用性，因为只要不少于 discovery.zen.munimum_master_nodes 个候选节点存活，选举工作就能正常进行。

当小于这个值的时候，无法触发选举行为，集群无法使用，不会造成分片混乱的情况。

• 角色分离。 即是上面我们提到的候选主节点和数据节点进行角色分离，这样可以减轻主节点的负担，防止主节点的假死状态发生，减少对主节点“已死”的误判。

分片（Shards）

ES 支持 PB 级全文搜索，当索引上的数据量太大的时候，ES 通过水平拆分的方式将一个索引上的数据拆分出来分配到不同的数据块上，拆分出来的数据库块称之为一个分片。

这类似于 MySQL 的分库分表，只不过 MySQL 分库分表需要借助第三方组件而 ES 内部自身实现了此功能。

在一个多分片的索引中写入数据时，通过路由来确定具体写入哪一个分片中，所以在创建索引的时候需要指定分片的数量，并且分片的数量一旦确定就不能修改。

分片的数量和下面介绍的副本数量都是可以通过创建索引时的 Settings 来配置，ES 默认为一个索引创建 5 个主分片, 并分别为每个分片创建一个副本。

PUT /myIndex  
{  
   "settings" : {  
      "number_of_shards" : 5,  
      "number_of_replicas" : 1  
   }  
}  

ES 通过分片的功能使得索引在规模上和性能上都得到提升，每个分片都是 Lucene 中的一个索引文件，每个分片必须有一个主分片和零到多个副本。

副本（Replicas）

副本就是对分片的 Copy，每个主分片都有一个或多个副本分片，当主分片异常时，副本可以提供数据的查询等操作。

主分片和对应的副本分片是不会在同一个节点上的，所以副本分片数的最大值是 N-1（其中 N 为节点数）。

对文档的新建、索引和删除请求都是写操作，必须在主分片上面完成之后才能被复制到相关的副本分片。

ES 为了提高写入的能力这个过程是并发写的，同时为了解决并发写的过程中数据冲突的问题，ES 通过乐观锁的方式控制，每个文档都有一个 _version （版本）号，当文档被修改时版本号递增。

一旦所有的副本分片都报告写成功才会向协调节点报告成功，协调节点向客户端报告成功。

图片

从上图可以看出为了达到高可用，Master 节点会避免将主分片和副本分片放在同一个节点上。

假设这时节点 Node1 服务宕机了或者网络不可用了，那么主节点上主分片 S0 也就不可用了。

幸运的是还存在另外两个节点能正常工作，这时 ES 会重新选举新的主节点，而且这两个节点上存在我们所需要的 S0 的所有数据。

我们会将 S0 的副本分片提升为主分片，这个提升主分片的过程是瞬间发生的。此时集群的状态将会为 Yellow。

为什么我们集群状态是 Yellow 而不是 Green 呢？虽然我们拥有所有的 2 个主分片，但是同时设置了每个主分片需要对应两份副本分片，而此时只存在一份副本分片。所以集群不能为 Green 的状态。

如果我们同样关闭了 Node2 ，我们的程序依然可以保持在不丢失任何数据的情况下运行，因为 Node3 为每一个分片都保留着一份副本。

如果我们重新启动 Node1 ，集群可以将缺失的副本分片再次进行分配，那么集群的状态又将恢复到原来的正常状态。

如果 Node1 依然拥有着之前的分片，它将尝试去重用它们，只不过这时 Node1 节点上的分片不再是主分片而是副本分片了，如果期间有更改的数据只需要从主分片上复制修改的数据文件即可。

映射（Mapping）

映射是用于定义 ES 对索引中字段的存储类型、分词方式和是否存储等信息，就像数据库中的 Schema ，描述了文档可能具有的字段或属性、每个字段的数据类型。

只不过关系型数据库建表时必须指定字段类型，而 ES 对于字段类型可以不指定然后动态对字段类型猜测，也可以在创建索引时具体指定字段的类型。

对字段类型根据数据格式自动识别的映射称之为动态映射（Dynamic Mapping），我们创建索引时具体定义字段类型的映射称之为静态映射或显示映射（Explicit Mapping）。

在讲解动态映射和静态映射的使用前，我们先来了解下 ES 中的数据有哪些字段类型？之后我们再讲解为什么我们创建索引时需要建立静态映射而不使用动态映射。

ES（v6.8）中字段数据类型主要有以下几类：

Text 用于索引全文值的字段，例如电子邮件正文或产品说明。这些字段是被分词的，它们通过分词器传递 ，以在被索引之前将字符串转换为单个术语的列表。

分析过程允许 Elasticsearch 搜索单个单词中每个完整的文本字段。文本字段不用于排序，很少用于聚合。

Keyword 用于索引结构化内容的字段，例如电子邮件地址，主机名，状态代码，邮政编码或标签。它们通常用于过滤，排序，和聚合。Keyword 字段只能按其确切值进行搜索。

通过对字段类型的了解我们知道有些字段需要明确定义的，例如某个字段是 Text 类型还是 Keyword 类型差别是很大的，时间字段也许我们需要指定它的时间格式，还有一些字段我们需要指定特定的分词器等等。

如果采用动态映射是不能精确做到这些的，自动识别常常会与我们期望的有些差异。

所以创建索引的时候一个完整的格式应该是指定分片和副本数以及 Mapping 的定义，如下：

PUT my_index   
{  
   "settings" : {  
      "number_of_shards" : 5,  
      "number_of_replicas" : 1  
   }  
  "mappings": {  
    "_doc": {   
      "properties": {   
        "title":    { "type": "text"  },   
        "name":     { "type": "text"  },   
        "age":      { "type": "integer" },    
        "created":  {  
          "type":   "date",   
          "format": "strict_date_optional_time||epoch_millis"  
        }  
      }  
    }  
  }  
}  

集群健康状态

要检查群集运行状况，我们可以在 Kibana 控制台中运行以下命令 GET /_cluster/health，得到如下信息：

{  
  "cluster_name" : "wujiajian",  
  "status" : "yellow",  
  "timed_out" : false,  
  "number_of_nodes" : 1,  
  "number_of_data_nodes" : 1,  
  "active_primary_shards" : 9,  
  "active_shards" : 9,  
  "relocating_shards" : 0,  
  "initializing_shards" : 0,  
  "unassigned_shards" : 5,  
  "delayed_unassigned_shards" : 0,  
  "number_of_pending_tasks" : 0,  
  "number_of_in_flight_fetch" : 0,  
  "task_max_waiting_in_queue_millis" : 0,  
  "active_shards_percent_as_number" : 64.28571428571429  
}  

集群状态通过 绿，黄，红 来标识：

• 绿色：集群健康完好，一切功能齐全正常，所有分片和副本都可以正常工作。
• 黄色：预警状态，所有主分片功能正常，但至少有一个副本是不能正常工作的。此时集群是可以正常工作的，但是高可用性在某种程度上会受影响。
• 红色：集群不可正常使用。某个或某些分片及其副本异常不可用，这时集群的查询操作还能执行，但是返回的结果会不准确。对于分配到这个分片的写入请求将会报错，最终会导致数据的丢失。

当集群状态为红色时，它将会继续从可用的分片提供搜索请求服务，但是你需要尽快修复那些未分配的分片。

ES 机制原理

ES 的基本概念和基本操作介绍完了之后，我们可能还有很多疑惑：

• 它们内部是如何运行的？
• 主分片和副本分片是如何同步的？
• 创建索引的流程是什么样的？
• ES 如何将索引数据分配到不同的分片上的？以及这些索引数据是如何存储的？
• 为什么说 ES 是近实时搜索引擎而文档的 CRUD (创建-读取-更新-删除) 操作是实时的？
• 以及 Elasticsearch 是怎样保证更新被持久化在断电时也不丢失数据？
• 还有为什么删除文档不会立刻释放空间？

带着这些疑问我们进入接下来的内容。

写索引原理

下图描述了 3 个节点的集群，共拥有 12 个分片，其中有 4 个主分片（S0、S1、S2、S3）和 8 个副本分片（R0、R1、R2、R3），每个主分片对应两个副本分片，节点 1 是主节点（Master 节点）负责整个集群的状态。

写索引是只能写在主分片上，然后同步到副本分片。这里有四个主分片，一条数据 ES 是根据什么规则写到特定分片上的呢？

这条索引数据为什么被写到 S0 上而不写到 S1 或 S2 上？那条数据为什么又被写到 S3 上而不写到 S0 上了？

首先这肯定不会是随机的，否则将来要获取文档的时候我们就不知道从何处寻找了。

实际上，这个过程是根据下面这个公式决定的：

shard = hash(routing) % number_of_primary_shards  

Routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。

Routing 通过 Hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）后得到余数。

这个在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。

这就解释了为什么我们要在创建索引的时候就确定好主分片的数量并且永远不会改变这个数量：因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。

由于在 ES 集群中每个节点通过上面的计算公式都知道集群中的文档的存放位置，所以每个节点都有处理读写请求的能力。

在一个写请求被发送到某个节点后，该节点即为前面说过的协调节点，协调节点会根据路由公式计算出需要写到哪个分片上，再将请求转发到该分片的主分片节点上。

假如此时数据通过路由计算公式取余后得到的值是 shard=hash(routing)%4=0。

则具体流程如下：

• 客户端向 ES1 节点（协调节点）发送写请求，通过路由计算公式得到值为 0，则当前数据应被写到主分片 S0 上。
• ES1 节点将请求转发到 S0 主分片所在的节点 ES3，ES3 接受请求并写入到磁盘。
• 并发将数据复制到两个副本分片 R0 上，其中通过乐观并发控制数据的冲突。一旦所有的副本分片都报告成功，则节点 ES3 将向协调节点报告成功，协调节点向客户端报告成功。

存储原理

上面介绍了在 ES 内部索引的写处理流程，这个流程是在 ES 的内存中执行的，数据被分配到特定的分片和副本上之后，最终是存储到磁盘上的，这样在断电的时候就不会丢失数据。

具体的存储路径可在配置文件 ../config/elasticsearch.yml 中进行设置，默认存储在安装目录的 Data 文件夹下。

建议不要使用默认值，因为若 ES 进行了升级，则有可能导致数据全部丢失：

path.data: /path/to/data  //索引数据  
path.logs: /path/to/logs  //日志记录  

①分段存储

索引文档以段的形式存储在磁盘上，何为段？索引文件被拆分为多个子文件，则每个子文件叫作段，每一个段本身都是一个倒排索引，并且段具有不变性，一旦索引的数据被写入硬盘，就不可再修改。

在底层采用了分段的存储模式，使它在读写时几乎完全避免了锁的出现，大大提升了读写性能。

段被写入到磁盘后会生成一个提交点，提交点是一个用来记录所有提交后段信息的文件。

一个段一旦拥有了提交点，就说明这个段只有读的权限，失去了写的权限。相反，当段在内存中时，就只有写的权限，而不具备读数据的权限，意味着不能被检索。

段的概念提出主要是因为：在早期全文检索中为整个文档集合建立了一个很大的倒排索引，并将其写入磁盘中。

如果索引有更新，就需要重新全量创建一个索引来替换原来的索引。这种方式在数据量很大时效率很低，并且由于创建一次索引的成本很高，所以对数据的更新不能过于频繁，也就不能保证时效性。

索引文件分段存储并且不可修改，那么新增、更新和删除如何处理呢？

• 新增，新增很好处理，由于数据是新的，所以只需要对当前文档新增一个段就可以了。
• 删除，由于不可修改，所以对于删除操作，不会把文档从旧的段中移除而是通过新增一个 .del 文件，文件中会列出这些被删除文档的段信息。这个被标记删除的文档仍然可以被查询匹配到， 但它会在最终结果被返回前从结果集中移除。
• 更新，不能修改旧的段来进行反映文档的更新，其实更新相当于是删除和新增这两个动作组成。会将旧的文档在 .del 文件中标记删除，然后文档的新版本被索引到一个新的段中。可能两个版本的文档都会被一个查询匹配到，但被删除的那个旧版本文档在结果集返回前就会被移除。

段被设定为不可修改具有一定的优势也有一定的缺点，优势主要表现在：

• 不需要锁。如果你从来不更新索引，你就不需要担心多进程同时修改数据的问题。
• 一旦索引被读入内核的文件系统缓存，便会留在哪里，由于其不变性。只要文件系统缓存中还有足够的空间，那么大部分读请求会直接请求内存，而不会命中磁盘。这提供了很大的性能提升。
• 其它缓存(像 Filter 缓存)，在索引的生命周期内始终有效。它们不需要在每次数据改变时被重建，因为数据不会变化。
• 写入单个大的倒排索引允许数据被压缩，减少磁盘 I/O 和需要被缓存到内存的索引的使用量。

段的不变性的缺点如下：

• 当对旧数据进行删除时，旧数据不会马上被删除，而是在 .del 文件中被标记为删除。而旧数据只能等到段更新时才能被移除，这样会造成大量的空间浪费。
• 若有一条数据频繁的更新，每次更新都是新增新的标记旧的，则会有大量的空间浪费。
• 每次新增数据时都需要新增一个段来存储数据。当段的数量太多时，对服务器的资源例如文件句柄的消耗会非常大。
• 在查询的结果中包含所有的结果集，需要排除被标记删除的旧数据，这增加了查询的负担。

②延迟写策略

介绍完了存储的形式，那么索引写入到磁盘的过程是怎样的？是否是直接调 Fsync 物理性地写入磁盘？

答案是显而易见的，如果是直接写入到磁盘上，磁盘的 I/O 消耗上会严重影响性能。

那么当写数据量大的时候会造成 ES 停顿卡死，查询也无法做到快速响应。如果真是这样 ES 也就不会称之为近实时全文搜索引擎了。

为了提升写的性能，ES 并没有每新增一条数据就增加一个段到磁盘上，而是采用延迟写的策略。

每当有新增的数据时，就将其先写入到内存中，在内存和磁盘之间是文件系统缓存。

当达到默认的时间（1 秒钟）或者内存的数据达到一定量时，会触发一次刷新（Refresh），将内存中的数据生成到一个新的段上并缓存到文件缓存系统 上，稍后再被刷新到磁盘中并生成提交点。

这里的内存使用的是 ES 的 JVM 内存，而文件缓存系统使用的是操作系统的内存。

新的数据会继续的被写入内存，但内存中的数据并不是以段的形式存储的，因此不能提供检索功能。

由内存刷新到文件缓存系统的时候会生成新的段，并将段打开以供搜索使用，而不需要等到被刷新到磁盘。

在 Elasticsearch 中，写入和打开一个新段的轻量的过程叫做 Refresh （即内存刷新到文件缓存系统）。

默认情况下每个分片会每秒自动刷新一次。这就是为什么我们说 Elasticsearch 是近实时搜索，因为文档的变化并不是立即对搜索可见，但会在一秒之内变为可见。

我们也可以手动触发 Refresh，POST /_refresh 刷新所有索引，POST /nba/_refresh 刷新指定的索引。

Tips：尽管刷新是比提交轻量很多的操作，它还是会有性能开销。当写测试的时候， 手动刷新很有用，但是不要在生产>环境下每次索引一个文档都去手动刷新。而且并不是所有的情况都需要每秒刷新。

可能你正在使用 Elasticsearch 索引大量的日志文件， 你可能想优化索引速度而不是>近实时搜索。

这时可以在创建索引时在 Settings 中通过调大 refresh_interval = "30s" 的值 ， 降低每个索引的刷新频率，设值时需要注意后面带上时间单位，否则默认是毫秒。当 refresh_interval=-1 时表示关闭索引的自动刷新。

虽然通过延时写的策略可以减少数据往磁盘上写的次数提升了整体的写入能力，但是我们知道文件缓存系统也是内存空间，属于操作系统的内存，只要是内存都存在断电或异常情况下丢失数据的危险。

为了避免丢失数据，Elasticsearch 添加了事务日志（Translog），事务日志记录了所有还没有持久化到磁盘的数据。

图片

添加了事务日志后整个写索引的流程如上图所示：

• 一个新文档被索引之后，先被写入到内存中，但是为了防止数据的丢失，会追加一份数据到事务日志中。

  不断有新的文档被写入到内存，同时也都会记录到事务日志中。这时新数据还不能被检索和查询。

• 当达到默认的刷新时间或内存中的数据达到一定量后，会触发一次 Refresh，将内存中的数据以一个新段形式刷新到文件缓存系统中并清空内存。这时虽然新段未被提交到磁盘，但是可以提供文档的检索功能且不能被修改。

• 随着新文档索引不断被写入，当日志数据大小超过 512M 或者时间超过 30 分钟时，会触发一次 Flush。

  内存中的数据被写入到一个新段同时被写入到文件缓存系统，文件系统缓存中数据通过 Fsync 刷新到磁盘中，生成提交点，日志文件被删除，创建一个空的新日志。

通过这种方式当断电或需要重启时，ES 不仅要根据提交点去加载已经持久化过的段，还需要工具 Translog 里的记录，把未持久化的数据重新持久化到磁盘上，避免了数据丢失的可能。

③段合并

由于自动刷新流程每秒会创建一个新的段 ，这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。

每一个段都会消耗文件句柄、内存和 CPU 运行周期。更重要的是，每个搜索请求都必须轮流检查每个段然后合并查询结果，所以段越多，搜索也就越慢。

Elasticsearch 通过在后台定期进行段合并来解决这个问题。小的段被合并到大的段，然后这些大的段再被合并到更大的段。

段合并的时候会将那些旧的已删除文档从文件系统中清除。被删除的文档不会被拷贝到新的大段中。合并的过程中不会中断索引和搜索。

图片

段合并在进行索引和搜索时会自动进行，合并进程选择一小部分大小相似的段，并且在后台将它们合并到更大的段中，这些段既可以是未提交的也可以是已提交的。

合并结束后老的段会被删除，新的段被 Flush 到磁盘，同时写入一个包含新段且排除旧的和较小的段的新提交点，新的段被打开可以用来搜索。

段合并的计算量庞大， 而且还要吃掉大量磁盘 I/O，段合并会拖累写入速率，如果任其发展会影响搜索性能。

Elasticsearch 在默认情况下会对合并流程进行资源限制，所以搜索仍然有足够的资源很好地执行。

性能优化

存储设备

磁盘在现代服务器上通常都是瓶颈。Elasticsearch 重度使用磁盘，你的磁盘能处理的吞吐量越大，你的节点就越稳定。

这里有一些优化磁盘 I/O 的技巧：

• 使用 SSD。就像其他地方提过的， 他们比机械磁盘优秀多了。
• 使用 RAID 0。条带化 RAID 会提高磁盘 I/O，代价显然就是当一块硬盘故障时整个就故障了。不要使用镜像或者奇偶校验 RAID 因为副本已经提供了这个功能。
• 另外，使用多块硬盘，并允许 Elasticsearch 通过多个 path.data 目录配置把数据条带化分配到它们上面。
• 不要使用远程挂载的存储，比如 NFS 或者 SMB/CIFS。这个引入的延迟对性能来说完全是背道而驰的。
• 如果你用的是 EC2，当心 EBS。即便是基于 SSD 的 EBS，通常也比本地实例的存储要慢。

内部索引优化

图片

Elasticsearch 为了能快速找到某个 Term，先将所有的 Term 排个序，然后根据二分法查找 Term，时间复杂度为 logN，就像通过字典查找一样，这就是 Term Dictionary。

现在再看起来，似乎和传统数据库通过 B-Tree 的方式类似。但是如果 Term 太多，Term Dictionary 也会很大，放内存不现实，于是有了 Term Index。

就像字典里的索引页一样，A 开头的有哪些 Term，分别在哪页，可以理解 Term Index是一棵树。

这棵树不会包含所有的 Term，它包含的是 Term 的一些前缀。通过 Term Index 可以快速地定位到 Term Dictionary 的某个 Offset，然后从这个位置再往后顺序查找。

在内存中用 FST 方式压缩 Term Index，FST 以字节的方式存储所有的 Term，这种压缩方式可以有效的缩减存储空间，使得 Term Index 足以放进内存，但这种方式也会导致查找时需要更多的 CPU 资源。

对于存储在磁盘上的倒排表同样也采用了压缩技术减少存储所占用的空间。

调整配置参数

调整配置参数建议如下：

• 给每个文档指定有序的具有压缩良好的序列模式 ID，避免随机的 UUID-4 这样的 ID，这样的 ID 压缩比很低，会明显拖慢 Lucene。

• 对于那些不需要聚合和排序的索引字段禁用 Doc values。Doc Values 是有序的基于 document=>field value 的映射列表。

• 不需要做模糊检索的字段使用 Keyword 类型代替 Text 类型，这样可以避免在建立索引前对这些文本进行分词。

• 如果你的搜索结果不需要近实时的准确度，考虑把每个索引的 index.refresh_interval 改到 30s 。

  如果你是在做大批量导入，导入期间你可以通过设置这个值为 -1 关掉刷新，还可以通过设置 index.number_of_replicas: 0 关闭副本。别忘记在完工的时候重新开启它。

• 避免深度分页查询建议使用 Scroll 进行分页查询。普通分页查询时，会创建一个 from+size 的空优先队列，每个分片会返回 from+size 条数据，默认只包含文档 ID 和得分 Score 给协调节点。

  如果有 N 个分片，则协调节点再对（from+size）×n 条数据进行二次排序，然后选择需要被取回的文档。当 from 很大时，排序过程会变得很沉重，占用 CPU 资源严重。

• 减少映射字段，只提供需要检索，聚合或排序的字段。其他字段可存在其他存储设备上，例如 Hbase，在 ES 中得到结果后再去 Hbase 查询这些字段。

• 创建索引和查询时指定路由 Routing 值，这样可以精确到具体的分片查询，提升查询效率。路由的选择需要注意数据的分布均衡。

JVM 调优

JVM 调优建议如下：

• 确保堆内存最小值（ Xms ）与最大值（ Xmx ）的大小是相同的，防止程序在运行时改变堆内存大小。Elasticsearch 默认安装后设置的堆内存是 1GB。可通过 ../config/jvm.option 文件进行配置，但是最好不要超过物理内存的50%和超过 32GB。
• GC 默认采用 CMS 的方式，并发但是有 STW 的问题，可以考虑使用 G1 收集器。
• ES 非常依赖文件系统缓存（Filesystem Cache），快速搜索。一般来说，应该至少确保物理上有一半的可用内存分配到文件系统缓存。

优化

项目背景：

在一业务系统中，部分表每天的数据量过亿，已按天分表，但业务上受限于按天查询，并且DB中只能保留3个月的数据(硬件高配)，分库代价较高。

改进版本目标：

\1. 数据能跨月查询，并且支持1年以上的历史数据查询与导出。

\2. 按条件的数据查询秒级返回。

三、ES 检索原理

3.1 关于ES和Lucene基础结构

谈到优化，必须能了解组件的基本原理，才容易找到瓶颈所在，以免走多种弯路，先从ES的基础结构说起(如下图)：

一些基本概念:

• Cluster 包含多个Node的集群
• Node 集群服务单元
• Index 一个ES索引包含一个或多个物理分片，它只是这些分片的逻辑命名空间
• Type 一个index的不同分类，6.x后只能配置一个type，以后将移除
• Document 最基础的可被索引的数据单元，如一个JSON串
• Shards 一个分片是一个底层的工作单元，它仅保存全部数据中的一部分，它是一个Lucence实例 (一个lucene索引最大包含2,147,483,519 (= Integer.MAX_VALUE - 128)个文档数量)
• Replicas 分片备份，用于保障数据安全与分担检索压力

ES依赖一个重要的组件Lucene，关于数据结构的优化通常来说是对Lucene的优化，它是集群的一个存储于检索工作单元，结构如下图：

在Lucene中，分为索引(录入)与检索(查询)两部分，索引部分包含 分词器、过滤器、字符映射器 等，检索部分包含 查询解析器 等。

一个Lucene索引包含多个segments，一个segment包含多个文档，每个文档包含多个字段，每个字段经过分词后形成一个或多个term。

通过Luke工具查看ES的lucene文件如下，主要增加了_id和_source字段:

**
**

3.2 Lucene索引实现

Lucene 索引文件结构主要的分为：词典、倒排表、正向文件、DocValues等，如下图:

注：整理来源于lucene官方:

http://lucene.apache.org/core/7_2_1/core/org/apache/lucene/codecs/lucene70/package-summary.html#package.description

Lucene 随机三次磁盘读取比较耗时。其中.fdt文件保存数据值损耗空间大，.tim和.doc则需要SSD存储提高随机读写性能。

另外一个比较消耗性能的是打分流程，不需要则可屏蔽。

关于DocValues：

倒排索引解决从词快速检索到相应文档ID, 但如果需要对结果进行排序、分组、聚合等操作的时候则需要根据文档ID快速找到对应的值。

通过倒排索引代价却很高：需迭代索引里的每个词项并收集文档的列里面 token。这很慢而且难以扩展：随着词项和文档的数量增加，执行时间也会增加。

Solr docs对此的解释如下：

For other features that we now commonly associate with search, such as sorting, faceting, and highlighting, this approach is not very efficient. The faceting engine, for example, must look up each term that appears in each document that will make up the result set and pull the document IDs in order to build the facet list. In Solr, this is maintained in memory, and can be slow to load (depending on the number of documents, terms, etc.)

在lucene 4.0版本前通过FieldCache，原理是通过按列逆转倒排表将（field value ->doc）映射变成（doc -> field value）映射，问题为逐步构建时间长并且消耗大量内存，容易造成OOM。

DocValues是一种列存储结构，能快速通过文档ID找到相关需要排序的字段。

在ES中，默认开启所有(除了标记需analyzed的字符串字段)字段的doc values，如果不需要对此字段做任何排序等工作，则可关闭以减少资源消耗。

3.3 关于ES索引与检索分片

ES中一个索引由一个或多个lucene索引构成，一个lucene索引由一个或多个segment构成，其中segment是最小的检索域。

数据具体被存储到哪个分片上： shard = hash(routing) % number_of_primary_shards

默认情况下 routing参数是文档ID (murmurhash3),可通过 URL中的 _routing 参数指定数据分布在同一个分片中，index和search的时候都需要一致才能找到数据

如果能明确根据_routing进行数据分区，则可减少分片的检索工作，以提高性能。

四、优化案例

在我们的案例中，查询字段都是固定的，不提供全文检索功能，这也是几十亿数据能秒级返回的一个大前提：

1、ES仅提供字段的检索，仅存储HBase的Rowkey不存储实际数据。

2、实际数据存储在HBase中，通过Rowkey查询，如下图。

3、提高索引与检索的性能建议，可参考官方文档（如 https://www.elastic.co/guide/en/elasticsearch/reference/current/tune-for-indexing-speed.html）

一些细节优化项官方与其他的一些文章都有描述，在此文章中仅提出一些本案例的重点优化项。

4.1 优化索引性能

1、批量写入，看每条数据量的大小，一般都是几百到几千。

2、多线程写入，写入线程数一般和机器数相当，可以配多种情况，在测试环境通过Kibana观察性能曲线。

3、增加segments的刷新时间，通过上面的原理知道，segment作为一个最小的检索单元，比如segment有50个，目的需要查10条数据，但需要从50个segment

分别查询10条，共500条记录，再进行排序或者分数比较后，截取最前面的10条，丢弃490条。在我们的案例中将此 “refresh_interval”: “-1” ，程序批量写入完成后

进行手工刷新(调用相应的API即可)。

4、内存分配方面，很多文章已经提到，给系统50%的内存给Lucene做文件缓存，它任务很繁重，所以ES节点的内存需要比较多(比如每个节点能配置64G以上最好）。

5、磁盘方面配置SSD，机械盘做阵列RAID5 RAID10虽然看上去很快，但是随机IO还是SSD好。

6、 使用自动生成的ID，在我们的案例中使用自定义的KEY，也就是与HBase的ROW KEY，是为了能根据rowkey删除和更新数据，性能下降不是很明显。

7、关于段合并，合并在后台定期执行，比较大的segment需要很长时间才能完成，为了减少对其他操作的影响(如检索)，elasticsearch进行阈值限制，默认是20MB/s，

可配置的参数：“indices.store.throttle.max_bytes_per_sec” : “200mb” （根据磁盘性能调整）

合并线程数默认是：Math.max(1, Math.min(4, Runtime.getRuntime().availableProcessors() / 2))，如果是机械磁盘，可以考虑设置为1：index.merge.scheduler.max_thread_count: 1，

在我们的案例中使用SSD，配置了6个合并线程。

4.2 优化检索性能

1、关闭不需要字段的doc values。

2、尽量使用keyword替代一些long或者int之类，term查询总比range查询好 (参考lucene说明 http://lucene.apache.org/core/7_4_0/core/org/apache/lucene/index/PointValues.html)。

3、关闭不需要查询字段的_source功能，不将此存储仅ES中，以节省磁盘空间。

4、评分消耗资源，如果不需要可使用filter过滤来达到关闭评分功能，score则为0，如果使用constantScoreQuery则score为1。

5、关于分页：

（1）from + size:

每分片检索结果数最大为 from + size，假设from = 20, size = 20，则每个分片需要获取20 * 20 = 400条数据，多个分片的结果在协调节点合并(假设请求的分配数为5，则结果数最大为 400*5 = 2000条) 再在内存中排序后然后20条给用户。

这种机制导致越往后分页获取的代价越高，达到50000条将面临沉重的代价，默认from + size默认如下：

index.max_result_window ：10000

(2) search_after: 使用前一个分页记录的最后一条来检索下一个分页记录，在我们的案例中，首先使用from+size，检索出结果后再使用search_after，在页面上我们限制了用户只能跳5页，不能跳到最后一页。

(3) scroll 用于大结果集查询，缺陷是需要维护scroll_id

6、关于排序：我们增加一个long字段，它用于存储时间和ID的组合(通过移位即可)，正排与倒排性能相差不明显。

7、关于CPU消耗，检索时如果需要做排序则需要字段对比，消耗CPU比较大，如果有可能尽量分配16cores以上的CPU，具体看业务压力。

8、关于合并被标记删除的记录，我们设置为0表示在合并的时候一定删除被标记的记录，默认应该是大于10%才删除：“merge.policy.expunge_deletes_allowed”: “0”。

{
    "mappings": {
        "data": {
            "dynamic": "false",
            "_source": {
                "includes": ["XXX"]  -- 仅将查询结果所需的数据存储仅_source中
            },
            "properties": {
                "state": {
                    "type": "keyword",   -- 虽然state为int值，但如果不需要做范围查询，尽量使用keyword，因为int需要比keyword增加额外的消耗。
                    "doc_values": false  -- 关闭不需要字段的doc values功能，仅对需要排序，汇聚功能的字段开启。
                },
                "b": {
                    "type": "long"    -- 使用了范围查询字段，则需要用long或者int之类 （构建类似KD-trees结构）
                }
            }
        }
    },
   "settings": {......}
}

五、性能测试

优化效果评估基于基准测试，如果没有基准测试无法了解是否有性能提升，在这所有的变动前做一次测试会比较好。在我们的案例中：

1、单节点5千万到一亿的数据量测试，检查单点承受能力。

2、集群测试1亿-30亿的数量，磁盘IO/内存/CPU/网络IO消耗如何。

3、随机不同组合条件的检索，在各个数据量情况下表现如何。

4、另外SSD与机械盘在测试中性能差距如何。

性能的测试组合有很多，通常也很花时间，不过作为评测标准时间上的投入有必要，否则生产出现性能问题很难定位或不好改善。

对于ES的性能研究花了不少时间，最多的关注点就是lucene的优化，能深入了解lucene原理对优化有很大的帮助。

六、生产效果

目前平台稳定运行，几十亿的数据查询100条都在3秒内返回，前后翻页很快，如果后续有性能瓶颈，可通过扩展节点分担数据压力。

风吹的有点冷

​ ES JVM的内存建议不超过30GB，因为这样可以用到指针压缩技术。64GB不浪费吗

码哥字节(作者)

​ 不浪费哦，预留的一半内存用作操作系统文件读取，刷写缓存