Elasticsearch7.8

Elasticsearch7.8

简介

官网：https://www.elastic.co/cn/elasticsearch/

The Elastic Stack, 包括Elasticsearch、Kibana、Beats 和Logstash（也称为ELK Stack）。能够安全可靠地获取任何来源、任何格式的数据，然后实时地对数据进行搜索、分析和可视化。Elaticsearch，简称为ES，ES是一个开源的高扩展的分布式全文搜索引擎，是整个Elastic Stack技术栈的核心。它可以近乎实时的存储、检索数据；本身扩展性很好，可以扩展到上百台服务器，处理PB级别的数据。

数据格式

ES 里的 Index 可以看做一个库，而 Types 相当于表，Documents 则相当于表的行。
这里 Types 的概念已经被逐渐弱化，Elasticsearch 6.X 中，一个 index 下已经只能包含一个
type，Elasticsearch 7.X 中, Type 的概念已经被删除了。

es部署安装

Linux单机

软件下载地址：https://www.elastic.co/cn/downloads/past-releases/elasticsearch-7-8-0
解压：tar -zxvf elasticsearch-7.8.0-linux-x86_64.tar.gz;
创建用户:因为安全问题，Elasticsearch 不允许 root 用户直接运行，所以要创建新用户，在 root 用
户中创建新用户

useradd es #新增 es 用户
passwd es #为 es 用户设置密码
userdel -r es #如果错了，可以删除再加
chown -R es:es /usr/local/es/es-7.8.0 #文件夹所有者

/usr/local/es/es-7.8.0 这是es解压之后的文件路径
修改配置文件
修改/usr/local/es/es-7.8.0/config/elasticsearch.yml 文件

# 加入如下配置
cluster.name: elasticsearch
node.name: node-1
network.host: 0.0.0.0
http.port: 9200
cluster.initial_master_nodes: ["node-1"]

修改/etc/security/limits.conf

# 在文件末尾中增加下面内容
# 每个进程可以打开的文件数的限制
es soft nofile 65536
es hard nofile 65536 

修改/etc/security/limits.d/20-nproc.conf

# 在文件末尾中增加下面内容
# 每个进程可以打开的文件数的限制
es soft nofile 65536
es hard nofile 65536
# 操作系统级别对每个用户创建的进程数的限制
* hard nproc 4096
# 注：* 带表 Linux 所有用户名称

修改/etc/sysctl.conf

# 在文件中增加下面内容
# 一个进程可以拥有的 VMA(虚拟内存区域)的数量,默认值为 65536
vm.max_map_count=655360

重新加载

sysctl -p

启动软件

#启动
bin/elasticsearch
#后台启动
bin/elasticsearch -d

访问http://localhost:9200/
出现：

表示启动成功
启动异常处理：
如果使用root用户启动：

切换之前创建的es用户启动 su es

出现以下异常：

启动时，会动态生成文件，如果文件所属用户不匹配，会发生错误，需要重新进行修改用户
和用户组
重新执行chown -R es:es es的路径

集群部署

准备三个节点192.168.3.118、192.168.3.119、192.168.3.120
除了elasticsearch.yml文件修改不一样以外，其他步骤和单机部署相同
修改配置文件
修改/usr/local/es/es-7.8.0/config/elasticsearch.yml 文件

# 加入如下配置
#集群名称
cluster.name: cluster-es
#节点名称，每个节点的名称不能重复
node.name: node-1
#ip 地址，每个节点的地址不能重复
network.host: 192.168.3.118
#是不是有资格主节点
node.master: true
node.data: true
http.port: 9200
# head 插件需要这打开这两个配置
http.cors.allow-origin: "*"
http.cors.enabled: true
http.max_content_length: 200mb
#es7.x 之后新增的配置，初始化一个新的集群时需要此配置来选举 master
cluster.initial_master_nodes: ["node-1"]
#es7.x 之后新增的配置，节点发现
discovery.seed_hosts: ["192.168.3.118:9300","192.168.3.119:9300","192.168.3.120:9300"]
gateway.recover_after_nodes: 2
network.tcp.keep_alive: true
network.tcp.no_delay: true
transport.tcp.compress: true
#集群内同时启动的数据任务个数，默认是 2 个
cluster.routing.allocation.cluster_concurrent_rebalance: 16
#添加或删除节点及负载均衡时并发恢复的线程个数，默认 4 个
cluster.routing.allocation.node_concurrent_recoveries: 16
#初始化数据恢复时，并发恢复线程的个数，默认 4 个
cluster.routing.allocation.node_initial_primaries_recoveries: 16

其他两个节点的配置文件只需要修改节点地址(network.host)和名称(node.name)。其他不用修改

按照单机方式依次启动每个节点，访问其中一个节点
http://localhost:9200/_cat/nodes

说明集群部署成功
如果es节点不能加入到集群，删除每个es节点的data目录下的数据，在重新启动

核心概念

索引(Index)

• 一个索引就是一个拥有几分相似特征的文档的集合。比如说，你可以有一个客户数据的
  索引，另一个产品目录的索引，还有一个订单数据的索引。一个索引由一个名字来标识（必
  须全部是小写字母），并且当我们要对这个索引中的文档进行索引、搜索、更新和删除的时
  候，都要使用到这个名字。在一个集群中，可以定义任意多的索引。
  能搜索的数据必须索引，这样的好处是可以提高查询速度，比如：新华字典前面的目录
  就是索引的意思，目录可以提高查询速度。
  Elasticsearch 索引的精髓：一切设计都是为了提高搜索的性能。

文档(Document)

• 一个文档是一个可被索引的基础信息单元，也就是一条数据
  比如：你可以拥有某一个客户的文档，某一个产品的一个文档，当然，也可以拥有某个
  订单的一个文档。文档以 JSON（Javascript Object Notation）格式来表示，而 JSON 是一个
  到处存在的互联网数据交互格式。
  在一个 index/type 里面，你可以存储任意多的文档。

字段(Field)

• 相当于是数据表的字段，对文档数据根据不同属性进行的分类标识。

映射(Mapping)

• mapping 是处理数据的方式和规则方面做一些限制，如：某个字段的数据类型、默认值、
  分析器、是否被索引等等。这些都是映射里面可以设置的，其它就是处理 ES 里面数据的一
  些使用规则设置也叫做映射，按着最优规则处理数据对性能提高很大，因此才需要建立映射，
  并且需要思考如何建立映射才能对性能更好

分片(Shards)

类似于mysql分表

• 一个索引可以存储超出单个节点硬件限制的大量数据。比如，一个具有 10 亿文档数据
  的索引占据 1TB 的磁盘空间，而任一节点都可能没有这样大的磁盘空间。或者单个节点处
  理搜索请求，响应太慢。为了解决这个问题，Elasticsearch 提供了将索引划分成多份的能力，
  每一份就称之为分片。当你创建一个索引的时候，你可以指定你想要的分片的数量。每个分
  片本身也是一个功能完善并且独立的“索引”，这个“索引”可以被放置到集群中的任何节点
  上。
  分片很重要，主要有两方面的原因：
  1）允许你水平分割 / 扩展你的内容容量。
  2）允许你在分片之上进行分布式的、并行的操作，进而提高性能/吞吐量。
  至于一个分片怎样分布，它的文档怎样聚合和搜索请求，是完全由 Elasticsearch 管理的，
  对于作为用户的你来说，这些都是透明的，无需过分关心。
  被混淆的概念是，一个 Lucene 索引 我们在 Elasticsearch 称作 分片 。 一个
  Elasticsearch 索引 是分片的集合。 当 Elasticsearch 在索引中搜索的时候， 他发送查询
  到每一个属于索引的分片(Lucene 索引)，然后合并每个分片的结果到一个全局的结果集。

副本(Replicas)

• 在一个网络 / 云的环境里，失败随时都可能发生，在某个分片/节点不知怎么的就处于
  离线状态，或者由于任何原因消失了，这种情况下，有一个故障转移机制是非常有用并且是
  强烈推荐的。为此目的，Elasticsearch 允许你创建分片的一份或多份拷贝，这些拷贝叫做复
  制分片(副本)。
  复制分片之所以重要，有两个主要原因：
  1）在分片/节点失败的情况下，提供了高可用性。因为这个原因，注意到复制分片从不与
  原/主要（original/primary）分片置于同一节点上是非常重要的。
  2） 扩展你的搜索量/吞吐量，因为搜索可以在所有的副本上并行运行
  总之，每个索引可以被分成多个分片。一个索引也可以被复制 0 次（意思是没有复制）
  或多次。一旦复制了，每个索引就有了主分片（作为复制源的原来的分片）和复制分片（主
  分片的拷贝）之别。分片和复制的数量可以在索引创建的时候指定。在索引创建之后，你可
  以在任何时候动态地改变复制的数量，但是你事后不能改变分片的数量。默认情况下，
  Elasticsearch 中的每个索引被分片 1 个主分片和 1 个复制，这意味着，如果你的集群中至少
  有两个节点，你的索引将会有 1 个主分片和另外 1 个复制分片（1 个完全拷贝），这样的话
  每个索引总共就有 2 个分片，我们需要根据索引需要确定分片个数。

分配(Allocation)

• 将分片分配给某个节点的过程，包括分配主分片或者副本。如果是副本，还包含从主分
  片复制数据的过程。这个过程是由 master 节点完成的。

系统架构

一个运行中的 Elasticsearch 实例称为一个节点，而集群是由一个或者多个拥有相同
cluster.name 配置的节点组成， 它们共同承担数据和负载的压力。当有节点加入集群中或者
从集群中移除节点时，集群将会重新平均分布所有的数据。
当一个节点被选举成为主节点时， 它将负责管理集群范围内的所有变更，例如增加、
删除索引，或者增加、删除节点等。 而主节点并不需要涉及到文档级别的变更和搜索等操
作，所以当集群只拥有一个主节点的情况下，即使流量的增加它也不会成为瓶颈。 任何节
点都可以成为主节点。我们的示例集群就只有一个节点，所以它同时也成为了主节点。
作为用户，我们可以将请求发送到集群中的任何节点 ，包括主节点。 每个节点都知道
任意文档所处的位置，并且能够将我们的请求直接转发到存储我们所需文档的节点。 无论
我们将请求发送到哪个节点，它都能负责从各个包含我们所需文档的节点收集回数据，并将
最终结果返回給客户端。 Elasticsearch 对这一切的管理都是透明的。

分布式集群使用

创建分片、副本

根据前面搭建的es集群，为集群创建一个user索引，并为索引创建分片和副本

通过 elasticsearch-head 插件查看集群情况

星号表示主节点，每一个节点012表示三个几点，相同的012表示副本

集群故障

当有某个节点宕机了，本次将node3关闭

此时es集群会自动分配副本和分片

重新启动node3

水平扩容

怎样为我们的正在增长中的应用程序按需扩容呢？当启动了第四个节点，我们的集群将
会拥有四个节点的集群 : 为了分散负载而对分片进行重新分配
这个node3关闭 在重启后相似，重新分配分片和副本

工作流程和原理

路由计算和分片控制

路由计算
当索引一个文档的时候，文档会被存储到一个主分片中。 Elasticsearch 如何知道一个
文档应该存放到哪个分片中呢？当我们创建文档时，它如何决定这个文档应当被存储在分片
1 还是分片 2 中呢？首先这肯定不会是随机的，否则将来要获取文档的时候我们就不知道
从何处寻找了。实际上，这个过程是根据下面这个公式决定的：

routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。 routing 通过
hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）
后得到余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求
的文档所在分片的位置。
这就解释了为什么我们要在创建索引的时候就确定好主分片的数量 并且永远不会改变
这个数量：因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。
所有的文档 API（ get 、 index 、 delete 、 bulk 、 update 以及 mget ）都接受一
个叫做 routing 的路由参数 ，通过这个参数我们可以自定义文档到分片的映射。一个自定
义的路由参数可以用来确保所有相关的文档——例如所有属于同一个用户的文档——都被
存储到同一个分片中。
分片控制
我们可以发送请求到集群中的任一节点。 每个节点都有能力处理任意请求。 每个节点都知
道集群中任一文档位置，所以可以直接将请求转发到需要的节点上。被发送请求的节点我们将其称为协调节点(coordinating node)
当发送请求的时候， 为了扩展负载，更好的做法是轮询集群中所有的节点。

写流程

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

新建，索引和删除文档所需要的步骤顺序：

1. 客户端向 Node 1 发送新建、索引或者删除请求。
2. 节点使用文档的 _id 确定文档属于分片 0 。请求会被转发到 Node 3，因为分片 0 的
   主分片目前被分配在 Node 3 上。
3. Node 3 在主分片上面执行请求。如果成功了，它将请求并行转发到 Node 1 和 Node 2
   的副本分片上。一旦所有的副本分片都报告成功, Node 3 将向协调节点报告成功，协调
   节点向客户端报告成功。
   在客户端收到成功响应时，文档变更已经在主分片和所有副本分片执行完成，变更是安全的。
   有一些可选的请求参数允许您影响这个过程，可能以数据安全为代价提升性能。这些选项很
   少使用，因为 Elasticsearch 已经很快，但是为了完整起见，请参考下面表格：

参数	含义
consistency	consistency，即一致性。在默认设置下，即使仅仅是在试图执行一个_写_操作之前，主分片都会要求 必须要有 规定数量(quorum)（或者换种说法，也即必须要有大多数）的分片副本处于活跃可用状态，才会去执行_写_操作(其中分片副本可以是主分片或者副本分片)。这是为了避免在发生网络分区故障（network partition）的时候进行_写_操作，进而导致数据不一致。规定数量_即：int( (primary + number_of_replicas) / 2 ) + 1 。consistency 参数的值可以设为 one （只要主分片状态 ok 就允许执行_写_操作）,all（必须要主分片和所有副本分片的状态没问题才允许执行_写_操作）, 或 quorum 。默认值为 quorum , 即大多数的分片副本状态没问题就允许执行_写 操作。 注意，规定数量 的计算公式中 number_of_replicas 指的是在索引设置中的设定副本分片数，而不是指当前处理活动状态的副本分片数。如果你的索引设置中指定了当前索引拥有三个副本分片，那规定数量的计算结果即：int( (primary + 3 replicas) / 2 ) + 1 = 3如果此时你只启动两个节点，那么处于活跃状态的分片副本数量就达不到规定数量，也因此您将无法索引和删除任何文档。
timeout	如果没有足够的副本分片会发生什么？ Elasticsearch 会等待，希望更多的分片出现。默认情况下，它最多等待1 分钟。 如果你需要，你可以使用 timeout 参数使它更早终止： 100 100 毫秒，30s 是 30 秒。

es是一个近实时搜索的服务，延迟时间=主分片的延时+并行写入副本的最大延迟时间

读流程

1.客户端向 Node 1 发送获取请求。
2. 节点使用文档的 _id 来确定文档属于分片 0 。分片 0 的副本分片存在于所有的三个
节点上。 在这种情况下，它将请求转发到 Node 2 。
3. Node 2 将文档返回给 Node 1 ，然后将文档返回给客户端。
在处理读取请求时，协调结点在每次请求的时候都会通过轮询所有的副本分片来达到负载均
衡。在文档被检索时，已经被索引的文档可能已经存在于主分片上但是还没有复制到副本分
片。 在这种情况下，副本分片可能会报告文档不存在，但是主分片可能成功返回文档。 一
旦索引请求成功返回给用户，文档在主分片和副本分片都是可用的。

更新流程

1.客户端向 Node 1 发送更新请求。
2. 它将请求转发到主分片所在的 Node 3 。
3. Node 3 从主分片检索文档，修改 _source 字段中的 JSON ，并且尝试重新索引主分片
的文档。如果文档已经被另一个进程修改，它会重试步骤 3 ，超过 retry_on_conflict 次
后放弃。
4. 如果 Node 3 成功地更新文档，它将新版本的文档并行转发到 Node 1 和 Node 2 上的
副本分片，重新建立索引。一旦所有副本分片都返回成功， Node 3 向协调节点也返回
成功，协调节点向客户端返回成功。

倒排索引

Elasticsearch 使用一种称为倒排索引的结构，它适用于快速的全文搜索。
见其名，知其意，有倒排索引，肯定会对应有正向索引。正向索引（forward index），
反向索引（inverted index）更熟悉的名字是倒排索引。
所谓的正向索引，就是搜索引擎会将待搜索的文件都对应一个文件 ID，搜索时将这个
ID 和搜索关键字进行对应，形成 K-V 对，然后对关键字进行统计计数

但是互联网上收录在搜索引擎中的文档的数目是个天文数字，这样的索引结构根本无法满足
实时返回排名结果的要求。所以，搜索引擎会将正向索引重新构建为倒排索引，即把文件
ID对应到关键词的映射转换为关键词到文件ID的映射，每个关键词都对应着一系列的文件，
这些文件中都出现这个关键词

文档搜索

早期的全文检索会为整个文档集合建立一个很大的倒排索引并将其写入到磁盘。 一旦
新的索引就绪，旧的就会被其替换，这样最近的变化便可以被检索到。
倒排索引被写入磁盘后是 不可改变 的:它永远不会修改。
不变性有重要的价值：

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

当然，一个不变的索引也有不好的地方。主要事实是它是不可变的! 你不能修改它。如
果你需要让一个新的文档 可被搜索，你需要重建整个索引。这要么对一个索引所能包含的
数据量造成了很大的限制，要么对索引可被更新的频率造成了很大的限制。

动态更新索引

如何在保留不变性的前提下实现倒排索引的更新？
答案是: 用更多的索引。通过增加新的补充索引来反映新近的修改，而不是直接重写整个倒排索引。每一个倒排索引都会被轮流查询到，从最早的开始查询完后再对结果进行合并。
Elasticsearch 基于 Lucene, 这个 java 库引入了按段搜索的概念。 每一段本身都是一个倒排索引， 但索引在 Lucene 中除表示所有段的集合外，还增加了提交点的概念————
一个列出了所有已知段的文件按段搜索会以如下流程执行：

1. 新文档被收集到内存索引缓存
   

2. 不时地, 缓存被 提交
   (1) 一个新的段—一个追加的倒排索引—被写入磁盘。
   (2) 一个新的包含新段名字的 提交点 被写入磁盘
   (3) 磁盘进行 同步 — 所有在文件系统缓存中等待的写入都刷新到磁盘，以确保它们被写入物理文件

3. 新的段被开启，让它包含的文档可见以被搜索

4. 内存缓存被清空，等待接收新的文档
   

当一个查询被触发，所有已知的段按顺序被查询。词项统计会对所有段的结果进行聚合，以
保证每个词和每个文档的关联都被准确计算。 这种方式可以用相对较低的成本将新文档添
加到索引。
段是不可改变的，所以既不能从把文档从旧的段中移除，也不能修改旧的段来进行反映文档
的更新。 取而代之的是，每个提交点会包含一个 .del 文件，文件中会列出这些被删除文档
的段信息。
当一个文档被 “删除” 时，它实际上只是在 .del 文件中被 标记 删除。一个被标记删除的文档仍然可以被查询匹配到， 但它会在最终结果被返回前从结果集中移除。
文档更新也是类似的操作方式：当一个文档被更新时，旧版本文档被标记删除，文档的新版
本被索引到一个新的段中。 可能两个版本的文档都会被一个查询匹配到，但被删除的那个
旧版本文档在结果集返回前就已经被移除。
除了有段的概念还有合并的概念，当倒排索引合并的时候，会把标记删除的文件真正的删除掉。

磁盘写入流程

在创建索引index时，会在内存创建一个索引缓存，这个索引缓存包含段segment和一个translog的类似日志文件。此时文档的新增，修改都会在缓存中进行，存入到段中，然后在写入到logs文件。
(translog文件保证了缓存再写入磁盘之前如果服务宕机，可以通过该文件恢复。)
此时新的文档还不能被搜索，通过refresh写入都操作系统的缓冲区，此时相当于开启了Segment，文档可以被搜索，通过flush写入到磁盘。
refresh
在 Elasticsearch 中，写入和打开一个新段的轻量的过程叫做 refresh 。 默认情况下每个分片会每秒自动刷新一次。这就是为什么我们说 Elasticsearch 是 近 实时搜索: 文档的变化并不是立即对搜索可见，但会在一秒之内变为可见。在索引了一个文档然后尝试搜索它，但却没有搜到。这个问题的解决办法是用 refresh API 执行一次手动刷新:/users/_refresh。

并不是所有的情况都需要每秒刷新。可能你正在使用 Elasticsearch 索引大量的日志文件，你可能想优化索引速度而不是近实时搜索， 可以通过设置 refresh_interval ， 降低每个索引的刷新频率。

{
 "settings": {
 "refresh_interval": "30s" 
 }
}

在生产环境中，当你正在建立一个大的新索引时，可以先关闭自动刷新，待开始使用该索引时，再把它们调回来

关闭自动刷新
PUT /users/_settings
{ "refresh_interval": -1 } 
每一秒刷新
PUT /users/_settings
{ "refresh_interval": "1s" }

translog和flush
translog 提供所有还没有被刷到磁盘的操作的一个持久化纪录。当 Elasticsearch 启动的时候， 它会从磁盘中使用最后一个提交点去恢复已知的段，并且会重放 translog 中所有在最后一次提交后发生的变更操作。
translog 也被用来提供实时 CRUD 。当你试着通过 ID 查询、更新、删除一个文档，它会在尝试从相应的段中检索之前， 首先检查 translog 任何最近的变更。这意味着它总是能够实时地获取到文档的最新版本。
执行一个提交并且截断 translog 的行为在 Elasticsearch 被称作一次 flush，分片每 30 分钟被自动刷新（flush），或者在 translog 太大的时候也会刷新；通常情况下，自动刷新就足够了。这就是说，在重启节点或关闭索引之前执行 flush 有益于你的索引。当 Elasticsearch 尝试恢复或重新打开一个索引， 它需要重放 translog 中所有的操作，所以如果日志越短，恢复越快。translog 的目的是保证操作不会丢失，在文件被 fsync 到磁盘前，被写入的文件在重启之后就会丢失。默认 translog 是每 5 秒被 fsync 刷新到硬盘， 或者在每次写请求完成之后执行(e.g. index, delete, update, bulk)。这个过程在主分片和复制分片都会发生。
段合并
由于自动刷新流程每秒会创建一个新的段 ，这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。 每一个段都会消耗文件句柄、内存和 cpu 运行周期。更重要的是，每个搜索请求都必须轮流检查每个段；所以段越多，搜索也就越慢。
Elasticsearch 通过在后台进行段合并来解决这个问题。小的段被合并到大的段，然后这些大
的段再被合并到更大的段。
段合并的时候会将那些旧的已删除文档从文件系统中清除。被删除的文档（或被更新文档的
旧版本）不会被拷贝到新的大段中。启动段合并不需要你做任何事。进行索引和搜索时会自动进行。

插件

IK分词器

ES 的默认分词器无法识别中文中测试、单词这样的词汇，而是简单的将每个字拆完分为一个词，这样的结果显然不符合我们的使用要求，所以我们需要下载 ES 对应版本的中文分词器。
我们这里采用 IK 中文分词器，下载地址为:
https://github.com/medcl/elasticsearch-analysis-ik/releases/tag/v7.8.0
将解压后的后的文件夹放入 ES 根目录下的 plugins 目录下，重启 ES 即可使用。
在Linux中安装Ik分词器
在es的plugins目录中创建ik文件夹mkdir ik
把下载好的ik压缩包elasticsearch-analysis-ik-7.8.0.zip解压到ik文件夹中unzip elasticsearch-analysis-ik-7.8.0.zip
重启es即可。出现

完成安装。

ik_max_word：会将文本做最细粒度的拆分
ik_smart：会将文本做最粗粒度的拆分
如果碰到一些专有名词，ik分词器会将该名词分词，但是我们需要将该名词作为一个整体，所以我们需要扩展Ik分词器的词汇，首先进入 ES 根目录中的 plugins 文件夹下的 ik 文件夹，进入 config 目录，创建 custom.dic文件，写入指定词汇。同时打开 IKAnalyzer.cfg.xml 文件，将新建的 custom.dic 配置其中，重启 ES 服务器。


说明添加成功

Kibana

Kibana 是一个免费且开放的用户界面，能够让你对 Elasticsearch 数据进行可视化，并
让你在 Elastic Stack 中进行导航。你可以进行各种操作，从跟踪查询负载，到理解请求如
何流经你的整个应用，都能轻松完成。
下载地址：https://www.elastic.co/cn/downloads/kibana

找到对应版本下载，上传到服务器
解压：tar -zxvf kibana-7.8.0-linux-x86_64.tar.gz
编辑配置文件 vim config/kibana.yml

# 默认端口
server.port: 5601
#kibana访问ip
server.host: "192.168.3.120" 
# ES 服务器的地址
elasticsearch.hosts: ["http://192.168.3.118:9200"]
# 索引名
kibana.index: ".kibana"
# 支持中文
i18n.locale: "zh-CN"

kibana不支持root用户启动，切换成其他用户，如果要用root用户启动通过下面命令

启动成功

优化

硬件选择

Elasticsearch 的基础是 Lucene，所有的索引和文档数据是存储在本地的磁盘中，具体的
路径可在 ES 的配置文件…/config/elasticsearch.yml 中配置，如下：

#----------------------------------- Paths
#
# Path to directory where to store the data (separate multiple locations by comma):
#
#path.data: /path/to/data
#
# Path to log files:
#
#path.logs: /path/to/logs

磁盘在现代服务器上通常都是瓶颈。Elasticsearch 重度使用磁盘，你的磁盘能处理的吞吐量
越大，你的节点就越稳定。这里有一些优化磁盘 I/O 的技巧：

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

分片策略

合理设置分片数
分片和副本的设计为 ES 提供了支持分布式和故障转移的特性，但并不意味着分片和副本是可以无限分配的。而且索引的分片完成分配后由于索引的路由机制，我们是不能重新修改分片数的。
关于分片需要了解：

• 一个分片的底层即为一个 Lucene 索引，会消耗一定文件句柄、内存、以及 CPU 运转。
• 每一个搜索请求都需要命中索引中的每一个分片，如果每一个分片都处于不同的节点还好， 但如果多个分片都需要在同一个节点上竞争使用相同的资源就有些糟糕了。
• 用于计算相关度的词项统计信息是基于分片的。如果有许多分片，每一个都只有很少的数据会导致很低的相关度

一个业务索引具体需要分配多少分片可能需要架构师和技术人员对业务的增长有个预先的判断，横向扩展应当分阶段进行。为下一阶段准备好足够的资源。 只有当你进入到下一个阶段，你才有时间思考需要作出哪些改变来达到这个阶段。一般来说，我们遵循一些原则：

• 控制每个分片占用的硬盘容量不超过 ES 的最大 JVM 的堆空间设置（一般设置不超过 32G，参考下文的 JVM 设置原则），因此，如果索引的总容量在 500G 左右，那分片大小在 16 个左右即可；当然，最好同时考虑原则 2。
• 考虑一下 node 数量，一般一个节点有时候就是一台物理机，如果分片数过多，大大超过了节点数，很可能会导致一个节点上存在多个分片，一旦该节点故障，即使保持了 1 个以上的副本，同样有可能会导致数据丢失，集群无法恢复。所以， 一般都设置分片数不超过节点数的 3 倍。
• 主分片，副本和节点最大数之间数量，我们分配的时候可以参考以下关系：
  节点数<=主分片数*（副本数+1）

推迟分片分配
对于节点瞬时中断的问题，默认情况，集群会等待一分钟来查看节点是否会重新加入，如果这个节点在此期间重新加入，重新加入的节点会保持其现有的分片数据，不会触发新的分片分配。这样就可以减少 ES 在自动再平衡可用分片时所带来的极大开销。
通过修改参数 delayed_timeout ，可以延长再均衡的时间，可以全局设置也可以在索引级别进行修改

PUT /_all/_settings 
{
 "settings": {
 "index.unassigned.node_left.delayed_timeout": "5m" 
 } }

写入速度优化

ES 的默认配置，是综合了数据可靠性、写入速度、搜索实时性等因素。实际使用时，我们需要根据公司要求，进行偏向性的优化。针对于搜索性能要求不高，但是对写入要求较高的场景，我们需要尽可能的选择恰当写优化策略。综合来说，可以考虑以下几个方面来提升写索引的性能：

• 加大 Translog Flush ，目的是降低 Iops、Writeblock。  增加 Index Refresh 间隔，目的是减少Segment Merge 的次数。
• 调整 Bulk 线程池和队列。
• 优化节点间的任务分布。
• 优化 Lucene 层的索引建立，目的是降低 CPU 及 IO。

批量数据提交
ES 提供了 Bulk API 支持批量操作，当我们有大量的写任务时，可以使用 Bulk 来进行批量写入。通用的策略如下：Bulk 默认设置批量提交的数据量不能超过 100M。数据条数一般是根据文档的大小和服务器性能而定的，但是单次批处理的数据大小应从 5MB～15MB 逐渐增加，当性能没有提升时，把这个数据量作为最大值。
优化存储设备
ES 是一种密集使用磁盘的应用，在段合并的时候会频繁操作磁盘，所以对磁盘要求较高，当磁盘速度提升之后，集群的整体性能会大幅度提高。
合理使用合并
Lucene 以段的形式存储数据。当有新的数据写入索引时，Lucene 就会自动创建一个新的段。
随着数据量的变化，段的数量会越来越多，消耗的多文件句柄数及 CPU 就越多，查询效率就会下降。
由于 Lucene 段合并的计算量庞大，会消耗大量的 I/O，所以 ES 默认采用较保守的策略，让后台定期进行段合并
减少 Refresh 的次数
Lucene 在新增数据时，采用了延迟写入的策略，默认情况下索引的 refresh_interval 为1 秒。Lucene 将待写入的数据先写到内存中，超过 1 秒（默认）时就会触发一次 Refresh，然后 Refresh 会把内存中的的数据刷新到操作系统的文件缓存系统中。如果我们对搜索的实效性要求不高，可以将 Refresh 周期延长，例如 30 秒。这样还可以有效地减少段刷新次数，但这同时意味着需要消耗更多的 Heap 内存。
加大 Flush 设置
Flush 的主要目的是把文件缓存系统中的段持久化到硬盘，当 Translog 的数据量达到512MB 或者 30 分钟时，会触发一次 Flush。
index.translog.flush_threshold_size 参数的默认值是 512MB，我们进行修改。增加参数值意味着文件缓存系统中可能需要存储更多的数据，所以我们需要为操作系统的文件缓存系统留下足够的空间。
减少副本的数量
ES 为了保证集群的可用性，提供了 Replicas（副本）支持，然而每个副本也会执行分析、索引及可能的合并过程，所以 Replicas 的数量会严重影响写索引的效率。
当写索引时，需要把写入的数据都同步到副本节点，副本节点越多，写索引的效率就越慢。
如果我们需要大批量进行写入操作,可以先禁止Replica复制，设置index.number_of_replicas:0关闭副本。在写入完成后，Replica 修改回正常的状态。

内存设置

ES 默认安装后设置的内存是 1GB，对于任何一个现实业务来说，这个设置都太小了。 ES 安装文件中包含一个 jvm.option 文件，修改如下命令来设置 ES 的堆大小，Xms 表示堆的初始大小，Xmx 表示可分配的最大内存，都是 1GB。确保 Xmx 和 Xms 的大小是相同的，其目的是为了能够在 Java 垃圾回收机制清理完堆区后不需要重新分隔计算堆区的大小而浪费资源，可以减轻伸缩堆大小带来的压力。
假设你有一个 64G 内存的机器，按照正常思维思考，你可能会认为把 64G 内存都给ES 比较好，但现实是这样吗， 越大越好？虽然内存对 ES 来说是非常重要的，但是答案是否定的！
因为 ES 堆内存的分配需要满足以下两个原则：

• 不要超过物理内存的 50%：Lucene 的设计目的是把底层 OS 里的数据缓存到内存中。Lucene 的段是分别存储到单个文件中的，这些文件都是不会变化的，所以很利于缓存，同时操作系统也会把这些段文件缓存起来，以便更快的访问。
  如果我们设置的堆内存过大，Lucene 可用的内存将会减少，就会严重影响降低 Lucene 的全文本查询性能。
• 堆内存的大小最好不要超过 32GB：在 Java 中，所有对象都分配在堆上，然后有一个 Klass Pointer 指
  针指向它的类元数据。这个指针在 64 位的操作系统上为 64 位，64 位的操作系统可以使用更多的内存（2^64）。在 32 位的系统上为 32 位32 位的操作系统的最大寻址空间为 4GB
  （2^32）。
  但是 64 位的指针意味着更大的浪费，因为你的指针本身大了。浪费内存不算，更糟糕的是，更大的指针在主内存和缓存器（例如 LLC, L1 等）之间移动数据的时候，会占用更多的带宽。最终我们都会采用 31 G 设置
  -Xms 31g
  -Xmx 31g
  假设你有个机器有 128 GB 的内存，你可以创建两个节点，每个节点内存分配不超过 32 GB。 也就是说不超过 64 GB 内存给 ES 的堆内存，剩下的超过 64 GB 的内存给 Lucene

重要配置

参数名	参数值	说明
cluster.name	elasticsearch	配置 ES 的集群名称，默认值是 ES，建议改成与所存数据相关的名称，ES 会自动发现在同一网段下的集群名称相同的节点
node.name	node-1	集群中的节点名，在同一个集群中不能重复。节点的名称一旦设置，就不能再改变了。当然，也可以设置成服务器的主机名称，例 如node.name:${HOSTNAME}。
node.master	true	指定该节点是否有资格被选举成为 Master 节点，默认是 True，如果被设置为 True，则只是有资格成为Master 节点，具体能否成为 Master 节点，需要通过选举产生
node.data	true	指定该节点是否存储索引数据，默认为 True。数据的增、删、改、查都是在 Data 节点完成的。
index.number_of_shards	1	设置索引分片个数，默认是 1 片。也可以在创建索引时设置该值，具体设置为多大都值要根据数据量的大小来定。如果数据量不大，则设置成 1 时效率最高
index.number_of_replicas	1	设置默认的索引副本个数，默认为 1 个。副本数越多，集群的可用性越好，但是写索引时需要同步的数据越多。
transport.tcp.compress	false	设置在节点间传输数据时是否压缩，默认为 False，不压缩
discovery.zen.minimum_master_nodes	1	设置在选举 Master 节点时需要参与的最少的候选主节点数，默认为 1。如果使用默认值，则当网络不稳定时有可能会出现脑裂。合理的数值为 (master_eligible_nodes/2)+1 ，其master_eligible_nodes 表示集群中的候选主节点数
discovery.zen.ping.timeout	3s	设置在集群中自动发现其他节点时 Ping 连接的超时时间，默认为 3 秒。在较差的网络环境下需要设置得大一点，防止因误判该节点的存活状态而导致分片的转移

spingboot 整合es和APi使用

spingboot 整合es