ElasticSearch 学习笔记之基本概念

前言

ELK Stack 简介

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

Logstash 已经逐渐被beats 替代了。按照官方说法：

Logstash adds powerful data parsing and transformation features, but usually isn’t required.

Elastic Stack 包含：

Elasticsearch 是个开源分布式搜索引擎，提供搜集、分析、存储数据三大功能。详细可参考 Elasticsearch 权威指南
Logstash 主要是用来日志的搜集、分析、过滤日志的工具，支持大量的数据获取方式。一般工作方式为 c/s 架构，client 端安装在需要收集日志的主机上，server 端负责将收到的各节点日志进行过滤、修改等操作在一并发往 Elasticsearch 上去。
Kibana 也是一个开源和免费的工具，Kibana 可以为 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面，可以帮助汇总、分析和搜索重要数据日志。
Beats 在这里是一个轻量级日志采集器，其实 Beats 家族有 6 个成员，早期的 ELK 架构中使用 Logstash 收集、解析日志，但是 Logstash 对内存、cpu、io 等资源消耗比较高。相比 Logstash，Beats 所占系统的 CPU 和内存几乎可以忽略不计。

目前 Beats 包含六种工具：

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

是什么？

Elasticsearch is a real-time, distributed storage, search, and analytics engine

Elasticsearch 是一个实时的分布式存储、搜索、分析的引擎。

介绍那儿有几个关键字：

实时
分布式
搜索
分析（通过聚合来实现）

ES基于Apache Lucene(TM)的开源搜索引擎，是Lucene的集群版本。

为什么需要 Elasticsearch？

相对于传统关系型数据库，Elasticsearch的强大之处就是可以模糊查询。

主要表现在：

Elasticsearch对模糊搜索非常擅长（搜索速度很快）
从Elasticsearch搜索到的数据可以根据评分过滤掉大部分的，只要返回评分高的给用户就好了（原生就支持排序）
没有那么准确的关键字也能搜出相关的结果（能匹配有相关性的记录）

Elasticsearch的术语

Index：一个索引就是一个拥有相似特征的文档的集合。相当于数据库的database 。
Type：这个在新的Elasticsearch版本已经废除（在以前的Elasticsearch版本，一个Index下支持多个Type--有点类似于消息队列一个topic下多个group的概念）
Document：ES是面向文档(document oriented)的，这意味着它可以存储整个对象或文档(document)。然而它不仅仅是存储，还会索引(index)每个文档的内容使之可以被搜索。在ES中，你可以对文档（而非成行成列的数据）进行索引、搜索、排序、过滤。
Document相当于数据库的一行记录。由于es存储的数据是文档型的，一条数据对应一篇文档即相当于mysql数据库中的一行数据row，一个文档中可以有多个字段也就是mysql数据库一行可以有多列。一个文档是一个可被索引的基础信息单元。比如，你可以拥有某一个客户的文档、某一个产品的一个文档、某个订单的一个文档。文档以JSON格式来表示，而JSON是一个到处存在的互联网数据交互格式。
Field：相当于数据库的Column的概念
Mapping：相当于数据库的Schema的概念，定义 field 的类型。
DSL：(Domain Specific Language特定领域语言)以JSON请求体的形式出现。相当于数据库的SQL（给我们读取Elasticsearch数据的API）
shards and replicas：分片和复制
segment：真实的写入单位
GET/PUT/POST/DELETE 分别类似与mysql中的select/update/delete

RDBMS(关系型数据库)	ElasticSearch
Database	Index
Row	Document
Column	Field
Schema	Mapping
SQL	DSL

相信大家看完上面的对比图，对Elasticsearch的一些术语就不难理解了。

一个Elasticsearch集群会有多个Elasticsearch节点，所谓节点实际上就是运行着Elasticsearch进程的机器。

在众多的节点中，其中会有一个Master Node，它主要负责维护索引元数据、负责切换主分片和副本分片身份等工作（后面会讲到分片的概念），如果主节点挂了，会选举出一个新的主节点。

Elasticsearch最外层的是Index（相当于数据库表的概念）；一个Index的数据我们可以分发到不同的Node上进行存储，这个操作就叫做分片。

比如现在我集群里边有4个节点，我现在有一个Index，想将这个Index在4个节点上存储，那我们可以设置为4个分片。这4个分片的数据合起来就是Index的数据。

为什么要分片？原因也很简单：

如果一个Index的数据量太大，只有一个分片，那只会在一个节点上存储，随着数据量的增长，一个节点未必能把一个Index存储下来。
多个分片，在写入或查询的时候就可以并行操作（从各个节点中读写数据，提高吞吐量）

现在问题来了，如果某个节点挂了，那部分数据就丢了吗？显然Elasticsearch也会想到这个问题，所以分片会有主分片和副本分片之分（为了实现高可用）

数据写入的时候是写到主分片，副本分片会复制主分片的数据，读取的时候主分片和副本分片都可以读。

Index需要分为多少个主分片和副本分片都是可以通过配置设置的

ES中节点的角色 Role

ES中节点分为四种类型：Node Roles

主节点 master节点

主要职责就是负责集群管理，如索引创建或删除，发现集群其它节点并确定那些分片分配到相应的节点，默认情况下任何一个节点都有可能被选举为master节点，但是索引数据何搜索查询等操作会占用大量CPU、内存和IO资源，为了保证集群的稳定，通常分离主节点和数据节点；

node.master: true
node.data: false
node.ingest: false

2）数据节点 data节点

数据节点主要是存储索引数据，主要对文档进行增删改查操作，数据节点对CPU、内存和IO要求较高；

node.master: false
node.data: true
node.ingest: false

3）负载均衡节点 client节点

当一个节点既不配置为主节点也不配置为数据节点时，该节点只能处理路由请求，处理搜索，分发索引操作；

node.master: false
node.data: false
node.ingest: false

4）预处理节点 ingest节点

预处理节点在索引数据之前可以对数据做预处理，默认所有的节点都支持ingest操作，但是也可以专门设置一个Ingest节点；

node.master: false
node.data: false
node.ingest: true

Elasticsearch更新和删除

Elasticsearch的更新和删除操作流程：

给对应的doc记录打上.del标识，如果是删除操作就打上delete状态，如果是更新操作就把原来的doc标志为delete，然后重新新写入一条数据

前面提到了，每隔1s会生成一个segement 文件，那segement文件会越来越多越来越多。Elasticsearch会有一个merge任务，会将多个segement文件合并成一个segement文件。

在合并的过程中，会把带有delete状态的doc给物理删除掉。

Elasticsearch查询

查询我们最简单的方式可以分为两种：

根据ID查询doc -- 类似传统关系型数据库
根据query（搜索词）去查询匹配的doc -- 这才是ES 的优势（全文检索）

根据ID去查询具体的doc的流程是：

检索内存的Translog文件
检索硬盘的Translog文件
检索硬盘的Segement文件

根据query去匹配doc的流程是：

同时去查询内存和硬盘的Segement文件

因为segement文件是每隔一秒才生成一次的
Elasticsearch查询又分可以为三个阶段：

QUERY_AND_FETCH（查询完就返回整个Doc内容）
QUERY_THEN_FETCH（先查询出对应的Doc id ，然后再根据Doc id 匹配去对应的文档）
DFS_QUERY_THEN_FETCH（先算分，再查询）
「这里的分指的是 词频率和文档的频率（Term Frequency、Document Frequency）众所周知，出现频率越高，相关性就更强」

一般我们用得最多的就是QUERY_THEN_FETCH，第一种查询完就返回整个Doc内容（QUERY_AND_FETCH）只适合于只需要查一个分片的请求。

QUERY_THEN_FETCH总体的流程流程大概是：

客户端请求发送到集群的某个节点上。集群上的每个节点都是coordinate node（协调节点）
然后协调节点将搜索的请求转发到所有分片上（主分片和副本分片都行）
每个分片将自己搜索出的结果(doc id)返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最终结果。
接着由协调节点根据 doc id 去各个节点上拉取实际的 document 数据，最终返回给客户端。

Query Phase阶段时节点做的事：

协调节点向目标分片发送查询的命令（转发请求到主分片或者副本分片上）
数据节点（在每个分片内做过滤、排序等等操作），返回doc id给协调节点

Fetch Phase阶段时节点做的是：

协调节点得到数据节点返回的doc id，对这些doc id做聚合，然后将目标数据分片发送抓取命令（希望拿到整个Doc记录）
数据节点按协调节点发送的doc id，拉取实际需要的数据返回给协调节点

主流程我相信大家也不会太难理解，说白了就是：由于Elasticsearch是分布式的，所以需要从各个节点都拉取对应的数据，然后最终统一合成给客户端

安装

测试环境：VirtualBox，ubuntu16 虚机

wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -
sudo apt-get install apt-transport-https
echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-7.x.list
sudo apt-get update && sudo apt-get install elasticsearch

当前安装的版本是7.9

refs

Linux 源码方式

从官网下载linux源码包 https://www.elastic.co/downloads/elasticsearch

curl -L -O https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.9.2-linux-x86_64.tar.gz
tar -xzvf elasticsearch-7.9.2-linux-x86_64.tar.gz
cd elasticsearch-7.9.2
./bin/elasticsearch

配置

The config directory location defaults to /etc/elasticsearch.

Elasticsearch has three configuration files:

elasticsearch.yml for configuring Elasticsearch
jvm.options for configuring Elasticsearch JVM settings
log4j2.properties for configuring Elasticsearch logging

ElasticSearch 学习笔记 之基本概念

前言