111 lines
5.4 KiB
Markdown
111 lines
5.4 KiB
Markdown
# ES简介
|
||
|
||
Elasticsearch 是一个非常强大的搜索引擎。它目前被广泛地使用于各个IT公司。Elasticsearch 是由 Elastic 公司创建并开源维护的。[代码库](https://github.com/elastic/elasticsearch)<br>
|
||
|
||
同时，Elastic 公司也拥有 Logstash 及 Kibana 开源项目。这个三个开源项目组合在一起，就形成了 ELK 软件栈。
|
||
|
||
他们三个共同形成了一个强大的生态圈。简单地说，Logstash 负责数据的采集，处理（丰富数据，数据转型等），Kibana 负责数据展，分析及管理。
|
||
|
||
Elasticsearch 处于最核心的位置，它可以帮我们对数据进行快速地搜索及分析。
|
||
|
||
|
||
|
||
|
||
|
||
# ES中的基本概念
|
||
|
||
|
||
## 文档（Document）
|
||
Elasticsearch是面向文档的，文档是所有可搜索数据的最小单位。
|
||
|
||
- 日志文件中的日志项
|
||
- 一本电影的具体信息/—张唱片的详细信息
|
||
- MP3播放器里的一首歌/ 一篇PDF文档中的具体内容
|
||
|
||
- 文档会被序列化成JSON格式，保存在Elasticsearch中，JSON对象由字段组成。每个字段都有对应的字段类型（字符串/数值/布尔/日期/二进制/范围类型）。
|
||
- 结构灵活。你的文档不依赖于预定义的架构。例如，并非所有事件都需要描述值，因此可以完全省略该字段。但它可能需要新的字段，例如位置的纬度和经度。
|
||
- 它可以是分层的。可以将其视为文档中的文档。字段的值可以很简单，就像位置字段的值可以是字符串一样。它还可以包含其他字段和值。例如，位置字段可能包含城市和街道地址。
|
||
- 每个文档都有一个Unique ID，你可以自己指定ID，或者通过Elasticsearch自动生成。
|
||
|
||
```json
|
||
{
|
||
"name": "Elasticsearch Denver",
|
||
"organizer": "Lee",
|
||
"location": "Denver, Colorado, USA"
|
||
}
|
||
```
|
||
|
||
#### 文档的元数据
|
||
|
||
元数据，用于标注文档的相关信息
|
||
|
||
- _index -文档所属的索引名
|
||
- type -文档所属的类型名
|
||
- _id -文档唯一Id
|
||
- _source：文档的原始Json数据
|
||
- _all:整合所有字段内容到该字段，已被废除
|
||
- _version :文档的版本信息
|
||
- _score :相关性打分
|
||
|
||
|
||
# 类型(Type)
|
||
|
||
关于Type，类型概念，在6.x版本中，一个索引(Index)可以拥有多个Type。在7.x版本(目前最新版本)，一个索引只能拥有一个Type，默认的type就是_doc，在7.x版本中，已经建议删除了。在未来的8.x版本会彻底删除。但是在7.x版本中，一个文档还是必须归属于一个类型。
|
||
|
||
|
||
|
||
|
||
|
||
# ES集群
|
||
|
||
|
||
Elasticsearch 的节点的分类如下：
|
||
|
||
1. 主节点（Master Node）：也叫作主节点，主节点负责创建索引、删除索引、分配分片、追踪集群中的节点状态等工作。Elasticsearch 中的主节点的工作量相对较轻。
|
||
|
||
用户的请求可以发往任何一个节点，并由该节点负责分发请求、收集结果等操作，而并不需要经过主节点转发。
|
||
|
||
通过在配置文件中设置 node.master=true 来设置该节点成为候选主节点（但该节点不一定是主节点，主节点是集群在候选节点中选举出来的），在 Elasticsearch 集群中只有候选节点才有选举权和被选举权。其他节点是不参与选举工作的。
|
||
|
||
2. 数据节点（Data Node）：数据节点，负责数据的存储和相关具体操作，比如索引数据的创建、修改、删除、搜索、聚合。
|
||
|
||
所以，数据节点对机器配置要求比较高，首先需要有足够的磁盘空间来存储数据，其次数据操作对系统 CPU、Memory 和 I/O 的性能消耗都很大。
|
||
|
||
通常随着集群的扩大，需要增加更多的数据节点来提高可用性。通过在配置文件中设置 node.data=true 来设置该节点成为数据节点。
|
||
|
||
3. 客户端节点（Client Node）：就是既不做候选主节点也不做数据节点的节点，只负责请求的分发、汇总等，也就是下面要说到的协调节点的角色。
|
||
|
||
其实任何一个节点都可以完成这样的工作，单独增加这样的节点更多地是为了提高并发性。
|
||
|
||
```shell
|
||
node.master=falsenode.data=false
|
||
```
|
||
|
||
4. 协调节点（Coordinating Node）：协调节点，是一种角色，而不是真实的 Elasticsearch 的节点，我们没有办法通过配置项来配置哪个节点为协调节点。集群中的任何节点都可以充当协调节点的角色。
|
||
|
||
|
||
当一个节点 A 收到用户的查询请求后，会把查询语句分发到其他的节点，然后合并各个节点返回的查询结果，最好返回一个完整的数据集给用户。
|
||
|
||
在这个过程中，节点 A 扮演的就是协调节点的角色。由此可见，协调节点会对 CPU、Memory 和 I/O 要求比较高。
|
||
|
||
|
||
|
||
## 集群健康
|
||
|
||
集群的状态有 Green、Yellow 和 Red 三种，如下所述：
|
||
|
||
Green：绿色，健康。所有的主分片和副本分片都可正常工作，集群 100% 健康。
|
||
|
||
Yellow：黄色，预警。所有的主分片都可以正常工作，但至少有一个副本分片是不能正常工作的。此时集群可以正常工作，但是集群的高可用性在某种程度上被弱化。
|
||
|
||
Red：红色，集群不可正常使用。集群中至少有一个分片的主分片及它的全部副本分片都不可正常工作。
|
||
|
||
这时虽然集群的查询操作还可以进行，但是也只能返回部分数据（其他正常分片的数据可以返回），而分配到这个分片上的写入请求将会报错，最终会导致数据的丢失。
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|