Elasticsearch笔记

Elasticsearch

发布时间 : 2022-12-06 20:08

字数:8.7k

Elasticsearch简介

https://my.oschina.net/happyBKs/blog/1798778

背景

随着业务复杂度的提升以及微服务的兴起，传统单一项目会被按照业务规则进行垂直拆分，另外为了防止单点故障我们也会将重要的服务模块进行集群部署，通过负载均衡进行服务的调用。那么随着节点的增多，各个服务的日志也会散落在各个服务器上。这对于我们进行日志分析带来了巨大的挑战，总不能一台一台的登录去下载日志吧。那么我们需要一种收集日志的工具将散落在各个服务器节点上的日志收集起来，进行统一的查询及管理统计。那么ELK就可以做到这一点。

Elasticsearch特性

安装方便：没有其他依赖，下载后安装非常方便；只用修改几个参数就可以搭建起来一个集群
JSON：输入/输出格式为 JSON，意味着不需要定义 Schema，快捷方便
RESTful：基本所有操作（索引、查询、甚至是配置）都可以通过 HTTP 接口进行
分布式：节点对外表现对等（每个节点都可以用来做入口）；加入节点自动均衡
多租户：可根据不同的用途分索引；可以同时操作多个索引

{
  "name" : "5i586tn", // node 名称
  "cluster_name" : "elasticsearch", // 集群名称
  "cluster_uuid" : "-Ij_g7DrQqeQRYt0BAIY2g",
  "version" : {
    "number" : "6.6.2",// es版本号
    "build_flavor" : "default",
    "build_type" : "zip",
    "build_hash" : "3bd3e59",
    "build_date" : "2019-03-06T15:16:26.864148Z",
    "build_snapshot" : false,
    "lucene_version" : "7.6.0",
    "minimum_wire_compatibility_version" : "5.6.0",
    "minimum_index_compatibility_version" : "5.0.0"
  },
  "tagline" : "You Know, for Search"
}

可以看到，我们成功的创建了一个twitter的节点，当然shard默认是5，我这里设置成了7
每一个绿色的小框框代表了一个shard，外面有黑色框框的代表主shard，没有的便是replication，横向的node对应了集群中每一个节点。至此简单的es集群就部署好了。

Elasticsearch 是一个开源的搜索引擎，建立在一个全文搜索引擎库 Apache Lucene™ 基础之上。 Lucene 可以说是当下最先进、高性能、全功能的搜索引擎库–无论是开源还是私有。

但是 Lucene 仅仅只是一个库。为了充分发挥其功能，你需要使用 Java 并将 Lucene 直接集成到应用程序中。

Elasticsearch 也是使用 Java 编写的，它的内部使用 Lucene 做索引与搜索，但是它的目的是使全文检索变得简单，通过隐藏 Lucene 的复杂性，取而代之的提供一套简单一致的 RESTful API。

然而，Elasticsearch 不仅仅是 Lucene，并且也不仅仅只是一个全文搜索引擎。它可以被下面这样准确的形容：

一个分布式的实时文档存储，每个字段可以被索引与搜索
一个分布式实时分析搜索引擎
能胜任上百个服务节点的扩展，并支持 PB 级别的结构化或者非结构化数据

Elasticsearch 将所有的功能打包成一个单独的服务，这样你可以通过程序与它提供的简单的 RESTful API 进行通信, 通过端口 9200 和 Elasticsearch 进行通信

Elasticsearch 存储结构

es中，存储数据的基本单位就是索引，比如说es中存储了一些订单系统的销售数据，就因该在es中创建一个索引，order—index，所有的销售数据就会都写到这个索引里面去，一个索引就像数据库。而type就相当于每一张表，
一个index里面可以有多个type，而mapping就相当于表的结构定义，定义了什么字段类型等，你往index的一个type里添加一行数据就叫做一个document，每一个document有多个filed，每一个filed就代表这个document的一个字段的值。

在Elasticsearch中，文档归属于一种类型(type),而这些类型存在于索引(index)中,和数据库的对比.
 shards  分片
 primary shard 主分片
 replica shard 复制分片
 document 文档必须包含的三个节点
    _index  文档存储的地方
    _type  文档代表的对象的类
    _id  文档的唯一标识

关系数据库 -> 数据库 -> 表 -> 行 -> 列
Elasticsearch -> Indices -> Types -> Documents -> Fields
索引相当于数据库，类型相当于表，文档相当于行，字段（Fields）相当于表的列（字段）。

es的几个概念：

（1）接近实时（NRT）
Elasticsearch是一个接近实时的搜索平台。这意味着，从索引一个文档直到这个文档能够被搜索到有一个轻微的延迟（通常是1秒）。

（2）集群（cluster）
一个集群就是由一个或多个节点组织在一起，它们共同持有你整个的数据，并一起提供索引和搜索功能。一个集群由一个唯一的名字标识，这个名字默认就是“elasticsearch”。这个名字是重要的，因为一个节点只能通过指定某个集群的名字，来加入这个集群。在产品环境中显式地设定这个名字是一个好习惯，但是使用默认值来进行测试/开发也是不错的。

（3）节点（node）
一个节点是你集群中的一个服务器，作为集群的一部分，它存储你的数据，参与集群的索引和搜索功能。和集群类似，一个节点也是由一个名字来标识的，默认情况下，这个名字是一个随机的漫威漫画角色的名字，这个名字会在启动的时候赋予节点。这个名字对于管理工作来说挺重要的，因为在这个管理过程中，你会去确定网络中的哪些服务器对应于Elasticsearch集群中的哪些节点。

一个节点可以通过配置集群名称的方式来加入一个指定的集群。默认情况下，每个节点都会被安排加入到一个叫做“elasticsearch”的集群中，这意味着，如果你在你的网络中启动了若干个节点，并假定它们能够相互发现彼此，它们将会自动地形成并加入到一个叫做“elasticsearch”的集群中。

在一个集群里，只要你想，可以拥有任意多个节点。而且，如果当前你的网络中没有运行任何Elasticsearch节点，这时启动一个节点，会默认创建并加入一个叫做“elasticsearch”的集群。

（4）索引（index）
一个索引就是一个拥有几分相似特征的文档的集合。比如说，你可以有一个客户数据的索引，另一个产品目录的索引，还有一个订单数据的索引。一个索引由一个名字来标识（必须全部是小写字母的），并且当我们要对对应于这个索引中的文档进行索引、搜索、更新和删除的时候，都要使用到这个名字。索引类似于关系型数据库中Database的概念。在一个集群中，如果你想，可以定义任意多的索引。

（5）类型（type）
在一个索引中，你可以定义一种或多种类型。一个类型是你的索引的一个逻辑上的分类/分区，其语义完全由你来定。通常，会为具有一组共同字段的文档定义一个类型。比如说，我们假设你运营一个博客平台并且将你所有的数据存储到一个索引中。在这个索引中，你可以为用户数据定义一个类型，为博客数据定义另一个类型，当然，也可以为评论数据定义另一个类型。类型类似于关系型数据库中Table的概念。
type 在6.0.0已经不赞成使用

（6）文档（document）
一个文档是一个可被索引的基础信息单元。比如，你可以拥有某一个客户的文档，某一个产品的一个文档，当然，也可以拥有某个订单的一个文档。文档以JSON（Javascript Object Notation）格式来表示，而JSON是一个到处存在的互联网数据交互格式。
在一个index/type里面，只要你想，你可以存储任意多的文档。注意，尽管一个文档，物理上存在于一个索引之中，文档必须被索引/赋予一个索引的type。文档类似于关系型数据库中Record的概念。实际上一个文档除了用户定义的数据外，还包括_index、_type和_id字段。

（7）分片和复制（Primary shards & Primary replicas）
一个索引可以存储超出单个结点硬件限制的大量数据。比如，一个具有10亿文档的索引占据1TB的磁盘空间，而任一节点都没有这样大的磁盘空间；或者单个节点处理搜索请求，响应太慢。

为了解决这个问题，Elasticsearch提供了将索引划分成多份的能力，这些份就叫做分片。当你创建一个索引的时候，你可以指定你想要的分片的数量。每个分片本身也是一个功能完善并且独立的“索引”，这个“索引”可以被放置到集群中的任何节点上。
分片之所以重要，主要有两方面的原因：

允许你水平分割/扩展你的内容容量
允许你在分片（潜在地，位于多个节点上）之上进行分布式的、并行的操作，进而提高性能/吞吐量，至于一个分片怎样分布，它的文档怎样聚合回搜索请求，是完全由Elasticsearch管理的，对于作为用户的你来说，这些都是透明的。

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

在分片/节点失败的情况下，提供了高可用性。因为这个原因，注意到复制分片从不与原/主要（original/primary）分片置于同一节点上是非常重要的。
扩展你的搜索量/吞吐量，因为搜索可以在所有的复制上并行运行
总之，每个索引可以被分成多个分片。一个索引也可以被复制0次（意思是没有复制）或多次。一旦复制了，每个索引就有了主分片（作为复制源的原来的分片）和复制分片（主分片的拷贝）之别。分片和复制的数量可以在索引创建的时候指定。在索引创建之后，你可以在任何时候动态地改变复制数量，但是不能改变分片的数量。

默认情况下，Elasticsearch中的每个索引被分片5个主分片和1个复制，这意味着，如果你的集群中至少有两个节点，你的索引将会有5个主分片和另外5个复制分片（1个完全拷贝），这样的话每个索引总共就有10个分片。一个索引的多个分片可以存放在集群中的一台主机上，也可以存放在多台主机上，这取决于你的集群机器数量。主分片和复制分片的具体位置是由ES内在的策略所决定的。

Mapping 映射

数据类型

https://www.cnblogs.com/shoufeng/p/10692113.html

1 核心数据类型

字符串类型 - string(不再支持), 用text或keyword类型来代替string
文本类型 - text 当一个字段需要用于全文搜索(会被分词), 比如产品名称、产品描述信息, 就应该使用text类型.
- text的内容会被分词, 可以设置是否需要存储: “index”: “true|false”.
  text类型的字段不能用于排序, 也很少用于聚合
关键字类型 - keyword 当一个字段需要按照精确值进行过滤、排序、聚合等操作时, 就应该使用keyword类型.
- keyword的内容不会被分词, 可以设置是否需要存储: “index”: “true|false”.

数字类型 - 8种

类型说明

byte 有符号的8位整数, 范围: [-128 ~ 127]

short 有符号的16位整数, 范围: [-32768 ~ 32767]

integer 有符号的32位整数, 范围: [$-2^{31}$ ~ $2^{31}$-1]

long 有符号的32位整数, 范围: [$-2^{63}$ ~ $2^{63}$-1]

float 32位单精度浮点数

double 64位双精度浮点数

half_float 16位半精度IEEE 754浮点类型

scaled_float 缩放类型的的浮点数, 比如price字段只需精确到分, 57.34缩放因子为100, 存储结果为5734

使用注意事项:

类型	说明
byte	有符号的8位整数, 范围: [-128 ~ 127]
short	有符号的16位整数, 范围: [-32768 ~ 32767]
integer	有符号的32位整数, 范围: [$-2^{31}$ ~ $2^{31}$-1]
long	有符号的32位整数, 范围: [$-2^{63}$ ~ $2^{63}$-1]
float	32位单精度浮点数
double	64位双精度浮点数
half_float	16位半精度IEEE 754浮点类型
scaled_float	缩放类型的的浮点数, 比如price字段只需精确到分, 57.34缩放因子为100, 存储结果为5734
使用注意事项:

尽可能选择范围小的数据类型, 字段的长度越短, 索引和搜索的效率越高;
优先考虑使用带缩放因子的浮点类型.

日期类型 - date
布尔类型 - boolean
二进制型 - binary

范围类型 - range

类型	范围
integer_range	$-2^{31}$ ~ $2^{31}-1$
long_range	$-2^{63}$ ~ $2^{63}-1$
float_range	32位单精度浮点型
double_range	64位双精度浮点型
date_range	64位整数, 毫秒计时
ip_range	IP值的范围, 支持IPV4和IPV6, 或者这两种同时存在

2 复杂数据类型

数组类型 - array
对象类型 - object
嵌套类型 - nested

3 地理数据类型

地理点类型 - geo point
地理形状类型 - geo_shape

4 专门数据类型

IP类型
计数数据类型 - token_count

es锁机制

悲观锁并发控制

优点：方便
缺点：并发能力低每次只有一个

乐观锁并发控制

es采用乐观锁

乐观锁不会加锁，会采用一个版本号

优点：并发能力高
缺点：每次操作都要比对版本号

倒排索引

倒排索引（Inverted Index）也叫反向索引，有反向索引必有正向索引。通俗地来讲，正向索引是通过key找value，反向索引则是通过value找key。

在创建索引之前，会对文档中的字符串进行分词。ES中字符串有两种类型，keyword和text。

keyword类型的字符串不会被分词，搜索时全匹配查询
text类型的字符串会被分词，搜索时是包含查询

如拆分“中华人民共和国国歌”

ik_max_word分词器: 最细粒度拆分，分词结果如下：
- 中华人民共和国
- 中华人民
- 中华
- 华人
- 人民共和国
- 人民
- 人
- 民
- 共和国
- 共和
- 和
- 国国
- 国歌
ik_smart分词器: 最粗粒度的拆分，分词结果如下：
- 中华人民共和国
- 国歌

可见，再ES中创建索引，选择合适的分词器是很重要的。

倒排索引— 一旦生成,不能更改
其好处如下:
- 不用考虑并发写文件的问题,杜绝了锁机制带来的性能问题
- 由于文件不再更改,可以充分利用文件系统缓存,只需载入- -次,只要内存足够,对该文件的读取都会从内存读取,性能高
- 利于生成缓存数据
- 利于对文件进行压缩存储,节省磁盘和内存存储空间
坏处为需要写入新文档时,必须重新构建倒排索引文件,然后替换老文件后,新文档才
能被检索,导致文档实时性差

新文档搜索实时性

当有一个新的文档，构建倒排索引文件，对两个新旧索引进行同时查询，最后再进行一个汇总

Search运行机制

Search执行的时候实际分为两个步骤运行
- Query阶段
- Fetch阶段
  称为：Query-Then-Fetch

ES元数据

ES分词

https://www.jianshu.com/p/914f102bc174
以及自定分词

ES自带分词器

Standard
Simple
Whitespace
Stop
Keyword
Pattern
Language

es查询

URI Search

GET /lib/_search

在url中使用查询参数

  // 泛查询
  GET /lib/_search?q=tom
  {
    "profile": "true"
  }

GET /lib/_search?q=tom&df=name
{
  "profile": "true"
}
```

Request Body
- 使用ElasticSearch提供的，基于json格式的更加完备的Query Domain Specific Language (DSL查询)

Restful

GET，对应select:是从服务器查询，可以在服务器通过请求的参数区分查询的方式。
POST,对应Create:在服务器新建立一个资源，调用insert操作。
PUT，对应update操作:在服务器更新资源，调用update操作。
PATCH，对应update操作，在服务器更新资源，客户端提供改变的属性。（目前JDK7没有实现，tomcat7也不行。）
DELETE，对应DELETE操作，从服务器删除资源，调用delete语句。

Mapping参数

在7.0之后一个索引只可以有一个type

analyzer

分词器，默认为standard analyzer，当该字段被索引和搜索时对字段进行分词处理

boost

字段权重，默认为1.0

dynamic

Mapping中的字段类型一旦设定后，禁止直接修改，原因是：Lucene实现的倒排索引生成后不允许修改
只能新建一个索引，然后reindex数据
默认允许新增字段
通过dynamic参数来控制字段的新增：

true（默认）允许自动新增字段
false 不允许自动新增字段，但是文档可以正常写入，但无法对新增字段进行查询等操作
strict 文档不能写入，报错

index
控制当前字段是否索引，默认为true，即记录索引，false不记录，即不可搜索

PUT my_index
{
  "mappings": {
    "_doc": {
      "dynamic": false, 
      "properties": {
        "user": { 
          "properties": {
            "name": {
              "type": "text"
            },
            "social_networks": { 
              "dynamic": true,
              "properties": {}
            }
          }
        }
      }
    }
  }
}

定义后my_index这个索引下不能自动新增字段，但是在user.social_networks下可以自动新增子字段

分片

脑裂

文档分布式存储

存储一个document是如何选择存储在哪个分片上面

https://www.cnblogs.com/wangshouchang/p/8049492.html

.shard = hash(routing) % number_of_primary_shards

下面将对这个公式每个字段进行分析

shard 哪个分片，也就是分片id
routing 一个可变值，默认是文档的id
hash 一个哈希函数，对rounting字段进行哈希计算生成一个数字
number_of_primary_shards 主分片的数量，routing字段经过hash函数计算之后的值，将对主分片的数量也就是 number_of_primary_shards 进行取与，之后得到的shard就是我们文档所在的分片的位置

该算法与主分片数相关，这也就是主分片一旦创建就无法修改的原因

深度分页问题

深度分页是分布式存储系统必然会面临的一个问题

分页方式的应用场景

ES聚合

es将聚合分析主要分为4类：

Bucket 分桶类型，类似sql中的GROUP BY的语法
- Terms
- Range
- Date Range
- Histogram
- Date Histogram
Metric指标分析类型，计算最大值、最小值、平均值 distinct conunt
- 单值分析，只输出一个分析结果
  - min、max、avg、sum
  - cardinality类型distinct count()
- 多值分析，输出多个分析结果
  - stats,extended stas
  - percentile,percentile rank
  - top hits
Pipeline管道分析类型，基于上一级的聚合分析结果进行再分析
Matrix矩阵分析类型

日志监控平台–平台架构ELK

ElasticSearch是有其自己的套件的，简称ELK，即ElasticSearch，Logstash以及Kibana。ElasticSearch负责存储，Logstash负责收集数据来源，Kibana负责可视化数据，分工明确。

　　下面，我给大家用一个图来说明日志监控平台的架构，如下图所示：

　　通过上图，我们可以清晰的看到日志平台整个流向过程。首先，多个独立的Agent，这里就是图左边的三个LogStash节点，他们负责收集不同来源的数据，由一个Indexer负责进行汇总和分析数据，在这个当中有一个中间过程，这里我们使用了Broker，用Redis来实现这部分功能，其作用充当一个缓冲区，之后由ElasticSearch负责存储和搜索数据，最后由前段的Kibana可视化我们收集的数据。

　　这里说明几点需要注意的地方：

采用LogStash收集各种日志数据，其类型可以是：系统日志、文件、Redis、MQ等等。
Broker作为远程代理和中心代理的缓冲区，使用Redis进行实现，原因有二：其一，可以提高系统的性能；其二，可以提高系统的高可用性，当中心代理提取数据失败时，数据保存在Redis中，可以规避数据丢失的风险。
中心代理使用LogStash，负责从Broker中获取数据，可以执行相关的分析和处理，它提供有Filter功能。
ElasticSearch用于存储最终的数据，并对外提供搜索功能，基于Restful。
Kibana提供一个简单、丰富的Web View可视化界面，用于可视化ElasticSearch集群中的数据，支持各种查询、统计和展示。

ELK介绍
需求背景：

业务发展越来越庞大，服务器越来越多
各种访问日志、应用日志、错误日志量越来越多，导致运维人员无法很好的去管理日志
开发人员排查问题，需要到服务器上查日志，不方便
运营人员需要一些数据，需要我们运维到服务器上分析日志
为什么要用到ELK：

一般我们需要进行日志分析场景：直接在日志文件中 grep、awk 就可以获得自己想要的信息。但在规模较大也就是日志量多而复杂的场景中，此方法效率低下，面临问题包括日志量太大如何归档、文本搜索太慢怎么办、如何多维度查询。需要集中化的日志管理，所有服务器上的日志收集汇总。常见解决思路是建立集中式日志收集系统，将所有节点上的日志统一收集，管理，访问。

大型系统通常都是一个分布式部署的架构，不同的服务模块部署在不同的服务器上，问题出现时，大部分情况需要根据问题暴露的关键信息，定位到具体的服务器和服务模块，构建一套集中式日志系统，可以提高定位问题的效率。

一个完整的集中式日志系统，需要包含以下几个主要特点：

收集－能够采集多种来源的日志数据
传输－能够稳定的把日志数据传输到中央系统
存储－如何存储日志数据
分析－可以支持 UI 分析
警告－能够提供错误报告，监控机制
而ELK则提供了一整套解决方案，并且都是开源软件，之间互相配合使用，完美衔接，高效的满足了很多场合的应用。是目前主流的一种日志系统。

ELK简介：

ELK是三个开源软件的缩写，分别为：Elasticsearch 、 Logstash以及Kibana , 它们都是开源软件。不过现在还新增了一个Beats，它是一个轻量级的日志收集处理工具(Agent)，Beats占用资源少，适合于在各个服务器上搜集日志后传输给Logstash，官方也推荐此工具，目前由于原本的ELK Stack成员中加入了 Beats 工具所以已改名为Elastic Stack。

Elastic Stack包含：

Elasticsearch是个开源分布式搜索引擎，提供搜集、分析、存储数据三大功能。它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。详细可参考Elasticsearch权威指南

Logstash 主要是用来日志的搜集、分析、过滤日志的工具，支持大量的数据获取方式。一般工作方式为c/s架构，client端安装在需要收集日志的主机上，server端负责将收到的各节点日志进行过滤、修改等操作在一并发往elasticsearch上去。它可以从许多来源接收日志，这些来源包括 syslog、消息传递（例如 RabbitMQ）和JMX，它能够以多种方式输出数据，包括电子邮件、websockets和 Elasticsearch。

Kibana 也是一个开源和免费的工具，Kibana可以为 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面，可以帮助汇总、分析和搜索重要数据日志。

Beats在这里是一个轻量级日志采集器，其实Beats家族有6个成员，早期的ELK架构中使用Logstash收集、解析日志，但是Logstash对内存、cpu、io等资源消耗比较高。相比 Logstash，Beats所占系统的CPU和内存几乎可以忽略不计
ELK Stack （5.0版本之后）–> Elastic Stack == （ELK Stack + Beats）。目前Beats包含六种工具：

Packetbeat：网络数据（收集网络流量数据）
Metricbeat：指标（收集系统、进程和文件系统级别的 CPU 和内存使用情况等数据）
Filebeat：日志文件（收集文件数据）
Winlogbeat： windows事件日志（收集 Windows 事件日志数据）
Auditbeat：审计数据（收集审计日志）
Heartbeat：运行时间监控（收集系统运行时的数据）
关于x-pack工具：

x-pack对Elastic Stack提供了安全、警报、监控、报表、图表于一身的扩展包，是收费的

** Kibana索引用来存储数据，千万不要删除了它。它是将es数据通过kibana进行web展示的关键。这个配置后，在es的web界面里就会看到这个.kibana索引 **

提高 Elasticsearch 的高可用性

这时集群的作用就体现出来了。假如 Elasticsearch
只放在一台服务器上，即单机运行，假如这台主机突然断网了或者被攻击了，那么整个 Elasticsearch 的服务就不可用了。但如果改成
Elasticsearch 集群的话，有一台主机宕机了，还有其他的主机可以支撑，这样就仍然可以保证服务是可用的。

那假如一台主机宕机了，那么不就无法访问这台主机的数据了吗？那假如我要访问的数据正好存在这台主机上，那不就获取不到了吗？难道其他的主机里面也存了一份一模一样的数据？那这岂不是很浪费吗？

为了解答这个问题，这里就引出了 Elasticsearch
的信息存储机制了。首先解答上面的问题，一台主机宕机了，这台主机里面存的数据依然是可以被访问到的，因为在其他的主机上也有备份，但备份的时候也不是整台主机备份，是分片备份的，那这里就又引出了一个概念——分片(Shard)。

分片，英文叫做 Shard，顾名思义，分片就是对数据切分成了多个部分。我们知道 Elasticsearch
中一个索引（Index）相当于是一个数据库，如存某网站的用户信息，我们就建一个名为 user
的索引。但索引存储的时候并不是整个存一起的，它是被分片存储的，Elasticsearch
默认会把一个索引分成五个分片，当然这个数字是可以自定义的。分片是数据的容器，数据保存在分片内，分片又被分配到集群内的各个节点里。当你的集群规模扩大或者缩小时，
Elasticsearch 会自动的在各节点中迁移分片，使得数据仍然均匀分布在集群里，所以相当于一份数据被分成了多份并保存在不同的主机上。

那这还是没解决问题啊，如果一台主机挂掉了，那么这个分片里面的数据不就无法访问了？别的主机都是存储的其他的分片。其实是可以访问的，因为其他主机存储了这个分片的备份，叫做副本，这里就引出了另外一个概念——副本。

副本，英文叫做 Replica，同样顾名思义，副本就是对原分片的复制，和原分片的内容是一样的，Elasticsearch
默认会生成一份副本，所以相当于是五个原分片和五个分片副本，相当于一份数据存了两份，并分了十个分片，当然副本的数量也是可以自定义的。这时我们只需要将某个分片的副本存在另外一台主机上，这样当某台主机宕机了，我们依然还可以从另外一台主机的副本中找到对应的数据。所以从外部来看，数据结果是没有任何区别的。

一般来说，Elasticsearch 会尽量把一个索引的不同分片存储在不同的主机上，分片的副本也尽可能存在不同的主机上，这样可以提高容错率，从而提高高可用性。

但这时假如你只有一台主机，那不就没办法了吗？分片和副本其实是没意义的，一台主机挂掉了，就全挂掉了。

（2）健康状态

针对一个索引，Elasticsearch 中其实有专门的衡量索引健康状况的标志，分为三个等级：

green，绿色。这代表所有的主分片(primary shard)和副本(replica shard)分片都已分配。你的集群是 100% 可用的。
yellow，黄色。所有的主分片已经分片了，但至少还有一个副本是缺失的。不会有数据丢失，所以搜索结果依然是完整的。不过，你的高可用性在某种程度上被弱化。如果更多的分片消失，你就会丢数据了。所以可把
yellow 想象成一个需要及时调查的警告。
red，红色。至少一个主分片以及它的全部副本都在缺失中。这意味着你在缺少数据：搜索只能返回部分数据，而分配到这个分片上的写入请求会返回一个异常。

如果你只有一台主机的话，其实索引的健康状况也是
yellow，因为一台主机，集群没有其他的主机可以防止副本，所以说，这就是一个不健康的状态，因此集群也是十分有必要的。

（3）存储空间

另外，既然是群集，那么存储空间肯定也是联合起来的，假如一台主机的存储空间是固定的，那么集群它相对于单个主机也有更多的存储空间，可存储的数据量也更大。

所以综上所述，我们需要一个集群！

二、详细了解 Elasticsearch 集群

接下来我们再来了解下集群的结构是怎样的。

首先我们应该清楚多台主机构成了一个集群，每台主机称作一个节点（Node）。

如图就是一个三节点的集群：

在图中，每个 Node 都有三个分片，其中 P 开头的代表 Primary 分片，即主分片，R 开头的代表 Replica 分片，即副本分片。所以图中主分片
1、2，副本分片 0 储存在 1 号节点，副本分片 0、1、2 储存在 2 号节点，主分片 0 和副本分片 1、2 储存在 3 号节点，一共是 3 个主分片和
6 个副本分片。同时我们还注意到 1 号节点还有个 MASTER
的标识，这代表它是一个主节点，它相比其他的节点更加特殊，它有权限控制整个集群，比如资源的分配、节点的修改等等。

这里就引出了一个概念就是节点的类型，我们可以将节点分为这么四个类型：

主节点：即 Master
节点。主节点的主要职责是和集群操作相关的内容，如创建或删除索引，跟踪哪些节点是群集的一部分，并决定哪些分片分配给相关的节点。稳定的主节点对集群的健康是非常重要的。默认情况下任何一个集群中的节点都有可能被选为主节点。索引数据和搜索查询等操作会占用大量的cpu，内存，io资源，为了确保一个集群的稳定，分离主节点和数据节点是一个比较好的选择。虽然主节点也可以协调节点，路由搜索和从客户端新增数据到数据节点，但最好不要使用这些专用的主节点。一个重要的原则是，尽可能做尽量少的工作。
数据节点：即 Data 节点。数据节点主要是存储索引数据的节点，主要对文档进行增删改查操作，聚合操作等。数据节点对 CPU、内存、IO
要求较高，在优化的时候需要监控数据节点的状态，当资源不够的时候，需要在集群中添加新的节点。
负载均衡节点：也称作 Client
节点，也称作客户端节点。当一个节点既不配置为主节点，也不配置为数据节点时，该节点只能处理路由请求，处理搜索，分发索引操作等，从本质上来说该客户节点表现为智能负载平衡器。独立的客户端节点在一个比较大的集群中是非常有用的，他协调主节点和数据节点，客户端节点加入集群可以得到集群的状态，根据集群的状态可以直接路由请求。
预处理节点：也称作 Ingest 节点，在索引数据之前可以先对数据做预处理操作，所有节点其实默认都是支持 Ingest 操作的，也可以专门将某个节点配置为
Ingest 节点。

以上就是节点几种类型，一个节点其实可以对应不同的类型，如一个节点可以同时成为主节点和数据节点和预处理节点，但如果一个节点既不是主节点也不是数据节点，那么它就是负载均衡节点。具体的类型可以通过具体的配置文件来设置。