ElasticSearch知识体系详解

1.介绍

ElasticSearch是基于Lucene的开源搜索及分析引擎，使用Java语言开发的搜索引擎库类，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。 它可以被下面这样准确的形容：

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

1.1.主要功能及应用场景

除了搜索，结合Kibana、Logstash、Beats开源产品，Elastic Stack（简称ELK）还被广泛运用在大数据近实时分析领域
主要功能：
1）海量数据的分布式存储以及集群管理，达到了服务与数据的高可用以及水平扩展；
2）近实时搜索，性能卓越。可以对结构化、全文、地理位置等类型数据的处理；
3）海量数据的近实时分析（聚合功能）
应用场景：
1）网站搜索、垂直搜索、代码搜索；
2）日志管理与分析、安全指标监控、应用性能监控、Web抓取舆情分析。

1.2.ELK生态认知

如下是从官方博客中找到图，这张图展示了ELK生态以及基于ELK的场景（最上方）

1.3.基础概念

• Near Realtime（NRT） 近实时。数据提交索引后，立马就可以搜索到。
• Cluster 集群，一个集群由一个唯一的名字标识，默认为“elasticsearch”。集群名称非常重要，具有相同集群名的节点才会组成一个集群。集群名称可以在配置文件中指定。
• Node 节点：存储集群的数据，参与集群的索引和搜索功能。像集群有名字，节点也有自己的名称，默认在启动时会以一个随机的UUID的前七个字符作为节点的名字，你可以为其指定任意的名字。通过集群名在网络中发现同伴组成集群。一个节点也可是集群。
• Index 索引: 一个索引是一个文档的集合（等同于solr中的集合）。每个索引有唯一的名字，通过这个名字来操作它。一个集群中可以有任意多个索引。
• Type 类型：指在一个索引中，可以索引不同类型的文档，如用户数据、博客数据。从6.0.0 版本起已废弃，一个索引中只存放一类数据。
• Document 文档：被索引的一条数据，索引的基本信息单元，以JSON格式来表示。
• Shard 分片：在创建一个索引时可以指定分成多少个分片来存储。每个分片本身也是一个功能完善且独立的“索引”，可以被放置在集群的任意节点上。
• Replication 备份: 一个分片可以有多个备份（副本）

为了方便理解，作一个ES和数据库的对比

2.安装

2.1.官网

官方网站：https://www.elastic.co/cn/
官方2.x中文教程中安装教程：https://www.elastic.co/guide/cn/elasticsearch/guide/current/running-elasticsearch.html
官方ElasticSearch下载地址：https://www.elastic.co/cn/downloads/elasticsearch
官方Kibana下载地址：https://www.elastic.co/cn/downloads/kibana

2.2.安装

安装Java：安装 Elasticsearch 之前，你需要先安装一个较新的版本的 Java，最好的选择是，你可以从 www.java.com在新窗口打开 获得官方提供的最新版本的 Java。安装以后，确认是否安装成功：

下载ElasticSearch
解压

增加elasticSearch用户：必须创建一个非root用户来运行ElasticSearch(ElasticSearch5及以上版本，基于安全考虑，强制规定不能以root身份运行。)如果你使用root用户来启动ElasticSearch，则会有如下错误信息：

所以我们增加一个独立的elasticsearch用户来运行

进入elasticsearch.yml文件修改上述的data和log路径

修改Linux系统的限制配置
（1）修改系统中允许应用最多创建多少文件等的限制权限。Linux默认来说，一般限制应用最多创建的文件是65535个。但是ES至少需要65536的文件创建权限。
（2）修改系统中允许用户启动的进程开启多少个线程。默认的Linux限制root用户开启的进程可以开启任意数量的线程，其他用户开启的进程可以开启1024个线程。必须修改限制数为4096+。因为ES至少需要4096的线程池预备。ES在5.x版本之后，强制要求在linux中不能使用root用户启动ES进程。所以必须使用其他用户启动ES进程才可以。
（3）Linux低版本内核为线程分配的内存是128K。4.x版本的内核分配的内存更大。如果虚拟机的内存是1G，最多只能开启3000+个线程数。至少为虚拟机分配1.5G以上的内存。

启动ElasticSearch

查看安装是否成功

安装kibana
下载Kibana
Kibana是界面化的查询数据的工具，下载时尽量下载与ElasicSearch一致的版本。
解压

使用elasticsearch用户权限

启动

配置密码
（1）停止kibana和elasticsearch服务
（2）将xpack.security.enabled设置添加到ES_PATH_CONF/elasticsearch.yml文件并将值设置为true
（3）启动elasticsearch (./bin/elasticsearch -d)
（4）执行如下密码设置器，./bin/elasticsearch-setup-passwords interactive来设置各个组件的密码
（5）将elasticsearch.username设置添加到KIB_PATH_CONF/kibana.yml 文件并将值设置给elastic用户： elasticsearch.username: “elastic”
（6）创建kibana keystore, ./bin/kibana-keystore create
（7）在kibana keystore 中添加密码 ./bin/kibana-keystore add elasticsearch.password
（8）重启kibana 服务即可 nohup ./bin/kibana &

3.查询和聚合的使用

3.1.DSL查询之复合查询

3.1.1 bool query(布尔查询)

Bool查询语法有以下特点：
子查询可以任意顺序出现
可以嵌套多个查询，包括bool查询
如果bool查询中没有must条件，should中必须至少满足一条才会返回结果。

bool查询包含四种操作符，分别是must,should,must_not,filter。他们均是一种数组，数组里面是对应的判断条件。
must： 必须匹配。贡献算分
must_not：过滤子句，必须不能匹配，但不贡献算分
should： 选择性匹配，至少满足一条。贡献算分
filter： 过滤子句，必须匹配，但不贡献算分

3.1.2 function_score(函数查询）

script_score
如果需要预定义函数之外的功能，可以根据需要通过脚本进行实现

3.2.DSL查询之全文搜索

3.2.1.match多个词深入

它在内部实际上先执行两次 term 查询，然后将两次查询的结果合并作为最终结果输出。和如下语句查询结果是等同的

3.2.2.match的匹配精度

如果用户给定 3 个查询词，想查找至少包含其中 2 个的文档，该如何处理？将 operator 操作符参数设置成 and 或者 or 都是不合适的。
match 查询支持 minimum_should_match 最小匹配参数，这让我们可以指定必须匹配的词项数用来表示一个文档是否相关。 我们可以将其设置为某个具体数字，更常用的做法是将其设置为一个百分数，因为我们无法控制用户搜索时输入的单词数量

当给定百分比的时候， minimum_should_match 会做合适的事情：在之前三词项的示例中， 75% 会自动被截断成 66.6% ，即三个里面两个词。无论这个值设置成什么，至少包含一个词项的文档才会被认为是匹配的。

3.3.DSL查询之term

查询分基于文本查询和基于词项的查询，term主要讲基于词项的查询
字段是否存在:exist：文档字段的索引值可能不存在，exist表示查找是否存在字段
前缀:prefix：通过前缀查找某个字段
多个分词匹配:terms：按照多个分词term匹配，它们是or的关系
通配符:wildcard：通配符匹配，比如*
范围:range：常常被用在数字或者日期范围的查询
正则:regexp：通过正则表达式查询

3.4.聚合查询之Bucket

ElasticSearch中桶在概念上类似于 SQL 的分组（GROUP BY）
标准的聚合：聚合操作被置于顶层参数 aggs 之下（完整形式 aggregations 同样有效）
动态脚本的聚合：ElasticSearch还支持一些基于脚本（生成运行时的字段）的复杂的动态聚合
对number类型聚合：Range：基于Range的聚合，使用户能够定义一组范围-每个范围代表一个桶。
对IP类型聚合：IP Range：专用于IP值的范围聚合
对日期类型聚合：Date Range：专用于日期值的范围聚合

3.5.聚合查询之Metric

指标（Metrics） 对桶内的文档进行统计计算，类似于 COUNT() 、 SUM() 、 MAX() 等统计方法

单值分析:
标准stat类型
avg 平均值
max 最大值
min 最小值
sum 和
value_count 数量
其它类型
weighted_avg 带权重的avg
cardinality 基数（distinct去重）
median_absolute_deviation 中位值

非单值分析：
stats型
stats 包含avg,max,min,sum和count
matrix_stats 针对矩阵模型
string_stats 针对字符串
百分数型
percentiles 百分数范
percentile_ranks 百分数排行
地理位置型
geo_bounds Geo bounds
geo_centroid Geo-centroid
geo_line Geo-Line
Top型
top_hits 分桶后的top hits
top_metrics

3.6.聚合查询之Pipline

管道聚合（Pipeline Aggregation)简单而言就是让上一步的聚合结果成为下一个聚合的输入

嵌套的bucket聚合：聚合出按月价格的直方图
Metic聚合：对上面的聚合再求平均值

字段含义：
buckets_path：指定聚合的名称，支持多级嵌套聚合。
gap_policy 当管道聚合遇到不存在的值，有点类似于term等聚合的(missing)时所采取的策略，可选择值为：skip、insert_zeros。
skip：此选项将丢失的数据视为bucket不存在。它将跳过桶并使用下一个可用值继续计算。
format 用于格式化聚合桶的输出(key)。

以上内容主要用于构筑知识体系，用的时候查询下即可

4.性能优化

4.1.硬件配置优化

CPU 配置：大多数 Elasticsearch 部署往往对 CPU 要求不高。因此，相对其它资源，具体配置多少个（CPU）不是那么关键。常见的集群使用4 到 8 个核的机器。

内存配置：如果有一种资源是最先被耗尽的，它可能是内存。排序和聚合都很耗内存，所以有足够的堆空间来应付它们是很重要的。64 GB 内存的机器是非常理想的，但是 32 GB 和 16 GB 机器也是很常见的。少于8 GB 会适得其反（你最终需要很多很多的小机器），大于 64 GB 的机器也会有问题。

内存分配：当机器内存小于 64G 时，遵循通用的原则，50% 给 ES，50% 留给 lucene。

禁止 swap：禁止 swap，一旦允许内存与磁盘的交换，会引起致命的性能问题。可以通过在 elasticsearch.yml 中 bootstrap.memory_lock: true，以保持 JVM 锁定内存，保证 ES 的性能。

磁盘：硬盘对所有的集群都很重要，对大量写入的集群更是加倍重要（例如那些存储日志数据的）。硬盘是服务器上最慢的子系统，这意味着那些写入量很大的集群很容易让硬盘饱和，使得它成为集群的瓶颈。尽量使用固态硬盘（SSD）。

4.2.查询方面优化

带 routing 查询：查询的时候，可以直接根据 routing 信息定位到某个分配查询，不需要查询所有的分配，经过协调节点排序。routing 默认值是文档的 id，也可以采用自定义值，比如用户 ID。

Filter VS Query：Elasticsearch 针对 Filter 查询只需要回答「是」或者「否」，不需要像 Query 查询一样计算相关性分数，同时Filter结果可以缓存。

深度翻页：在使用 Elasticsearch 过程中，应尽量避免大翻页的出现。
正常翻页查询都是从 from 开始 size 条数据，这样就需要在每个分片中查询打分排名在前面的 from+size 条数据。如果 from 或者 size 很大的话，导致参加排序的数量会同步扩大很多，最终会导致 CPU 资源消耗增大。
可以结合实际业务特点，文档 id 大小如果和文档创建时间是一致有序的，可以以文档 id 作为分页的偏移量，并将其作为分页查询的一个条件。

Cache的设置及使用：QueryCache: ES查询的时候，使用filter查询会使用query cache, 如果业务场景中的过滤查询比较多，建议将querycache设置大一些，以提高查询速度。
FieldDataCache: 在聚类或排序时，field data cache会使用频繁，因此，设置字段数据缓存的大小，在聚类或排序场景较多的情形下很有必要。

4.3.集群架构设计

Elasticsearch 集群在架构拓朴时，采用主节点、数据节点和负载均衡节点分离的架构，在 5.x 版本以后，又可将数据节点再细分为“Hot-Warm”的架构模式。
Elasticsearch 的配置文件中有 2 个参数，node.master 和 node.data。这两个参数搭配使用时，能够帮助提供服务器性能。

主（master）节点：
配置 node.master:true 和 node.data:false，该 node 服务器只作为一个主节点，但不存储任何索引数据，专门负责处理集群的管理以及加强状态的整体稳定性。
因为这 3 个 master 节点不包含数据也不会实际参与搜索以及索引操作，所以master 节点的 CPU，内存以及磁盘配置可以比 data 节点少很多的。

数据（data）节点：
配置 node.master:false 和 node.data:true，该 node 服务器只作为一个数据节点，只用于存储索引数据，使该 node 服务器功能单一，只用于数据存储和数据查询，降低其资源消耗率。
hot 节点主要是索引节点（写节点），同时会保存近期的一些频繁被查询的索引。由于进行索引非常耗费 CPU 和 IO，即属于 IO 和 CPU 密集型操作，建议使用 SSD 的磁盘类型，保持良好的写性能。将节点设置为 hot 类型需要 elasticsearch.yml 如下配置：node.attr.box_type: hot。
warm节点是为了处理大量的，而且不经常访问的只读索引而设计的。由于这些索引是只读的，warm 节点倾向于挂载大量磁盘（普通磁盘）来替代 SSD。内存、CPU 的配置跟 hot 节点保持一致即可；节点数量一般也是大于等于 3 个。将节点设置为 warm 类型需要 elasticsearch.yml 如下配置：node.attr.box_type: warm。