ElasticSearch搜索引擎详解-持续更新中

1. ElasticSearch概述

1.1 elasticsearch是什么

官网地址：https://www.elastic.co/cn/elasticsearch/
废话不多说了，官网是这样定义的
Elasticsearch 是 Elastic Stack的核心，是一个分布式，RESTful风格的数据存储，搜索和分析引擎，能够帮助您发现意料之中以及意料之外的情况。

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

1.2 全文搜索引擎

对于这些非结构化的数据文本，关系型数据库搜索不是能很好的支持。
一般传统数据库，对于非结构化数据存储，查询效率很低，维护扩展麻烦，对于 insert 和 update，delete 操作都会重新构建索引。
为了解决结构化数据搜索和非结构化数据搜索性能问题，我们就需要专业，健壮，强大的全文搜索引擎。
这里说到的全文搜索引擎指的是目前广泛应用的主流搜索引擎。它的工作原理是计算机索引程序通过扫描文章中的每一个词，对每一个词建立一个索引，指明该词在文章中出现的次数和位置，当用户查询时，检索程序就根据事先建立的索引进行查找，并将查找的结果反馈给用户的检索方式。这个过程类似于通过字典中的检索字表查字的过程。

1.3 elasticsearch and solr

Lucene 是 Apache 软件基金会 Jakarta 项目组的一个子项目，提供了一个简单却强大的应用程式接口，能够做全文索引和搜寻。在 Java 开发环境里 Lucene 是一个成熟的免费开源工具。就其本身而言， Lucene 是当前以及最近几年最受欢迎的免费 Java 信息检索程序库。但 Lucene 只是一个提供全文搜索功能类库的核心工具包，而真正使用它还需要一个完善的服务框架搭建起来进行应用。

目前市面上流行的搜索引擎软件，主流的就两款： Elasticsearch 和 Solr,这两款都是基于Lucene 搭建的，可以独立部署启动的搜索引擎服务软件。由于内核相同，所以两者除了服务器安装、部署、管理、集群以外，对于数据的操作 修改、添加、保存、查询等等都十分类似。

在使用过程中，一般都会将 Elasticsearch 和 Solr 这两个软件对比，然后进行选型。这两个搜索引擎都是流行的，先进的的开源搜索引擎。它们都是围绕核心底层搜索库 - Lucene构建的 - 但它们又是不同的。像所有东西一样，每个都有其优点和缺点。

1.4 elasticsearch or solr

所有的技术选型都必须结合业务场景，否则都没有意义。

Elasticsearch 和 Solr 都是开源搜索引擎，那么我们在使用时该如何选择呢？

1.  Google 搜索趋势结果表明，与 Solr 相比， Elasticsearch 具有很大的吸引力，但这并不意味着 Apache Solr 已经死亡。虽然有些人可能不这么认为，但 Solr 仍然是最受欢迎的搜索引擎之一，拥有强大的社区和开源支持。
2. 与 Solr 相比， Elasticsearch 易于安装且非常轻巧。此外，你可以在几分钟内安装并运行Elasticsearch。但是，如果 Elasticsearch 管理不当，这种易于部署和使用可能会成为一个问题。基于 JSON 的配置很简单，但如果要为文件中的每个配置指定注释，那么它不适合您。总的来说，如果你的应用使用的是 JSON，那么 Elasticsearch 是一个更好的选择。否则，请使用 Solr，因为它的 schema.xml 和 solrconfig.xml 都有很好的文档记录。
3. Solr 拥有更大，更成熟的用户，开发者和贡献者社区。 ES 虽拥有的规模较小但活跃的用户社区以及不断增长的贡献者社区。Solr 贡献者和提交者来自许多不同的组织，而 Elasticsearch 提交者来自单个公司。
4. Solr 更成熟，但 ES 增长迅速，更稳定。
5. Solr 是一个非常有据可查的产品，具有清晰的示例和 API 用例场景。 Elasticsearch 的文档组织良好，但它缺乏好的示例和清晰的配置说明。

那么，到底是 Solr 还是 Elasticsearch？
有时很难找到明确的答案。无论您选择 Solr 还是 Elasticsearch，首先需要了解正确的用例和未来需求。总结他们的每个属性。
 由于易于使用， Elasticsearch 在新开发者中更受欢迎。一个下载和一个命令就可以启动一切。
 如果除了搜索文本之外还需要它来处理分析查询， Elasticsearch 是更好的选择
 如果需要分布式索引，则需选择 Elasticsearch。对于需要良好可伸缩性和以及性能分布式环境，Elasticsearch 是更好的选择。
 Elasticsearch 在开源日志管理用例中占据主导地位，许多组织在 Elasticsearch 中索引它们的日志以使其可搜索。
 如果你喜欢监控和指标，那么请使用 Elasticsearch，因为相对于 Solr， Elasticsearch 暴露了更多的关键指

1.5 elasticsearch应用案例

1. GitHub: 2013 年初，抛弃了 Solr，采取 Elasticsearch 来做 PB 级的搜索。 “GitHub 使用Elasticsearch 搜索 20TB 的数据，包括 13 亿文件和 1300 亿行代码”。
2.  维基百科：启动以 Elasticsearch 为基础的核心搜索架构
3.  SoundCloud： “SoundCloud 使用 Elasticsearch 为 1.8 亿用户提供即时而精准的音乐搜索服务”。
4. 百度：目前广泛使用 Elasticsearch 作为文本数据分析，采集百度所有服务器上的各类指标数据及用户自定义数据，通过对各种数据进行多维分析展示，辅助定位分析实例异常或业务层面异常。目前覆盖百度内部 20 多个业务线（包括云分析、网盟、预测、文库、直达号、钱包、 风控等），单集群最大 100 台机器， 200 个 ES 节点，每天导入 30TB+数据。
5. 新浪：使用 Elasticsearch 分析处理 32 亿条实时日志。
6. 阿里：使用 Elasticsearch 构建日志采集和分析体系。
7. Stack Overflow：解决 Bug 问题的网站，全英文，编程人员交流的网站

2. ElasticSearch入门

2.1 ElasticSearch安装

2.1.1 官网下载

Elasticsearch 的官方地址： https://www.elastic.co/cn/
Elasticsearch 最新的版本是 7.11.2（截止 2021.3.10），我们选择 7.8.0 版本（最新版本半
年前的版本）
下载地址： https://www.elastic.co/cn/downloads/past-releases#elasticsearch
Elasticsearch 分为 Linux 和 Windows 版本，基于我们主要学习的是 Elasticsearch 的 Java
客户端的使用，所以课程中使用的是安装较为简便的 Windows 版本。

2.1.2 安装

Windows 版的 Elasticsearch 的安装很简单，解压即安装完毕，解压后的 Elasticsearch 的
目录结构如下
解压后，进入 bin 文件目录，点击 elasticsearch.bat 文件启动 ES 服务。
注意： 9300 端口为 Elasticsearch 集群间组件的通信端口， 9200 端口为浏览器访问的 http
协议 RESTful 端口。
打开浏览器（推荐使用谷歌浏览器），输入地址： http://localhost:9200，测试结果

使用Chrome插件更直观一些。

2.1.3 解决问题

1. Elasticsearch 是使用 java 开发的，且 7.8 版本的 ES 需要 JDK 版本 1.8 以上，默认安装包带有 jdk 环境，如果系统配置 JAVA_HOME，那么使用系统默认的 JDK，如果没有配置使用自带的 JDK，一般建议使用系统配置的 JDK。
2. 双击启动窗口闪退，通过路径访问追踪错误，如果是“空间不足”，请修改config/jvm.options 配置文件。

# 设置 JVM 初始内存为 1G。此值可以设置与-Xmx 相同，以避免每次垃圾回收完成后 JVM 重新分配内存
# Xms represents the initial size of total heap space
# 设置 JVM 最大可用内存为 1G
# Xmx represents the maximum size of total heap space
-Xms1g
-Xmx1g

2.2 Elasticsearch基本操作

2.2.1 RESTful风格

比较装X的说法，REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。 Web 应用程序最重要的 REST 原则是，客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启，客户端不会得到通知。此外，无状态请求可以由任何可用服务器回答，这十分适合云计算之类的环境。客户端可以缓存数据以改进性能。
RESTful就是一种架构设计约束，现实使用中就是http请求，但是同样是/user请求，请求方式不一样，所代表的含义也不一样，post请求是修改，get请求是获取，delete请求是删除，put请求是新增。

2.2.2 postman客户端

这是一款接口调用工具，非常强大方便，简单易用。
Postman 官网： https://www.getpostman.com
Postman 下载： https://www.getpostman.com/apps

不知道我为什么介绍Restful与postman。没什么，就是es支持RESTful，postman工具就是后边测试要用，因为不是本文所讲的重点，具体细节就不展开了，如有需要，自行百度。

2.2.3 数据格式

ElasticSearch是面向文档型的数据库，一条数据就是一个文档。为了方便大家理解，这里将elasticsearch里存储文档数据和关系型数据库MySQL存储数据的概念进行一个类比。
ES 里的 Index 可以看做一个库，而 Types 相当于表， Documents 则相当于表的行。
这里 Types 的概念已经被逐渐弱化， Elasticsearch 6.X 中，一个 index 下已经只能包含一个
type， Elasticsearch 7.X 中, Type 的概念已经被删除了。

2.2.4 基本操作

2.2.4.1 索引操作

基本操作既可以通过postman接口调用，也可以通过Chrome插件elasticsearch-head，插件可视化操作更直观。

1. 创建索引
   对比关系型数据库，创建索引就等同于创建数据库
   在 Postman 中，向 ES 服务器发 PUT 请求 ： http://127.0.0.1:9200/shopping
   如果重复添加索引，会返回错误信息。
   
2. 查看所有索引
   在 Postman 中，向 ES 服务器发 GET 请求 ： http://127.0.0.1:9200/_cat/indices?v
   这里请求路径中的_cat 表示查看的意思， indices 表示索引，所以整体含义就是查看当前 ES服务器中的所有索引，就好像 MySQL 中的 show tables 的感觉，服务器响应结果如下。
   

2.2.4.2 文档操作

1. 创建文档
   索引已经创建好了，接下来我们来创建文档，并添加数据。这里的文档可以类比为关系型数据库中的表数据，添加的数据格式为 JSON 格式。
   在 Postman 中，向 ES 服务器发 POST 请求 ： http://127.0.0.1:9200/shopping/_doc
   请求体内容为：

{
	"title":"小米手机",
	"category":"小米",
	"images":"http://www.gulixueyuan.com/xm.jpg",
	"price":3999.00
}

此处发送请求的方式必须为 POST，不能是 PUT，否则会发生错误.
服务器响应结果
上面的数据创建后，由于没有指定数据唯一性标识（ID），默认情况下， ES 服务器会随机
生成一个。
如果想要自定义唯一性标识，需要在创建时指定： http://127.0.0.1:9200/shopping/_doc/1

2. 查看文档
   查看文档时，需要指明文档的唯一性标识，类似于 MySQL 中数据的主键查询
   在 Postman 中，向 ES 服务器发 GET 请求 ： http://127.0.0.1:9200/shopping/_doc/1
   
3. 修改文档
   向 ES 服务器发 POST 请求 ： http://127.0.0.1:9200/shopping/_doc/1

{
"title":"华为手机",
"category":"华为",
"images":"http://www.gulixueyuan.com/hw.jpg",
"price":4999.00
}

4. 修改字段
   修改数据时，也可以只修改某一给条数据的局部信息
   在 Postman 中，向 ES 服务器发 POST 请求 ： http://127.0.0.1:9200/shopping/_update/1

{
	"doc": {
		"price":3000.00
	}
}

6. 删除文档
   删除一个文档不会立即从磁盘上移除，它只是被标记成已删除（逻辑删除）。
   在 Postman 中，向 ES 服务器发 DELETE 请求 ： http://127.0.0.1:9200/shopping/_doc/1

2.2.4.3 映射操作

有了索引库，等于有了数据库中的 database。
接下来就需要建索引库(index)中的映射了，类似于数据库(database)中的表结构(table)。
创建数据库表需要设置字段名称，类型，长度，约束等；索引库也一样，需要知道这个类型
下有哪些字段，每个字段有哪些约束信息，这就叫做映射(mapping)。

1. 创建映射
   在 Postman 中，向 ES 服务器发 PUT 请求 ： http://127.0.0.1:9200/student/_mapping
   请求内容

{
    "properties": {
        "name": {
            "type": "text",
            "index": true
        },
        "sex": {
            "type": "text",
            "index": false
        },
        "age": {
            "type": "long",
            "index": false
        }
    }
}

映射数据说明：
字段名：任意填写，下面指定许多属性，例如： title、 subtitle、 images、 price

type：类型， Elasticsearch 中支持的数据类型非常丰富，说几个关键的：
	String 类型，又分两种：
     	text：可分词
		keyword：不可分词，数据会作为完整字段进行匹配
		
	 Numerical：数值类型，分两类
		基本数据类型： long、 integer、 short、 byte、 double、 float、 half_float
		浮点数的高精度类型： scaled_float
		
	Date：日期类型
	Array：数组类型
	Object：对象
	index：是否索引，默认为 true，也就是说你不进行任何配置，所有字段都会被索引。
	true：字段会被索引，则可以用来进行搜索
	false：字段不会被索引，不能用来搜索
	store：是否将数据进行独立存储，默认为 false
	原始的文本会存储在_source 里面，默认情况下其他提取出来的字段都不是独立存储的，是从_source 里面提取出来的。当然你也可以独立的存储某个字段，只要设置"store": true 即可，获取独立存储的字段要比从_source 中解析快得多，但是也会占用更多的空间，所以要根据实际业务需求来设置。
    analyzer：分词器，这里的 ik_max_word 即使用 ik 分词器,后面会有专门的章节学习

2. 查看映射
   在 Postman 中，向 ES 服务器发 GET 请求 ： http://127.0.0.1:9200/student/_mapping

2.2.4.4 高级查询

Elasticsearch 提供了基于 JSON 提供完整的查询 DSL 来定义查询
定义数据 :

# POST /student/_doc/1001
{
"name":"zhangsan",
"nickname":"zhangsan",
"sex":"男",
"age":30
}
# POST /student/_doc/1002
{
"name":"lisi",
"nickname":"lisi",
"sex":"男",
"age":20
}
# POST /student/_doc/1003
{
"name":"wangwu",
"nickname":"wangwu",
"sex":"女",
"age":40
}
# POST /student/_doc/1004
{
"name":"zhangsan1",
"nickname":"zhangsan1",
"sex":"女",
"age":50
}
# POST /student/_doc/1005
{
"name":"zhangsan2",
"nickname":"zhangsan2",
"sex":"女",
"age":30
}

1. 查询所有文档
   在 Postman 中，向 ES 服务器发 GET 请求 ： http://127.0.0.1:9200/student/_search

2. 匹配查询
   在 Postman 中，向 ES 服务器发 GET 请求 ： http://127.0.0.1:9200/student/_search

3. 字段匹配查询
   在 Postman 中，向 ES 服务器发 GET 请求 ： http://127.0.0.1:9200/student/_search

4. 关键字精确查询
   在 Postman 中，向 ES 服务器发 GET 请求 ： http://127.0.0.1:9200/student/_search

5. 多关键字精确查询
   在 Postman 中，向 ES 服务器发 GET 请求 ： http://127.0.0.1:9200/student/_search

由于操作太多就不一一列举，详见es操作手册。
指定字段，过滤字段，组合查询，范围查询，模糊查询，单字段排序，多字段排序，高亮查询，分页查询，聚合查询，桶聚合查询等

2.2.5 API操作

Elasticsearch 软件是由 Java 语言开发的，所以也可以通过 Java API 的方式对 Elasticsearch服务进行访问。

我们在 IDEA 开发工具中创建 Maven 项目(模块也可)ES,这与客户端postman调用一样效果，且平常开发中很少通过API的方式实现操作es，大部分是通过集成springdata方式实现的，所以api相关了解即可，代码详见git。

GitHub地址：https://github.com/zrj-coder/es

2.2.5.1 创建maven项目

引入依赖

        
        <dependency>
            <groupId>org.elasticsearchgroupId>
            <artifactId>elasticsearchartifactId>
            <version>7.8.0version>
        dependency>
        
        <dependency>
            <groupId>org.elasticsearch.clientgroupId>
            <artifactId>elasticsearch-rest-high-level-clientartifactId>
            <version>7.8.0version>
        dependency>
        
        <dependency>
            <groupId>org.apache.logging.log4jgroupId>
            <artifactId>log4j-apiartifactId>
            <version>2.8.2version>
        dependency>
        <dependency>
            <groupId>org.apache.logging.log4jgroupId>
            <artifactId>log4j-coreartifactId>
            <version>2.8.2version>
        dependency>
        <dependency>
            <groupId>com.fasterxml.jackson.coregroupId>
            <artifactId>jackson-databindartifactId>
            <version>2.9.9version>
        dependency>
        
        <dependency>
            <groupId>junitgroupId>
            <artifactId>junitartifactId>
            <version>4.12version>
        dependency>
    dependencies>

2.2.5.2 客户端对象

创建 com.example.es.test.Elasticsearch01_Client 类，代码中创建 Elasticsearch 客户端对象,因为早期版本的客户端对象已经不再推荐使用，且在未来版本中会被删除，所以这里我们采用高级 REST 客户端对象。

// 创建客户端对象
RestHighLevelClient client = new RestHighLevelClient(
RestClient.builder(new HttpHost("localhost", 9200, "http"))
);
...
// 关闭客户端连接
client.close();

注意： 9200 端口为 Elasticsearch 的 Web 通信端口，localhost 为启动 ES 服务的主机名。

2.2.5.3 索引操作

2.2.5.3 文档操作

2.2.5.5 高级查询

3. ElasticSearch环境

3.1 相关概念

3.1.1 单机&集群

单台 Elasticsearch 服务器提供服务，往往都有最大的负载能力，超过这个阈值，服务器性能就会大大降低甚至不可用，所以生产环境中，一般都是运行在指定服务器集群中。
除了负载能力，单点服务器也存在其他问题：
 单台机器存储容量有限
 单服务器容易出现单点故障，无法实现高可用
 单服务的并发处理能力有限
配置服务器集群时，集群中节点数量没有限制，大于等于 2 个节点就可以看做是集群了。一般出于高性能及高可用方面来考虑集群中节点数量都是 3 个以上。

3.1.2 集群Cluster

一个集群就是由一个或多个服务器节点组织在一起，共同持有整个的数据，并一起提供索引和搜索功能。一个 Elasticsearch 集群有一个唯一的名字标识，这个名字默认就是”elasticsearch”。这个名字是重要的，因为一个节点只能通过指定某个集群的名字，来加入这个集群。

3.1.3 节点Node

集群中包含很多服务器， 一个节点就是其中的一个服务器。 作为集群的一部分，它存储数据，参与集群的索引和搜索功能。

3.2 Windows集群

3.2.1 集群部署

1. 创建elasticsearch-cluster文件夹，内部复制三个elasticsearch服务。
2. 修改集群文件目录中每个节点的 config/elasticsearch.yml 配置文件。
   node-1001 节点

#节点 1 的配置信息：
#集群名称，节点之间要保持一致
cluster.name: my-elasticsearch
#节点名称，集群内要唯一
node.name: node-1001
node.master: true
node.data: true
#ip 地址
network.host: localhost
#http 端口
http.port: 1001
#tcp 监听端口
transport.tcp.port: 9301
#discovery.seed_hosts: ["localhost:9301", "localhost:9302","localhost:9303"]
#discovery.zen.fd.ping_timeout: 1m
#discovery.zen.fd.ping_retries: 5
#集群内的可以被选为主节点的节点列表
#cluster.initial_master_nodes: ["node-1", "node-2","node-3"]
#跨域配置
#action.destructive_requires_name: true
http.cors.enabled: true
http.cors.allow-origin: "*"

node-1002 节点

#节点 2 的配置信息：
#集群名称，节点之间要保持一致
cluster.name: my-elasticsearch
#节点名称，集群内要唯一
node.name: node-1002
node.master: true
node.data: true
#ip 地址
network.host: localhost
#http 端口
http.port: 1002
#tcp 监听端口
transport.tcp.port: 9302
discovery.seed_hosts: ["localhost:9301"]
discovery.zen.fd.ping_timeout: 1m
discovery.zen.fd.ping_retries: 5
#集群内的可以被选为主节点的节点列表
#cluster.initial_master_nodes: ["node-1", "node-2","node-3"]
#跨域配置
#action.destructive_requires_name: true
http.cors.enabled: true
http.cors.allow-origin: "*"

node-1003 节点

#节点 3 的配置信息：
#集群名称，节点之间要保持一致
cluster.name: my-elasticsearch
#节点名称，集群内要唯一
node.name: node-1003
node.master: true
node.data: true
#ip 地址
network.host: localhost
#http 端口
http.port: 1003
#tcp 监听端口
transport.tcp.port: 9303
#候选主节点的地址，在开启服务后可以被选为主节点
discovery.seed_hosts: ["localhost:9301", "localhost:9302"]
discovery.zen.fd.ping_timeout: 1m
discovery.zen.fd.ping_retries: 5
#集群内的可以被选为主节点的节点列表
#cluster.initial_master_nodes: ["node-1", "node-2","node-3"]
#跨域配置
#action.destructive_requires_name: true
http.cors.enabled: true
http.cors.allow-origin: "*"

3.2.2 启动集群

1. 启动前先删除每个节点中的 data 目录中所有内容（如果存在）
   
2. 分别双击执行 bin/elasticsearch.bat, 启动节点服务器，启动后，会自动加入指定名称的集群。

3.2.3 测试集群

查看集群状态

1. node-1001 节点
   

2. node-1002节点
   

3. node-1003 节点
   返回结果同节点2.

4. 字段说明
   

3.3 Linux 单机与集群

4. ElasticSearch进阶

4.1 核心概念

4.1.1 索引（Index）

一个索引就是一个具有相似特征的文档的集合。

比如说，你可以有一个客户数据的索引，另一个产品目录的索引，还有一个订单数据的索引。一个索引由一个名字来标识（必须全部是小写字母），并且当我们要对这个索引中的文档进行索引、搜索、更新和删除的时候，都要使用到这个名字。在一个集群中，可以定义任意多的索引。

能搜索的数据必须索引，这样的好处是可以提高查询速度，比如：新华字典前面的目录就是索引的意思，目录可以提高查询速度。
Elasticsearch 索引的精髓：一切设计都是为了提高搜索的性能。

4.1.2 类型（Type）

在一个索引中，你可以定义一种或多种类型。

一个类型是你的索引的一个逻辑上的分类/分区，其语义完全由你来定。通常，会为具有一组共同字段的文档定义一个类型。不同的版本，类型发生了不同的变化。

4.1.3 文档（Document）

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

在一个 index/type 里面，你可以存储任意多的文档

4.1.3 字段（Field）

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

4.1.5 映射（Mapping）

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

4.1.6 分片（Shards）

一个索引可以存储超出单个节点硬件限制的大量数据。比如，一个具有 10 亿文档数据的索引占据 1TB 的磁盘空间，而任一节点都可能没有这样大的磁盘空间。 或者单个节点处理搜索请求，响应太慢。为了解决这个问题， Elasticsearch 提供了将索引划分成多份的能力，每一份就称之为分片。当你创建一个索引的时候，你可以指定你想要的分片的数量。每个分片本身也是一个功能完善并且独立的“索引”，这个“索引”可以被放置到集群中的任何节点上。

分片很重要，主要有两方面的原因：
1）允许你水平分割 / 扩展你的内容容量。
2）允许你在分片之上进行分布式的、并行的操作，进而提高性能/吞吐量。
至于一个分片怎样分布，它的文档怎样聚合和搜索请求，是完全由 Elasticsearch 管理的，对于作为用户的你来说，这些都是透明的，无需过分关心。

被混淆的概念是，一个 Lucene 索引 我们在 Elasticsearch 称作 分片 。 一个Elasticsearch 索引 是分片的集合。 当 Elasticsearch 在索引中搜索的时候， 他发送查询到每一个属于索引的分片(Lucene 索引)，然后合并每个分片的结果到一个全局的结果集。

4.1.7 副本（Replicas）

在一个网络 / 云的环境里，失败随时都可能发生，在某个分片/节点不知怎么的就处于离线状态，或者由于任何原因消失了，这种情况下，有一个故障转移机制是非常有用并且是强烈推荐的。为此目的， Elasticsearch 允许你创建分片的一份或多份拷贝，这些拷贝叫做复制分片(副本)。

复制分片之所以重要，有两个主要原因：

1. 在分片/节点失败的情况下，提供了高可用性。因为这个原因，注意到复制分片从不与原/主要（original/primary）分片置于同一节点上是非常重要的。
2. 扩展你的搜索量/吞吐量，因为搜索可以在所有的副本上并行运行。

总之，每个索引可以被分成多个分片。一个索引也可以被复制 0 次（意思是没有复制）或多次。一旦复制了，每个索引就有了主分片（作为复制源的原来的分片）和复制分片（主分片的拷贝）之别。分片和复制的数量可以在索引创建的时候指定。在索引创建之后，你可以在任何时候动态地改变复制的数量，但是你事后不能改变分片的数量。默认情况下，Elasticsearch 中的每个索引被分片 1 个主分片和 1 个复制，这意味着，如果你的集群中至少有两个节点，你的索引将会有 1 个主分片和另外 1 个复制分片（1 个完全拷贝），这样的话每个索引总共就有 2 个分片， 我们需要根据索引需要确定分片个数。

4.1.8 分配（Allocation）

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

4.2 系统架构

一个运行中的 Elasticsearch 实例称为一个节点，而集群是由一个或者多个拥有相同cluster.name 配置的节点组成， 它们共同承担数据和负载的压力。当有节点加入集群中或者从集群中移除节点时，集群将会重新平均分布所有的数据。

当一个节点被选举成为主节点时， 它将负责管理集群范围内的所有变更，例如增加、删除索引，或者增加、删除节点等。 而主节点并不需要涉及到文档级别的变更和搜索等操作，所以当集群只拥有一个主节点的情况下，即使流量的增加它也不会成为瓶颈。 任何节点都可以成为主节点。我们的示例集群就只有一个节点，所以它同时也成为了主节点。

作为用户，我们可以将请求发送到集群中的任何节点 ，包括主节点。 每个节点都知道任意文档所处的位置，并且能够将我们的请求直接转发到存储我们所需文档的节点。 无论我们将请求发送到哪个节点，它都能负责从各个包含我们所需文档的节点收集回数据，并将最终结果返回給客户端。 Elasticsearch 对这一切的管理都是透明的。

4.3 分布式集群

详见GitHub中doc，其中包括单节点集群，故障转移，水平扩容，应对故障等功能。

4.4 路由计算

详见GitHub中doc

4.5 分片控制

详见GitHub中doc

4.6 分片原理

详见GitHub中doc

4.7 文档分析

详见GitHub中doc

4.8 文档处理

详见GitHub中doc

4.9 Kibana

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

下载地址： https://artifacts.elastic.co/downloads/kibana/kibana-7.8.0-windows-x86_64.zip

1. 解压缩下载的 zip 文件
2. 修改 config/kibana.yml 文件

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

3. Windows 环境下执行 bin/kibana.bat 文件
   
4. 通过浏览器访问 : http://localhost:5601
   控制台操作
   

5. ElasticSearch集成

5.1 Elasticsearch 集成 Spring Data

5.1.1 Spring Data 框架介绍

Spring Data 是一个用于简化数据库、非关系型数据库、索引库访问，并支持云服务的开源框架。其主要目标是使得对数据的访问变得方便快捷，并支持 map-reduce 框架和云计算数据服务。 Spring Data 可以极大的简化 JPA（Elasticsearch„）的写法，可以在几乎不用写实现的情况下，实现对数据的访问和操作。除了 CRUD 外，还包括如分页、排序等一些常用的功能。
代码实现地址：https://gitee.com/rjzhu/test/tree/dev/es-demo
Spring Data 的官网： https://spring.io/projects/spring-data
Spring Data 常用的功能模块如下：

5.1.2 Spring Data Elasticsearch 介绍

Spring Data Elasticsearch 基于 spring data API 简化 Elasticsearch 操作，将原始操作Elasticsearch 的客户端 API 进行封装 。 Spring Data 为 Elasticsearch 项目提供集成搜索引擎。Spring Data Elasticsearch POJO 的关键功能区域为中心的模型与 Elastichsearch 交互文档和轻松地编写一个存储索引库数据访问层。
官方网站: https://spring.io/projects/spring-data-elasticsearch

5.1.3 Spring Data Elasticsearch 版本对比

目前最新 springboot 对应 Elasticsearch7.6.2， Spring boot2.3.x 一般可以兼容 Elasticsearch7.x
https://docs.spring.io/spring-data/elasticsearch/docs/4.2.3/reference/html/#elasticsearch.mapping

5.1.4 框架集成

GitHub地址：https://github.com/zrj-coder/es

5.2 Spark Streaming 框架集成

5.2.1 Spark Streaming 框架介绍

Spark Streaming 是 Spark core API 的扩展，支持实时数据流的处理，并且具有可扩展，高吞吐量，容错的特点。 数据可以从许多来源获取，如 Kafka， Flume， Kinesis 或 TCP sockets，并且可以使用复杂的算法进行处理，这些算法使用诸如 map， reduce， join 和 window 等高级函数表示。 最后，处理后的数据可以推送到文件系统，数据库等。 实际上，您可以将Spark 的机器学习和图形处理算法应用于数据流。

5.3 Flink 框架集成

5.3.1 Flink 框架介绍

Apache Spark 是一种基于内存的快速、通用、可扩展的大数据分析计算引擎。
Apache Spark 掀开了内存计算的先河，以内存作为赌注，赢得了内存计算的飞速发展。但是在其火热的同时，开发人员发现，在 Spark 中，计算框架普遍存在的缺点和不足依然没有完全解决，而这些问题随着 5G 时代的来临以及决策者对实时数据分析结果的迫切需要而凸显的更加明显：
 数据精准一次性处理（Exactly-Once）
 乱序数据，迟到数据
 低延迟，高吞吐，准确性
 容错性
Apache Flink 是一个框架和分布式处理引擎，用于对无界和有界数据流进行有状态计算。在Spark 火热的同时，也默默地发展自己，并尝试着解决其他计算框架的问题。慢慢地，随着这些问题的解决， Flink慢慢被绝大数程序员所熟知并进行大力推广，阿里公司在 2015 年改进 Flink，并创建了内部分支 Blink，目前服务于阿里集团内部搜索、推荐、广告和蚂蚁等大量核心实时业务。

6. ElasticSearch优化

6.1 硬件选择

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

# 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 的技巧：

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

6.2 分片策略

6.2.1 合理设置分片数

分片和副本的设计为 ES 提供了支持分布式和故障转移的特性，但并不意味着分片和副本是可以无限分配的。而且索引的分片完成分配后由于索引的路由机制，我们是不能重新修改分片数的。可能有人会说，我不知道这个索引将来会变得多大，并且过后我也不能更改索引的大小，所以为了保险起见，还是给它设为 1000 个分片吧。但是需要知道的是，一个分片并不是没有代价的。需要了解：
 一个分片的底层即为一个 Lucene 索引，会消耗一定文件句柄、内存、以及 CPU 运转。
 每一个搜索请求都需要命中索引中的每一个分片，如果每一个分片都处于不同的节点还好， 但如果多个分片都需要在同一个节点上竞争使用相同的资源就有些糟糕了。
 用于计算相关度的词项统计信息是基于分片的。如果有许多分片，每一个都只有很少的数据会导致很低的相关度。

一个业务索引具体需要分配多少分片可能需要架构师和技术人员对业务的增长有个预先的判断，横向扩展应当分阶段进行。为下一阶段准备好足够的资源。 只有当你进入到下一个阶段，你才有时间思考需要作出哪些改变来达到这个阶段。一般来说，我们遵循一些原则：
 控制每个分片占用的硬盘容量不超过 ES 的最大 JVM 的堆空间设置（一般设置不超过 32G，参考下文的 JVM 设置原则），因此，如果索引的总容量在 500G 左右，那分片大小在 16 个左右即可；当然，最好同时考虑原则 2。
 考虑一下 node 数量，一般一个节点有时候就是一台物理机，如果分片数过多，大大超过了节点数，很可能会导致一个节点上存在多个分片，一旦该节点故障，即使保持了 1 个以上的副本，同样有可能会导致数据丢失，集群无法恢复。所以， 一般都设置分片数不超过节点数的 3 倍。
 主分片，副本和节点最大数之间数量，我们分配的时候可以参考以下关系：节点数<=主分片数*（副本数+1）

6.2.2 推迟分片分配

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

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

6.3 路由选择

当我们查询文档的时候， Elasticsearch 如何知道一个文档应该存放到哪个分片中呢？它其实是通过下面这个公式来计算出来:
shard = hash(routing) % number_of_primary_shards
routing 默认值是文档的 id，也可以采用自定义值，比如用户 id。
不带 routing 查询
在查询的时候因为不知道要查询的数据具体在哪个分片上，所以整个过程分为 2 个步骤
 分发：请求到达协调节点后，协调节点将查询请求分发到每个分片上。
 聚合: 协调节点搜集到每个分片上查询结果，在将查询的结果进行排序，之后给用户返回结果。
带 routing 查询
查询的时候，可以直接根据 routing 信息定位到某个分配查询，不需要查询所有的分配，经过协调节点排序。
向上面自定义的用户查询，如果 routing 设置为 userid 的话，就可以直接查询出数据来，效率提升很多.

6.4 写入速度优化

ES 的默认配置，是综合了数据可靠性、写入速度、搜索实时性等因素。实际使用时，我们需要根据公司要求，进行偏向性的优化。
针对于搜索性能要求不高，但是对写入要求较高的场景，我们需要尽可能的选择恰当写优化策略。综合来说，可以考虑以下几个方面来提升写索引的性能：
 加大 Translog Flush ，目的是降低 Iops、 Writeblock。
 增加 Index Refresh 间隔，目的是减少 Segment Merge 的次数。
 调整 Bulk 线程池和队列。
 优化节点间的任务分布。
 优化 Lucene 层的索引建立，目的是降低 CPU 及 IO。

6.4.1 批量数据提交

6.4.2 优化存储设备

6.4.3 合理使用合并

6.4.4 减少 Refresh 的次数

6.4.5 加大 Flush 设置

6.4.6 减少副本的数量

6.5 内存设置

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

1. 不要超过物理内存的 50%： Lucene 的设计目的是把底层 OS 里的数据缓存到内存中。Lucene 的段是分别存储到单个文件中的，这些文件都是不会变化的，所以很利于缓存，同时操作系统也会把这些段文件缓存起来，以便更快的访问。如果我们设置的堆内存过大， Lucene 可用的内存将会减少，就会严重影响降低 Lucene 的全文本查询性能。
2. 堆内存的大小最好不要超过 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.

6.6 重要配置

7. ElasticSearch总结