Elasticsearch
作者：互联网
Elasticsearch
什么是Elasticsearch
Elasticsearch、Kibana、Beats 和 Logstash
ES 是一个开源的高扩展的分布式全文搜索引擎
全文搜索引擎
这里说到的全文搜索引擎指的是目前广泛应用的主流搜索引擎。它的工作原理是计算机
索引程序通过扫描文章中的每一个词，对每一个词建立一个索引，指明该词在文章中出现的
次数和位置，当用户查询时，检索程序就根据事先建立的索引进行查找，并将查找的结果反
馈给用户的检索方式。这个过程类似于通过字典中的检索字表查字的过程。
Elasticsearch 入门
2.2.4 HTTP 操作
索引操作127.0.0.1:9200/user/_mapping
创建索引
在postman中相es服务器发送PUT请求
http://127.0.0.1:9200/shopping
响应结果
{
"acknowledged"【响应结果】: true, # true 操作成功
"shards_acknowledged"【分片结果】: true, # 分片操作成功
"index"【索引名称】: "shopping"
}
# 注意：创建索引库的分片数默认 1 片，在 7.0.0 之前的 Elasticsearch 版本中，默认 5 片
查看所有索引
发送GET请求
http://127.0.0.1:9200/_cat/indices?v
表头 含义
health 当前服务器健康状态：
green(集群完整) yellow(单点正常、集群不完整) red(单点不正常)
status 索引打开、关闭状态
index 索引名
uuid 索引统一编号
pri 主分片数量
rep 副本数量
docs.count 可用文档数量
docs.deleted 文档删除状态（逻辑删除）
store.size 主分片和副分片整体占空间大小
pri.store.size 主分片占空间大小
查看单个索引
在 Postman 中，向 ES 服务器发 GET 请求 ：http://127.0.0.1:9200/shopping
{
"shopping"【索引名】: {
"aliases"【别名】: {},
"mappings"【映射】: {},
"settings"【设置】: {
"index"【设置 - 索引】: {
"creation_date"【设置 - 索引 - 创建时间】: "1614265373911",
"number_of_shards"【设置 - 索引 - 主分片数量】: "1",
"number_of_replicas"【设置 - 索引 - 副分片数量】: "1",
"uuid"【设置 - 索引 - 唯一标识】: "eI5wemRERTumxGCc1bAk2A",
"version"【设置 - 索引 - 版本】: {
"created": "7080099"
},
"provided_name"【设置 - 索引 - 名称】: "shopping"
}
}
}
}
删除索引
在 Postman 中，向 ES 服务器发 DELETE 请求 ：http://127.0.0.1:9200/shopping
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，否则会发生错误
响应
{
"_index"【索引】: "shopping",
"_type"【类型-文档】: "_doc",
"_id"【唯一标识】: "Xhsa2ncBlvF_7lxyCE9G", #可以类比为 MySQL 中的主键，随机生成
"_version"【版本】: 1,
"result"【结果】: "created", #这里的 create 表示创建成功
"_shards"【分片】: {
"total"【分片 - 总数】: 2,
"successful"【分片 - 成功】: 1,
"failed"【分片 - 失败】: 0
},
"_seq_no": 0,
"_primary_term": 1
}
上面的数据创建后，由于没有指定数据唯一性标识（ID），默认情况下，ES 服务器会随机
生成一个。
如果想要自定义唯一性标识，需要在创建时指定：http://127.0.0.1:9200/shopping/_doc/1
此处需要注意：如果增加数据时明确数据主键，那么请求方式也可以为 PUT
查看文档
查看文档时，需要指明文档的唯一性标识，类似于 MySQL 中数据的主键查询 在 Postman 中，向 ES 服务器发 GET 请求 ：http://127.0.0.1:9200/shopping/_doc/1
{
"_index"【索引】: "shopping",
"_type"【文档类型】: "_doc",
"_id": "1",
"_version": 2,
"_seq_no": 2,
"_primary_term": 2,
"found"【查询结果】: true, # true 表示查找到，false 表示未查找到
"_source"【文档源信息】: {
"title": "华为手机",
"category": "华为",
"images": "http://www.gulixueyuan.com/hw.jpg",
"price": 4999.00
}
}
修改文档
和新增文档一样，输入相同的 URL 地址请求，如果请求体变化，会将原有的数据内容覆盖
在 Postman 中，向 ES 服务器发 POST 请求 ：http://127.0.0.1:9200/shopping/_doc/1
请求体内容为:
{
"title":"华为手机",
"category":"华为",
"images":"http://www.gulixueyuan.com/hw.jpg",
"price":4999.00
}
{
"_index": "shopping",
"_type": "_doc",
"_id": "1",
"_version"【版本】: 2,
"result"【结果】: "updated", # updated 表示数据被更新
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"_seq_no": 2,
"_primary_term": 2
}
修改字段
修改某一条信息
在 Postman 中，向 ES 服务器发 POST 请求 ：http://127.0.0.1:9200/shopping/_update/1
{
"doc": {
"price":3000.00
}
}
删除文档
5) 删除文档
删除一个文档不会立即从磁盘上移除，它只是被标记成已删除（逻辑删除）。
在 Postman 中，向 ES 服务器发 DELETE 请求 ：http://127.0.0.1:9200/shopping/_doc/1
{
"_index": "shopping",
"_type": "_doc",
"_id": "1",
"_version"【版本】: 4, #对数据的操作，都会更新版本
"result"【结果】: "deleted", # deleted 表示数据被标记为删除
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"_seq_no": 4,
"_primary_term": 2
}
条件删除文档
一般删除数据都是根据文档的唯一性标识进行删除，实际操作时，也可以根据条件对多条数
据进行删除
首先分别增加多条数据:
{
"title":"小米手机",
"category":"小米",
"images":"http://www.gulixueyuan.com/xm.jpg",
"price":4000.00
}
{
"title":"华为手机",
"category":"华为",
"images":"http://www.gulixueyuan.com/hw.jpg",
"price":4000.00
}
向 ES 服务器发 POST 请求 ：http://127.0.0.1:9200/shopping/_delete_by_query
{
"query":{
"match":{
"price":4000.00
}
}
}
删除成功
{
"took"【耗时】: 175,
"timed_out"【是否超时】: false,
"total"【总数】: 2,
"deleted"【删除数量】: 2,
"batches": 1,
"version_conflicts": 0,
"noops": 0,
"retries": {
"bulk": 0,
"search": 0
},
"throttled_millis": 0,
"requests_per_second": -1.0,
"throttled_until_millis": 0,
"failures": []
}
利用python操作ElasticSearch
利用python对ElasticSearch进行操作主要会涉及两个python库elasticsearch和elasticsearch-dsl。除此之外，还会一个更为简单的python库：es-pandas。
其中，elasticsearch-py是一个官方提供的elasticsearch python客户端库，它只是对elasticsearch的rest API接口做了一层简单的封装。相对于这个客户端库，官方还提供了相对高级的elasticsearch-dsl客户端库。而es-pandas主要用于读、写和更新大型pandas DataFrame到ElasticSearch。
本文主要介绍elasticsearch-py库，篇幅有限，详细可以参考官方文档。下面将按照操作的一般流程进行介绍，包括以下几个小节：连接elasticsearch，索引的相关操作，数据查询，批量插入数据至elasticsearch，实例：读取、写入ElasticSearch
（1）导入相关包
from elasticsearch import Elasticsearch
2）连接elasticsearch
host = 192.168.1.100 # 随便造的，使用时换上自己的真实host即可
post = 8888
es= Elasticsearch([{'host': host, 'port': post}])
3）索引
① 创建索引
如果需要自定义mapping，则指需将mapping定义好后传递给body参数即可，如`es.indices.create(index="index_name", body=mapping)`
es.indices.create("index_name")
② 删除索引
es.indices.delete("index_name")
③ 重建索引
重建索引主要用于需要将某个索引的全部数据（或者查询的数据）原封不动的迁移到另一个索引当中，包括mapping等都与原来的索引相同。其中，source_index参数为源索引，target_index参数为目标索引。（重建索引迁移数据，不会覆盖原来的数据，例如：将数据集a迁移到索引index中，然后将数据b迁移到索引index中，index中包含a和b的数据，且a和b中_id和索引相同的数据不会重复）
注意： 目标索引不用提前创建（es.indices.create），索引不存在将会自动创建，如果提前创建了反而会因为mapping不一致进而出错。
from elasticsearch import helpers
# 索引重建、数据迁移
body={"query":{"match_all":{}}} #遍历原索引，可自定义query
helpers.reindex(client=es,
source_index='old_index_name',
target_index='new_index_name',
target_client=es,
query=body)
④ 查看当前es中的索引
# 查看所有索引，且展示每个索引的详细结构。
indexs = es.indices.get("*")
# 查看es中的所有索引的名称
index_names = indexs.keys()
# 查看某个索引
index = es.indices.get("index_name")
⑤ 判断某个索引是否存在
# 判断索引是否存在，存在将会返回True
es.indices.exists(index='index_name')
4）查询数据
elasticsearch python客户端库查询数据主要使用es.search()，将查询语句传递给body参数即可，如果要限制返回的最大数据量，则指需指定size参数值即可，如size=1000。
① 查询全部数据——match_all
body={
"query" : {
"match_all" : {}
}
}
# index_name即为es中的索引名
es.search(index="index_name", doc_type="doc_type_name", body=body，size=1000)
② 等于查询——term、terms
erm支持查询某个字段等于某个值这样的业务场景（一对一），而terms支持查询某个字段等于多个值的业务场景（一对多）。
例1：查询lang=python的数据
body={
"query" : {
"term" : {
"lang" : "python"
}
}
}
es.search(index="index_name", doc_type="doc_type_name", body=body)
例2：查询lang=python或者lang=c++的数据
body={
"query" : {
"terms" : {
"lang" : [
"python", "c++"
]
}
}
}
es.search(index="index_name", doc_type="doc_type_name", body=body)
③ 包含查询——match、multi_match
match支持某个字段包含某个关键字，而multi_match支持查询多个字段包含某个关键字。
例1：查询name中包含”李“关键字的数据
body={
"query" : {
"match" : {
"name" : "李"
}
}
}
es.search(index="index_name", doc_type="doc_type_name", body=body)
例2：查询addr和city两个字段中包含”深圳“关键字
body = {
"query" : {
"multi_match" : {
"query" : "深圳",
"fields" : ["name", "addr"]
}
}
}
es.search(index="index_name", doc_type="doc_type_name", body=body)
④ 复合查询——bool
bool有3类查询关系，must(都满足),should(其中一个满足),must_not(都不满足)。
例：获取name="python"并且age=18的所有数据
body = {
"query":{
"bool":{
"must":[
{
"term":{
"name":"python"
}
},
{
"term":{
"age":18
}
}
]
}
}
}
es.search(index="index_name",doc_type="type_name",body=body)
⑤ 切片式查询——from、size
from为从第多少条数据开始查询，size为查询的数据量。
body = {
"query":{
"match_all":{}
}
"from":2 # 从第二条数据开始
"size":4 # 获取4条数据
}
# 从第2条数据开始，获取4条数据
es.search(index="index_name",doc_type="type_name",body=body)
⑥ 范围查询——range
range 过滤–按照指定范围查找一批数据，gt : 大于，gte : 大于等于，lt : 小于，lte : 小于等于。例如使用gte和lte，获取的数据范围为：gte<=字段值<=lte。
值得注意的是，针对日期格式的字段，一般需要配合format使用，format的格式为gte和lte的格式，而不是字段值的格式，format的日期格式可以自定义，也可以使用定义好的值，可以参考这篇文章和官方指导手册。
例：查询@timestamp在2020-07-04 8：12：00 到 2020-07-04 09：20：00时间段的数据。
body = {
"query":{
"range":{
"@timestamp":{
"gte": "2020-07-04 08:12:00",
"lte": "2020-07-04 09:20:00",
"format":"yyyy-MM-dd HH:mm:ss"
}
}
}
}
es.search(index="index_name",doc_type="type_name",body=body)
⑦ 通配符查询——wildcard
body = {
"query":{
"wildcard":{
"name":"*id"
}
}
}
# 查询name以id为后缀的所有数据
es.search(index="index_name",doc_type="type_name",body=body)
⑧ 排序——sort
排序主要通过sort中order字段限制升序（asc)还是降序(desc)。
body = {
"query":{
"match_all":{}
}
"sort":{
"age":{ # 根据age字段升序排序
"order":"asc" # asc升序，desc降序
}
}
}
es.search(index="index_name",doc_type="type_name",body=body)
当需要对多个字段进行排序时，需要注意sort下的字段顺序，字段顺序即为排序顺序。
body = {
"query":{
"match_all":{}
}
"sort":[{
"age":{ # 先根据age字段升序排序
"order":"asc" # asc升序，desc降序
}
},{
"name":{ # 后根据name字段升序排序
"order":"asc" # asc升序，desc降序
}
}],
}
es.search(index="index_name",doc_type="type_name",body=body)
⑨ 响应过滤——filter_path
# 只需要获取_id数据,多个条件用逗号隔开
es.search(index="index_name",doc_type="type_name",filter_path=["hits.hits._id"])
# 获取所有数据
es.search(index="index_name",doc_type="type_name",filter_path=["hits.hits._*"])
（5）删除符合条件的数据
先根据查询语句查询数据，然后使用delete_by_query删除查询到的数据。例如：删除平均加速度大于等于0.4的数据。
body = { "query":{ "range":{ "average_acceleration":{ "gte": 0.4} } } }
es.delete_by_query(index='index_name', body=body)
（6）批量插入数据至ElasticSearch
本小节主要展示将python中pandas数据插入到ElasticSearch，即批量插入数据，批量插入数据需要使用到helpers.bulk。对于单条数据，也可以使用此方法插入。
例如：读取本地csv文件数据（两列column1、column2），并将其插入到ElasticSearch中。
import pandas as pd
from elasticsearch import helpers
df = pd.read_csv('data.csv')
# 将要插入的数据以字典的形式存入列表中，如果是单条数据，则列表长度为1。
action_list = [df.loc[ind, :].to_dict() for ind in df.index]
helpers.bulk(es, action_list, index="index_name", doc_type="doc", raise_on_error=True)
处理思路如下：首先，读取数据。然后将每行数据转换成字典格式存入action_list列表中。最后使用helpers.bulk()将所有数据插入到ElasticSearch中。其中，helpers.bulk中es为上文中连接后的es变量，action_list为要插入的全部数据，index为数据存放的索引。索引的创建方法，可以看第（3）小节。
（7）批量更新数据
针对单条数据可以适用update、update_by_query更新。此外，批量更新ElasticSearch中的数据可以使用update、update_by_query等函数结合循环语句进行批量更新，也可以使用helpers.bulk进行一次性批量更新。
例如：需要将某个索引（predict_save_index）中的数据进行，根据_id（存放在update_id_list列表中）对某个字段（pred）的值进行更新（如果该字段不存在，就会自动创建，类似于pandas中数据框给字段赋值一样，字段不存在就会自动创建）。
actions = []
for ind, pred_label in zip(update_id_list, df['pred_label']): action = {
"_op_type": "update", # 操作命令，这里为更新
"index": predict_save_index, # 数据的索引
"_id": ind, # 要更新的数据 _id
"doc": {
"pred": pred_label # 更新pred字段，值为pred_label，如果该字段不存在，将会自动新增该字段
}
}
actions.append(action)
helpers.bulk(es,actions,index=predict_save_index,
doc_type="doc", raise_on_error=True)
其中，update_id_list为需要更新数据的_id的列表，df[‘pred_label’]为需要赋给es中pred字段的值，es为已经连接成功的客户端。
（8）实例：读取、写入ElasticSearch
业务场景：需要获取当前时间前5分钟内的数据，且数据量最多不超过10000条，并将其写入到新的索引当中。
读取数据思路：
涉及查询ElasticSearch数据，且为查询某个时间段的数据（范围range）。
写入数据思路：
a、读取到的数据转为数据框后，采用第（5）小节的方法，将其批量插入到ElasticSearch中，这个思路其实更适用，因为，在日常工作中，我们往往读取数据后，需要对数据做一定的处理，然后保存处理后的结果到新的索引中，而不是读取后直接存储，这里我为了方便，就把处理数据的过程给省略了。
b、直接使用重建索引，进行数据迁移。重建索引进行数据迁移，很适合用于保留原始数据的业务场景，因为在保留原始数据的情况下，插入数据经常会因为原始数据的格式而触发错误，除非新索引与原始数据的格式一致。
下面的代码为思路a，思路b不介绍，其比较简单，直接利用第（3）小节的代码即可。
import pandas as pd
from elasticsearch import Elasticsearch
from elasticsearch import helpers
from datetime import datetime, timedelta
from dateutil.relativedelta import relativedelta
class EsData(object):
"""从ES中读取数据"""
def __init__(self, config_path):
"""
:param config_path: 配置文件路径
:param data_col: 要获取的数据列（list）
:param new_col: 重新定义原始数据列的列名（list）
"""
self.config = configparser.ConfigParser()
self.config.read(config_path, encoding="utf-8-sig") # 配置文件中有中文，则需要指定encoding参数
self.es_index = self.config.get('ES', 'index') # 从配置文件中读取指定的索引名称
self.es = self.es_conn() # 连接elasticsearch
def es_conn(self):
"""连接ES"""
es_host = self.config.get('ES', 'host') # 从配置文件中读取host，也可以自己指定
es_port = self.config.get('ES', 'port')
es = Elasticsearch([{'host': es_host, 'port': es_port, 'timeout': 300}])
return es
def get_data_on_5minutes_maxsize(self):
"""
获取当前时间的前5分钟数据，且数据量大小不超过配置文件中设置的max_size
:return: 索引中符合条件的全部数据（所有列）
"""
time_diff = 5
max_size = 10000
current_time = datetime.now()
# 起始时间，注意为字符串格式
gte_time = (current_time - relativedelta(minutes=int(time_diff))).strftime('%Y-%m-%d %H:%M:%S')
# 结束时间，字符串格式
lte_time = current_time.strftime('%Y-%m-%d %H:%M:%S')
# print('gte_time:{} lte_time:{}'.format(gte_time, lte_time))
body = {
"query": {
"range": {
"@timestamp": {
"gte": gte_time,
"lte": lte_time,
"format": "yyyy-MM-dd HH:mm:ss||date_time"
}
}
}
}
s_5minutes = self.es.search(index=self.es_index, body=body, size=max_size)
# 数据存在”_source“中，因此提取该字段的数据，如果想获取其他字段的数据，更换”_source“即可
df_ontime = pd.DataFrame([hit['_source'] for hit in s_5minutes['hits']['hits']])
print('es中在{} ~ {}时间间隔的数据共有{}条'.format(gte_time, lte_time, len(df_ontime)))
return df_ontime
def write_data_to_es(self, df):
current_date = datetime.now().strftime('%Y-%m-%d')
#创建存储数据的索引名称
predict_save_index = 'predicted-save-index-' + current_date
# 判断predict_save_index索引是否存在
if self.es.indices.exists(predict_save_index):
pass
else:
print('预测结果保存的索引不存在，将重新创建')
self.es.indices.create(index=predict_save_index)
action_list = [df.loc[ind, :].to_dict() for ind in df.index]
helpers.bulk(self.es, action_list, index=predict_save_index, doc_type="doc", raise_on_error=True)
Elasticsearch 环境
3.1 相关概念 3.1.1 单机 & 集群
单台 Elasticsearch 服务器提供服务，往往都有最大的负载能力，超过这个阈值，服务器
性能就会大大降低甚至不可用，所以生产环境中，一般都是运行在指定服务器集群中。
除了负载能力，单点服务器也存在其他问题：
单台机器存储容量有限
单服务器容易出现单点故障，无法实现高可用
单服务的并发处理能力有限
配置服务器集群时，集群中节点数量没有限制，大于等于 2 个节点就可以看做是集群了。一
般出于高性能及高可用方面来考虑集群中节点数量都是 3 个以上。
3.1.2 集群 Cluster
一个集群就是由一个或多个服务器节点组织在一起，共同持有整个的数据，并一起提供
索引和搜索功能。一个 Elasticsearch 集群有一个唯一的名字标识，这个名字默认就
是”elasticsearch”。这个名字是重要的，因为一个节点只能通过指定某个集群的名字，来加入
这个集群。
3.1.3 节点 Node
集群中包含很多服务器，一个节点就是其中的一个服务器。作为集群的一部分，它存储
数据，参与集群的索引和搜索功能。
一个节点也是由一个名字来标识的，默认情况下，这个名字是一个随机的漫威漫画角色
的名字，这个名字会在启动的时候赋予节点。这个名字对于管理工作来说挺重要的，因为在
这个管理过程中，你会去确定网络中的哪些服务器对应于 Elasticsearch 集群中的哪些节点。
一个节点可以通过配置集群名称的方式来加入一个指定的集群。默认情况下，每个节点
都会被安排加入到一个叫做“elasticsearch”的集群中，这意味着，如果你在你的网络中启动了
若干个节点，并假定它们能够相互发现彼此，它们将会自动地形成并加入到一个叫做
“elasticsearch”的集群中
在一个集群里，只要你想，可以拥有任意多个节点。而且，如果当前你的网络中没有运
行任何 Elasticsearch 节点，这时启动一个节点，会默认创建并加入一个叫做“elasticsearch”的
集群。
Windows 集群部署
1）删除掉其中的data文件夹和清空logs文件夹下的日志。
2）打开config目录，修改elasticsearch.yml文件
官网文档：Networking | Elasticsearch Guide [8.2] | Elastic
放开集群名称和节点名称（并告知当前节点可以是master也可以是数据）：
修改配置文件elasticsearch.yml
#集群名称
cluster.name: my-application
#
# ------------------------------------ Node ------------------------------------
#
# Use a descriptive name for the node:
#节点名称
node.name: node-1001
node.roles: [master,data]
#网络地址
network.host: localhost
#通信端口
http.port: 1001
# 监听端口
transport.port: 9301
跨域配置
http.cors.enabled: true
http.cors.allow-origin: "*"
3）将文件夹名称改成node-1001
4）双击bin目录下elasticsearch.bat启动
5）访问：http://localhost:1001/_cluster/health 查看集群状态
可以看到当前节点数一个，数据节点也是1个。
2.2 节点node-1002
将节点1的文件夹复制一份
注意：需要将其中的data文件夹删掉，并且清空logs下的日志
除了相应的端口号需要改变外，还需要加上如下配置，发现其他的节点。
discovery.seed_hosts: ["localhost:9301"]
# ======================== Elasticsearch Configuration =========================
#
# NOTE: Elasticsearch comes with reasonable defaults for most settings.
# Before you set out to tweak and tune the configuration, make sure you
# understand what are you trying to accomplish and the consequences.
#
# The primary way of configuring a node is via this file. This template lists
# the most important settings you may want to configure for a production cluster.
#
# Please consult the documentation for further information on configuration options:
# https://www.elastic.co/guide/en/elasticsearch/reference/index.html
#
# ---------------------------------- Cluster -----------------------------------
#
# Use a descriptive name for your cluster:
#
cluster.name: my-application
#
# ------------------------------------ Node ------------------------------------
#
# Use a descriptive name for the node:
#
node.name: node-1002
node.roles: [master,data]
#
# Add custom attributes to the node:
#
#node.attr.rack: r1
#
# ----------------------------------- Paths ------------------------------------
#
# 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
#
# ----------------------------------- Memory -----------------------------------
#
# Lock the memory on startup:
#
#bootstrap.memory_lock: true
#
# Make sure that the heap size is set to about half the memory available
# on the system and that the owner of the process is allowed to use this
# limit.
#
# Elasticsearch performs poorly when the system is swapping the memory.
#
# ---------------------------------- Network -----------------------------------
#
# By default Elasticsearch is only accessible on localhost. Set a different
# address here to expose this node on the network:
#
network.host: localhost
#
# By default Elasticsearch listens for HTTP traffic on the first free port it
# finds starting at 9200. Set a specific HTTP port here:
#
http.port: 1002
#集群之间通信的tcp端口
transport.port: 9302
discovery.seed_hosts: ["localhost:9301"]
#
# For more information, consult the network module documentation.
#
# --------------------------------- Discovery ----------------------------------
#
# Pass an initial list of hosts to perform discovery when this node is started:
# The default list of hosts is ["127.0.0.1", "[::1]"]
#
#discovery.seed_hosts: ["localhost:1001"]
#
# Bootstrap the cluster using an initial set of master-eligible nodes:
#
#cluster.initial_master_nodes: ["node-1001"]
#
# For more information, consult the discovery and cluster formation module documentation.
#
# ---------------------------------- Various -----------------------------------
#
# Allow wildcard deletion of indices:
#
#action.destructive_requires_name: false
#----------------------- BEGIN SECURITY AUTO CONFIGURATION -----------------------
#
# The following settings, TLS certificates, and keys have been automatically
# generated to configure Elasticsearch security features on 27-03-2022 08:14:12
#
# --------------------------------------------------------------------------------
# Enable security features
xpack.security.enabled: false
xpack.security.enrollment.enabled: true
# Enable encryption for HTTP API client connections, such as Kibana, Logstash, and Agents
xpack.security.http.ssl:
enabled: false
keystore.path: certs/http.p12
# Enable encryption and mutual authentication between cluster nodes
xpack.security.transport.ssl:
enabled: true
verification_mode: certificate
keystore.path: certs/transport.p12
truststore.path: certs/transport.p12
# Create a new cluster with the current node only
# Additional nodes can still join the cluster later
# Allow HTTP API connections from localhost and local networks
# Connections are encrypted and require user authentication
http.host: [_local_, _site_]
# Allow other nodes to join the cluster from localhost and local networks
# Connections are encrypted and mutually authenticated
#transport.host: [_local_, _site_]
http.cors.enabled: true
http.cors.allow-origin: "*"
#----------------------- END SECURITY AUTO CONFIGURATION -------------------------
此时我们依然访问节点1001：http://localhost:1001/_cluster/health 查看集群状态：
发现我们节点数量和数据节点数量变为2。
2.3 节点node-1003
按照节点2的方法如法炮制：唯一不同的是：需要发现节点有两个
discovery.seed_hosts: ["localhost:9301","localhost:9302"]
发现我们节点数量和数据节点数量变为3。
Linux部署
# 解压缩
tar -zxvf elasticsearch-7.8.0-linux-x86_64.tar.gz -C /opt/module
# 改名
mv elasticsearch-7.8.0 es
vim /etc/security/limits.conf
# 在文件末尾中增加下面内容
# 每个进程可以打开的文件数的限制
elastic soft nofile 65536
elastic hard nofile 65536
elastic soft nproc 65536
elastic hard nproc 65536
修改/etc/security/limits.d/20-nproc.conf
# 在文件末尾中增加下面内容
# 每个进程可以打开的文件数的限制
es soft nofile 65536
es hard nofile 65536
vim /etc/sysctl.conf
# 添加如下配置
vm.max_map_count=262144
# 执行生效
sysctl -p
useradd es #新增 es 用户
passwd es #为 es 用户设置密码
userdel -r es #如果错了，可以删除再加
chown -R es:es /opt/module/es #文件夹所有者
如果运行不了
修改yml文件
/opt/module/es/config/elasticsearch.yml
xpack.security.enabled: false
xpack.security.enrollment.enabled: false
xpack.security.http.ssl:
enabled: false
keystore.path: certs/http.p12
xpack.security.transport.ssl:
enabled: false
Elasticsearch 进阶
索引
能搜索的数据必须索引，这样的好处是可以提高查询速度，比如：新华字典前面的目录 就是索引的意思，目录可以提高查询速度。
类型（Type）
在一个索引中，你可以定义一种或多种类型。
一个类型是你的索引的一个逻辑上的分类/分区，其语义完全由你来定。通常，会为具
有一组共同字段的文档定义一个类型。不同的版本，类型发生了不同的变化
7版本以上都不支持类型
文档（Document）
一个文档是一个可被索引的基础信息单元，也就是一条数据
字段（Field）
相当于是数据表的字段，对文档数据根据不同属性进行的分类标识
映射（Mapping）
mapping 是处理数据的方式和规则方面做一些限制，如：某个字段的数据类型、默认值、 分析器、是否被索引等等。
分片（Shards）
一个索引可以存储超出单个节点硬件限制的大量数据。比如，一个具有 10 亿文档数据
的索引占据 1TB 的磁盘空间，而任一节点都可能没有这样大的磁盘空间。或者单个节点处
理搜索请求，响应太慢。为了解决这个问题，Elasticsearch 提供了将索引划分成多份的能力，
每一份就称之为分片。当你创建一个索引的时候，你可以指定你想要的分片的数量。每个分
片本身也是一个功能完善并且独立的“索引”，这个“索引”可以被放置到集群中的任何节点
上。
分片很重要，主要有两方面的原因：
1）允许你水平分割 / 扩展你的内容容量。
2）允许你在分片之上进行分布式的、并行的操作，进而提高性能/吞吐量。
至于一个分片怎样分布，它的文档怎样聚合和搜索请求，是完全由 Elasticsearch 管理的，
对于作为用户的你来说，这些都是透明的，无需过分关心。
被混淆的概念是，一个 Lucene 索引 我们在 Elasticsearch 称作 分片 。 一个
Elasticsearch 索引 是分片的集合。 当 Elasticsearch 在索引中搜索的时候， 他发送查询
到每一个属于索引的分片(Lucene 索引)，然后合并每个分片的结果到一个全局的结果集。
副本（Replicas）
在一个网络 / 云的环境里，失败随时都可能发生，在某个分片/节点不知怎么的就处于
离线状态，或者由于任何原因消失了，这种情况下，有一个故障转移机制是非常有用并且是
强烈推荐的。为此目的，Elasticsearch 允许你创建分片的一份或多份拷贝，这些拷贝叫做复
制分片(副本)。
复制分片之所以重要，有两个主要原因：
在分片/节点失败的情况下，提供了高可用性。因为这个原因，注意到复制分片从不与
原/主要（original/primary）分片置于同一节点上是非常重要的。
扩展你的搜索量/吞吐量，因为搜索可以在所有的副本上并行运行。
分配（Allocation）
将分片分配给某个节点的过程，包括分配主分片或者副本。如果是副本，还包含从主分
片复制数据的过程。这个过程是由 master 节点完成的。
系统架构
个运行中的 Elasticsearch 实例称为一个节点，而集群是由一个或者多个拥有相同
cluster.name 配置的节点组成， 它们共同承担数据和负载的压力。当有节点加入集群中或者
从集群中移除节点时，集群将会重新平均分布所有的数据。
当一个节点被选举成为主节点时， 它将负责管理集群范围内的所有变更，例如增加、
删除索引，或者增加、删除节点等。 而主节点并不需要涉及到文档级别的变更和搜索等操
作，所以当集群只拥有一个主节点的情况下，即使流量的增加它也不会成为瓶颈。 任何节
点都可以成为主节点。我们的示例集群就只有一个节点，所以它同时也成为了主节点。
作为用户，我们可以将请求发送到集群中的任何节点 ，包括主节点。 每个节点都知道
任意文档所处的位置，并且能够将我们的请求直接转发到存储我们所需文档的节点。 无论
我们将请求发送到哪个节点，它都能负责从各个包含我们所需文档的节点收集回数据，并将
最终结果返回給客户端。 Elasticsearch 对这一切的管理都是透明的
分布式集群
单节点集群
发送 请求 http://localhst:1001/users
{
"settings" : {
"number_of_shards" : 3,
"number_of_replicas" : 1
}
}
我们的集群现在是拥有一个索引的单节点集群。所有 3 个主分片都被分配在 node-1 。
故障转移
当集群中只有一个节点在运行时，意味着会有一个单点故障问题——没有冗余。 幸运
的是，我们只需再启动一个节点即可防止数据丢失。当你在同一台机器上启动了第二个节点
时，只要它和第一个节点有同样的 cluster.name 配置，它就会自动发现集群并加入到其中。
但是在不同机器上启动节点的时候，为了加入到同一集群，你需要配置一个可连接到的单播
主机列表。之所以配置为使用单播发现，以防止节点无意中加入集群。只有在同一台机器上
运行的节点才会自动组成集群。
水平扩容
但是如果我们想要扩容超过 6 个节点怎么办呢？
主分片的数目在索引创建时就已经确定了下来。实际上，这个数目定义了这个索引能够
存储 的最大数据量。（实际大小取决于你的数据、硬件和使用场景。） 但是，读操作——
搜索和返回数据——可以同时被主分片 或 副本分片所处理，所以当你拥有越多的副本分片
时，也将拥有越高的吞吐量。
在运行中的集群上是可以动态调整副本分片数目的，我们可以按需伸缩集群。让我们把
副本数从默认的 1 增加到 2
调整副本数量
{
"number_of_replicas" : 2
}
应对故障
我们关闭第一个节点，这时集群的状态为:关闭了一个节点后的集群。
我们关闭的节点是一个主节点。而集群必须拥有一个主节点来保证正常工作，所以发生
的第一件事情就是选举一个新的主节点： Node 2 。在我们关闭 Node 1 的同时也失去了主
分片 1 和 2 ，并且在缺失主分片的时候索引也不能正常工作。 如果此时来检查集群的状况，我们看到的状态将会为 red ：不是所有主分片都在正常工作。
幸运的是，在其它节点上存在着这两个主分片的完整副本， 所以新的主节点立即将这
些分片在 Node 2 和 Node 3 上对应的副本分片提升为主分片， 此时集群的状态将会为
yellow。这个提升主分片的过程是瞬间发生的，如同按下一个开关一般。
为什么我们集群状态是 yellow 而不是 green 呢？
虽然我们拥有所有的三个主分片，但是同时设置了每个主分片需要对应 2 份副本分片，而此
时只存在一份副本分片。 所以集群不能为 green 的状态，不过我们不必过于担心：如果我
们同样关闭了 Node 2 ，我们的程序 依然 可以保持在不丢任何数据的情况下运行，因为
Node 3 为每一个分片都保留着一份副本。
如果我们重新启动 Node 1 ，集群可以将缺失的副本分片再次进行分配，那么集群的状
态也将恢复成之前的状态。 如果 Node 1 依然拥有着之前的分片，它将尝试去重用它们，
同时仅从主分片复制发生了修改的数据文件。和之前的集群相比，只是 Master 节点切换了。
路由计算
当索引一个文档的时候，文档会被存储到一个主分片中。 Elasticsearch 如何知道一个
文档应该存放到哪个分片中呢？当我们创建文档时，它如何决定这个文档应当被存储在分片
1 还是分片 2 中呢？首先这肯定不会是随机的，否则将来要获取文档的时候我们就不知道
从何处寻找了。实际上，这个过程是根据下面这个公式决定的：
routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。 routing 通过
hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）
后得到余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。
这就解释了为什么我们要在创建索引的时候就确定好主分片的数量 并且永远不会改变这个数量：因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。所有的文档 API（ get 、 index 、 delete 、 bulk 、 update 以及 mget ）都接受一
个叫做 routing 的路由参数 ，通过这个参数我们可以自定义文档到分片的映射。一个自定义的路由参数可以用来确保所有相关的文档——例如所有属于同一个用户的文档——都被存储到同一个分片中。
分片控制：用户可以访问任何一个节点获取数据，这个节点叫协调节点
客户端请求集群节点
协调接地那
协调节点请求转换到孩子定节点
主分片需要将数据保存
主分片将数据发送给副本
副本保存后进行反馈
客户端获取反馈
客户端发送查询请求到协调节点
协调节点计算数据所在分片以及全部的副本位置
为了能够负载均衡，可以轮训所有节点
将请求转发给具体节点
节点返回查询结果，将结果反馈给客户端
延时：主分片延时+并行写入副本最大延时
分片控制
我们假设有一个集群由三个节点组成。 它包含一个叫 emps 的索引，有两个主分片， 每个主分片有两个副本分片。相同分片的副本不会放在同一节点。
通过 elasticsearch-head 插件查看集群情况，所以我们的集群是一个有三个节点和一个索 引的集群。
我们可以发送请求到集群中的任一节点。 每个节点都有能力处理任意请求。 每个节点都知 道集群中任一文档位置，所以可以直接将请求转发到需要的节点上。 在下面的例子中，将 所有的请求发送到 Node 1，我们将其称为 协调节点(coordinating node) 。
当发送请求的时候， 为了扩展负载，更好的做法是轮询集群中所有的节点。
写流程
新建、索引和删除 请求都是 写 操作， 必须在主分片上面完成之后才能被复制到相关 的副本分片
新建，索引和删除文档所需要的步骤顺序：
1. 客户端向 Node 1 发送新建、索引或者删除请求。
2. 节点使用文档的 _id 确定文档属于分片 0 。请求会被转发到 Node 3，因为分片 0 的
主分片目前被分配在 Node 3 上。
3. Node 3 在主分片上面执行请求。如果成功了，它将请求并行转发到 Node 1 和 Node 2
的副本分片上。一旦所有的副本分片都报告成功, Node 3 将向协调节点报告成功，协调
节点向客户端报告成功。
在客户端收到成功响应时，文档变更已经在主分片和所有副本分片执行完成，变更是安全的。
有一些可选的请求参数允许您影响这个过程，可能以数据安全为代价提升性能。这些选项很
少使用，因为 Elasticsearch 已经很快，但是为了完整起见，请参考下面表格：
新索引默认有 1 个副本分片，这意味着为满足规定数量应该需要两个活动的分片副本。 但是，这些 默认的设置会阻止我们在单一节点上做任何事情。为了避免这个问题，要求只有当 number_of_replicas 大 于 1 的时候，规定数量才会执行。
读流程
我们可以从主分片或者从其它任意副本分片检索文档
从主分片或者副本分片检索文档的步骤顺序：
1. 客户端向 Node 1 发送获取请求。
2. 节点使用文档的 _id 来确定文档属于分片 0 。分片 0 的副本分片存在于所有的三个
节点上。 在这种情况下，它将请求转发到 Node 2 。
3. Node 2 将文档返回给 Node 1 ，然后将文档返回给客户端。
在处理读取请求时，协调结点在每次请求的时候都会通过轮询所有的副本分片来达到负载均
衡。在文档被检索时，已经被索引的文档可能已经存在于主分片上但是还没有复制到副本分
片。 在这种情况下，副本分片可能会报告文档不存在，但是主分片可能成功返回文档。 一
旦索引请求成功返回给用户，文档在主分片和副本分片都是可用的。
更新流程
部分更新一个文档结合了先前说明的读取和写入流程
部分更新一个文档的步骤如下：
1. 客户端向 Node 1 发送更新请求。
2. 它将请求转发到主分片所在的 Node 3 。
3. Node 3 从主分片检索文档，修改 _source 字段中的 JSON ，并且尝试重新索引主分片
的文档。如果文档已经被另一个进程修改，它会重试步骤 3 ，超过 retry_on_conflict 次
后放弃。
4. 如果 Node 3 成功地更新文档，它将新版本的文档并行转发到 Node 1 和 Node 2 上的
副本分片，重新建立索引。一旦所有副本分片都返回成功， Node 3 向协调节点也返回
成功，协调节点向客户端返回成功。
当主分片把更改转发到副本分片时， 它不会转发更新请求。 相反，它转发完整文档的新版本。请记住，
这些更改将会异步转发到副本分片，并且不能保证它们以发送它们相同的顺序到达。 如果 Elasticsearch 仅
转发更改请求，则可能以错误的顺序应用更改，导致得到损坏的文档。
多文档操作流程
mget 和 bulk API 的模式类似于单文档模式。区别在于协调节点知道每个文档存在于
哪个分片中。它将整个多文档请求分解成 每个分片 的多文档请求，并且将这些请求并行转
发到每个参与节点。
协调节点一旦收到来自每个节点的应答，就将每个节点的响应收集整理成单个响应，返
回给客户端
用单个 mget 请求取回多个文档所需的步骤顺序
1. 客户端向 Node 1 发送 mget 请求。
2. Node 1 为每个分片构建多文档获取请求，然后并行转发这些请求到托管在每个所需的
主分片或者副本分片的节点上。一旦收到所有答复， Node 1 构建响应并将其返回给客
户端。
bulk API， 允许在单个批量请求中执行多个创建、索引、删除和更新请求。
bulk API 按如下步骤顺序执行：
1. 客户端向 Node 1 发送 bulk 请求。
2. Node 1 为每个节点创建一个批量请求，并将这些请求并行转发到每个包含主分片的节
点主机。
3. 主分片一个接一个按顺序执行每个操作。当每个操作成功时，主分片并行转发新文档（或
删除）到副本分片，然后执行下一个操作。 一旦所有的副本分片报告所有操作成功，
该节点将向协调节点报告成功，协调节点将这些响应收集整理并返回给客户端。
分片原理
分片是 Elasticsearch 最小的工作单元。但是究竟什么是一个分片，它是如何工作的？
传统的数据库每个字段存储单个值，但这对全文检索并不够。文本字段中的每个单词需
要被搜索，对数据库意味着需要单个字段有索引多值的能力。最好的支持是一个字段多个值
需求的数据结构是倒排索引。
倒排索引
Elasticsearch 使用一种称为倒排索引的结构，它适用于快速的全文搜索。
见其名，知其意，有倒排索引，肯定会对应有正向索引。正向索引（forward index），
反向索引（inverted index）更熟悉的名字是倒排索引。
所谓的正向索引，就是搜索引擎会将待搜索的文件都对应一个文件 ID，搜索时将这个
ID 和搜索关键字进行对应，形成 K-V 对，然后对关键字进行统计计数
一个倒排索引由文档中所有不重复词的列表构成，对于其中每个词，有一个包含它的文
档列表。例如，假设我们有两个文档，每个文档的 content 域包含如下内容：
The quick brown fox jumped over the lazy dog
Quick brown foxes leap over lazy dogs in summer
为了创建倒排索引，我们首先将每个文档的 content 域拆分成单独的 词（我们称它为 词条
或 tokens ），创建一个包含所有不重复词条的排序列表，然后列出每个词条出现在哪个文
档。结果如下所示：
现在，如果我们想搜索 quick brown ，我们只需要查找包含每个词条的文档
两个文档都匹配，但是第一个文档比第二个匹配度更高。如果我们使用仅计算匹配词条数量
的简单相似性算法，那么我们可以说，对于我们查询的相关性来讲，第一个文档比第二个文
档更佳。
但是，我们目前的倒排索引有一些问题：
Quick 和 quick 以独立的词条出现，然而用户可能认为它们是相同的词。
fox 和 foxes 非常相似, 就像 dog 和 dogs ；他们有相同的词根。
jumped 和 leap, 尽管没有相同的词根，但他们的意思很相近。他们是同义词。
使用前面的索引搜索 +Quick +fox 不会得到任何匹配文档。（记住，+ 前缀表明这个词必
须存在。）只有同时出现 Quick 和 fox 的文档才满足这个查询条件，但是第一个文档包含
quick fox ，第二个文档包含 Quick foxes 。
我们的用户可以合理的期望两个文档与查询匹配。我们可以做的更好。
如果我们将词条规范为标准模式，那么我们可以找到与用户搜索的词条不完全一致，但具有
足够相关性的文档。例如：
Quick 可以小写化为 quick 。
foxes 可以 词干提取 --变为词根的格式-- 为 fox 。类似的， dogs 可以为提取为 dog 。
jumped 和 leap 是同义词，可以索引为相同的单词 jump 。
现在索引看上去像这样：
这还远远不够。我们搜索 +Quick +fox 仍然 会失败，因为在我们的索引中，已经没有 Quick
了。但是，如果我们对搜索的字符串使用与 content 域相同的标准化规则，会变成查询
+quick +fox，这样两个文档都会匹配！分词和标准化的过程称为分析
文档搜索
早期的全文检索会为整个文档集合建立一个很大的倒排索引并将其写入到磁盘。 一旦
新的索引就绪，旧的就会被其替换，这样最近的变化便可以被检索到。
倒排索引被写入磁盘后是 不可改变 的:它永远不会修改。
不变性有重要的价值：
不需要锁。如果你从来不更新索引，你就不需要担心多进程同时修改数据的问题。
一旦索引被读入内核的文件系统缓存，便会留在哪里，由于其不变性。只要文件系统缓存中还有足够
的空间，那么大部分读请求会直接请求内存，而不会命中磁盘。这提供了很大的性能提升。
其它缓存(像 filter 缓存)，在索引的生命周期内始终有效。它们不需要在每次数据改变时被重建，因为
数据不会变化。
写入单个大的倒排索引允许数据被压缩，减少磁盘 I/O 和 需要被缓存到内存的索引的使用量。
当然，一个不变的索引也有不好的地方。主要事实是它是不可变的! 你不能修改它。如
果你需要让一个新的文档 可被搜索，你需要重建整个索引。这要么对一个索引所能包含的
数据量造成了很大的限制，要么对索引可被更新的频率造成了很大的限制。
动态更新索引
如何在保留不变性的前提下实现倒排索引的更新？
答案是: 用更多的索引。通过增加新的补充索引来反映新近的修改，而不是直接重写整
个倒排索引。每一个倒排索引都会被轮流查询到，从最早的开始查询完后再对结果进行合并。
Elasticsearch 基于 Lucene, 这个 java 库引入了按段搜索的概念。 每一 段 本身都是一
个倒排索引， 但索引在 Lucene 中除表示所有段的集合外， 还增加了提交点的概念 — 一
个列出了所有已知段的文
按段搜索会以如下流程执行：
1. 新文档被收集到内存索引缓存
2. 不时地, 缓存被 提交
(1) 一个新的段—一个追加的倒排索引—被写入磁盘。
(2) 一个新的包含新段名字的 提交点 被写入磁盘
(3) 磁盘进行 同步 — 所有在文件系统缓存中等待的写入都刷新到磁盘，以确保它们
被写入物理文件
3. 新的段被开启，让它包含的文档可见以被搜索
4. 内存缓存被清空，等待接收新的文档
当一个查询被触发，所有已知的段按顺序被查询。词项统计会对所有段的结果进行聚合，以
保证每个词和每个文档的关联都被准确计算。 这种方式可以用相对较低的成本将新文档添
加到索引。
段是不可改变的，所以既不能从把文档从旧的段中移除，也不能修改旧的段来进行反映文档
的更新。 取而代之的是，每个提交点会包含一个 .del 文件，文件中会列出这些被删除文档
的段信息。
当一个文档被 “删除” 时，它实际上只是在 .del 文件中被 标记 删除。一个被标记删除的
文档仍然可以被查询匹配到， 但它会在最终结果被返回前从结果集中移除。
文档更新也是类似的操作方式：当一个文档被更新时，旧版本文档被标记删除，文档的新版
本被索引到一个新的段中。 可能两个版本的文档都会被一个查询匹配到，但被删除的那个
旧版本文档在结果集返回前就已经被移除。
近实时搜索
随着按段（per-segment）搜索的发展，一个新的文档从索引到可被搜索的延迟显著降低了。新文档在几分钟之内即可被检索，但这样还是不够快。磁盘在这里成为了瓶颈。提交（Commiting）一个新的段到磁盘需要一个 fsync 来确保段被物理性地写入磁盘，这样在断
电的时候就不会丢失数据。 但是 fsync 操作代价很大; 如果每次索引一个文档都去执行一次的话会造成很大的性能问题。
我们需要的是一个更轻量的方式来使一个文档可被搜索，这意味着 fsync 要从整个过程中被移除。在 Elasticsearch 和磁盘之间是文件系统缓存。 像之前描述的一样， 在内存索引缓
冲区中的文档会被写入到一个新的段中。 但是这里新段会被先写入到文件系统缓存—这一步代价会比较低，稍后再被刷新到磁盘—这一步代价比较高。不过只要文件已经在缓存中，就可以像其它文件一样被打开和读取了。
在 Elasticsearch 中，写入和打开一个新段的轻量的过程叫做 refresh 。 默认情况下每个分片会每秒自动刷新一次。这就是为什么我们说 Elasticsearch 是 近 实时搜索: 文档的变化
并不是立即对搜索可见，但会在一秒之内变为可见。这些行为可能会对新用户造成困惑: 他们索引了一个文档然后尝试搜索它，但却没有搜到。这个问题的解决办法是用 refresh API 执行一次手动刷新: /users/_refresh尽管刷新是比提交轻量很多的操作，它还是会有性能开销。当写测试的时候， 手动刷新很有用，但是不要在生产环境下每次索引一个文档都去手动刷新。 相反，你的应用需要意识到 Elasticsearch 的近实时的性质，并接受它的不足。
并不是所有的情况都需要每秒刷新。可能你正在使用 Elasticsearch 索引大量的日志文件，你可能想优化索引速度而不是近实时搜索， 可以通过设置 refresh_interval ， 降低每个索引的刷新频率
{
"settings": {
"refresh_interval": "30s"
}
}
refresh_interval 可以在既存索引上进行动态更新。 在生产环境中，当你正在建立一个大的 新索引时，可以先关闭自动刷新，待开始使用该索引时，再把它们调回来
# 关闭自动刷新
PUT /users/_settings
{ "refresh_interval": -1 }
# 每一秒刷新
PUT /users/_settings
{ "refresh_interval": "1s" }
持久化变更
如果没有用 fsync 把数据从文件系统缓存刷（flush）到硬盘，我们不能保证数据在断
电甚至是程序正常退出之后依然存在。为了保证 Elasticsearch 的可靠性，需要确保数据变
化被持久化到磁盘。在 动态更新索引，我们说一次完整的提交会将段刷到磁盘，并写入一个包含所有段列表的提交点。Elasticsearch 在启动或重新打开一个索引的过程中使用这个提
交点来判断哪些段隶属于当前分片。
即使通过每秒刷新（refresh）实现了近实时搜索，我们仍然需要经常进行完整提交来确
保能从失败中恢复。但在两次提交之间发生变化的文档怎么办？我们也不希望丢失掉这些数
据。Elasticsearch 增加了一个 translog ，或者叫事务日志，在每一次对 Elasticsearch 进行
操作时均进行了日志记录
整个流程如下：
1. 一个文档被索引之后，就会被添加到内存缓冲区，并且追加到了 translog
2. 刷新（refresh）使分片每秒被刷新（refresh）一次：
这些在内存缓冲区的文档被写入到一个新的段中，且没有进行 fsync 操作。
这个段被打开，使其可被搜索
内存缓冲区被清空
3. 这个进程继续工作，更多的文档被添加到内存缓冲区和追加到事务日志
4. 每隔一段时间—例如 translog 变得越来越大—索引被刷新（flush）；一个新的 translog
被创建，并且一个全量提交被执行
所有在内存缓冲区的文档都被写入一个新的段。
缓冲区被清空。
一个提交点被写入硬盘。
文件系统缓存通过 fsync 被刷新（flush）。
老的 translog 被删除。
translog 提供所有还没有被刷到磁盘的操作的一个持久化纪录。当 Elasticsearch 启动的时
候， 它会从磁盘中使用最后一个提交点去恢复已知的段，并且会重放 translog 中所有在最
后一次提交后发生的变更操作。
translog 也被用来提供实时 CRUD 。当你试着通过 ID 查询、更新、删除一个文档，它会
在尝试从相应的段中检索之前， 首先检查 translog 任何最近的变更。这意味着它总是能够
实时地获取到文档的最新版本。
你很少需要自己手动执行 flush 操作；通常情况下，自动刷新就足够了。这就是说，在重启节点或关闭索引之前执行 flush 有益于你的索引。当 Elasticsearch 尝试恢复或重新打开一个索引， 它需要重放 translog 中所有的操作，所以如果日志越短，恢复越快。
translog 的目的是保证操作不会丢失，在文件被 fsync 到磁盘前，被写入的文件在重启之后就会丢失。默认 translog 是每 5 秒被 fsync 刷新到硬盘， 或者在每次写请求完成之
后执行(e.g. index, delete, update, bulk)。这个过程在主分片和复制分片都会发生。最终， 基本上，这意味着在整个请求被 fsync 到主分片和复制分片的 translog 之前，你的客户端不会
得到一个 200 OK 响应。在每次请求后都执行一个 fsync 会带来一些性能损失，尽管实践表明这种损失相对较小（特别是 bulk 导入，它在一次请求中平摊了大量文档的开销）。
但是对于一些大容量的偶尔丢失几秒数据问题也并不严重的集群，使用异步的 fsync 还是比较有益的。比如，写入的数据被缓存到内存中，再每 5 秒执行一次 fsync 。如果你决定使用异步 translog 的话，你需要 保证 在发生 crash 时，丢失掉 sync_interval 时间段
的数据也无所谓。请在决定前知晓这个特性。如果你不确定这个行为的后果，最好是使用默认的参数（ "index.translog.durability": "request" ）来避免数据丢失。
段合并
由于自动刷新流程每秒会创建一个新的段 ，这样会导致短时间内的段数量暴增。而段
数目太多会带来较大的麻烦。 每一个段都会消耗文件句柄、内存和 cpu 运行周期。更重要
的是，每个搜索请求都必须轮流检查每个段；所以段越多，搜索也就越慢。
Elasticsearch 通过在后台进行段合并来解决这个问题。小的段被合并到大的段，然后这些大
的段再被合并到更大的段。
段合并的时候会将那些旧的已删除文档从文件系统中清除。被删除的文档（或被更新文档的
旧版本）不会被拷贝到新的大段中。
启动段合并不需要你做任何事。进行索引和搜索时会自动进行。
1. 当索引的时候，刷新（refresh）操作会创建新的段并将段打开以供搜索使用。
2. 合并进程选择一小部分大小相似的段，并且在后台将它们合并到更大的段中。这并不会
中断索引和搜索
3. 一旦合并结束，老的段被删除
新的段被刷新（flush）到了磁盘。 ** 写入一个包含新段且排除旧的和较小的段
的新提交点。
新的段被打开用来搜索。
老的段被删除。
合并大的段需要消耗大量的 I/O 和 CPU 资源，如果任其发展会影响搜索性能。Elasticsearch 在默认情况下会对合并流程进行资源限制，所以搜索仍然 有足够的资源很好地执行。
文档分析
分析 包含下面的过程：
将一块文本分成适合于倒排索引的独立的 词条
将这些词条统一化为标准格式以提高它们的“可搜索性”，或者 recall
分析器执行上面的工作。分析器实际上是将三个功能封装到了一个包里：
字符过滤器
首先，字符串按顺序通过每个 字符过滤器 。他们的任务是在分词前整理字符串。一个
字符过滤器可以用来去掉 HTML，或者将 & 转化成 and。
分词器
其次，字符串被 分词器 分为单个的词条。一个简单的分词器遇到空格和标点的时候，
可能会将文本拆分成词条。
Token 过滤器
最后，词条按顺序通过每个 token 过滤器 。这个过程可能会改变词条（例如，小写化
Quick ），删除词条（例如， 像 a， and， the 等无用词），或者增加词条（例如，像 jump
和 leap 这种同义词）。
内置分析器
"Set the shape to semi-transparent by calling set_trans(5)"
标准分析器
标准分析器是 Elasticsearch 默认使用的分析器。它是分析各种语言文本最常用的选择。
它根据 Unicode 联盟 定义的 单词边界 划分文本。删除绝大部分标点。最后，将词条小写。
它会产生：
set, the, shape, to, semi, transparent, by, calling, set_trans, 5
简单分析器
简单分析器在任何不是字母的地方分隔文本，将词条小写。它会产生：
set, the, shape, to, semi, transparent, by, calling, set, trans
空格分析器
空格分析器在空格的地方划分文本。它会产生：
Set, the, shape, to, semi-transparent, by, calling, set_trans(5)
语言分析器
特定语言分析器可用于 很多语言。它们可以考虑指定语言的特点。例如， 英语 分析
器附带了一组英语无用词（常用单词，例如 and 或者 the ，它们对相关性没有多少影响），
它们会被删除。 由于理解英语语法的规则，这个分词器可以提取英语单词的 词干 。
英语 分词器会产生下面的词条：
set, shape, semi, transpar, call, set_tran, 5
注意看 transparent、 calling 和 set_trans 已经变为词根格式
分析器使用场景
当我们 索引 一个文档，它的全文域被分析成词条以用来创建倒排索引。 但是，当我
们在全文域 搜索 的时候，我们需要将查询字符串通过 相同的分析过程 ，以保证我们搜索
的词条格式与索引中的词条格式一致
全文查询，理解每个域是如何定义的，因此它们可以做正确的事：
当你查询一个 全文 域时， 会对查询字符串应用相同的分析器，以产生正确的搜
索词条列表。
当你查询一个 精确值 域时，不会分析查询字符串，而是搜索你指定的精确值。
测试分析器
有些时候很难理解分词的过程和实际被存储到索引中的词条，特别是你刚接触
Elasticsearch。为了理解发生了什么，你可以使用 analyze API 来看文本是如何被分析的。
在消息体里，指定分析器和要分析的文本
GET http://localhost:9200/_analyze
{
"analyzer": "standard",
"text": "Text to analyze"
}
结果中每个元素代表一个单独的词条：
{
"tokens": [
{
"token": "text",
"start_offset": 0,
"end_offset": 4,
"type": "<ALPHANUM>",
"position": 1
},
{
"token": "to",
"start_offset": 5,
"end_offset": 7,
"type": "<ALPHANUM>",
"position": 2
},
{
"token": "analyze",
"start_offset": 8,
"end_offset": 15,
"type": "<ALPHANUM>",
"position": 3
}
]
}
token 是实际存储到索引中的词条。 position 指明词条在原始文本中出现的位置。
start_offset 和 end_offset 指明字符在原始字符串中的位置。
4.7.4 指定分析器
当Elasticsearch在你的文档中检测到一个新的字符串域，它会自动设置其为一个全文 字
符串 域，使用 标准 分析器对它进行分析。你不希望总是这样。可能你想使用一个不同的
分析器，适用于你的数据使用的语言。有时候你想要一个字符串域就是一个字符串域—不使用分析，直接索引你传入的精确值，例如用户 ID 或者一个内部的状态域或标签。要做到这
一点，我们必须手动指定这些域的映射。
IK 分词器
首先我们通过 Postman 发送 GET 请求查询分词效果
# GET http://localhost:9200/_analyze
{
"text":"测试单词"
}
ES 的默认分词器无法识别中文中测试、单词这样的词汇，而是简单的将每个字拆完分为一
个词
{
"tokens": [
{
"token": "测",
"start_offset": 0,
"end_offset": 1,
"type": "<IDEOGRAPHIC>",
"position": 0
},
{
"token": "试",
"start_offset": 1,
"end_offset": 2,
"type": "<IDEOGRAPHIC>",
"position": 1
},
{
"token": "单",
"start_offset": 2,
"end_offset": 3,
"type": "<IDEOGRAPHIC>",
"position": 2
},
{
"token": "词",
"start_offset": 3,
"end_offset": 4,
"type": "<IDEOGRAPHIC>",
"position": 3
}
]
}
这样的结果显然不符合我们的使用要求，所以我们需要下载 ES 对应版本的中文分词器
# GET http://localhost:9200/_analyze { "text":"测试单词", "analyzer":"ik_max_word" }
ik_max_word：会将文本做最细粒度的拆分
ik_smart：会将文本做最粗粒度的拆分
使用中文分词后的结果为：
{
"tokens": [
{
"token": "测试",
"start_offset": 0,
"end_offset": 2,
"type": "CN_WORD",
"position": 0
},
{
"token": "单词",
"start_offset": 2,
"end_offset": 4,
"type": "CN_WORD",
"position": 1
}
]
}
ES 中也可以进行扩展词汇，首先查询
# GET http://localhost:9200/_analyze
{
"text":"弗雷尔卓德",
"analyzer":"ik_max_word"
}
仅仅可以得到每个字的分词结果，我们需要做的就是使分词器识别到弗雷尔卓德也是一个词
语
{
"tokens": [
{
"token": "弗",
"start_offset": 0,
"end_offset": 1,
"type": "CN_CHAR",
"position": 0
},
{
"token": "雷",
"start_offset": 1,
"end_offset": 2,
"type": "CN_CHAR",
"position": 1
},
{
"token": "尔",
"start_offset": 2,
"end_offset": 3,
"type": "CN_CHAR",
"position": 2
},
{
"token": "卓",
"start_offset": 3,
"end_offset": 4,
"type": "CN_CHAR",
"position": 3
},
{
"token": "德",
"start_offset": 4,
"end_offset": 5,
"type": "CN_CHAR",
"position": 4
}
]
}
首先进入 ES 根目录中的 plugins 文件夹下的 ik 文件夹，进入 config 目录，创建 custom.dic
文件，写入弗雷尔卓德。同时打开 IKAnalyzer.cfg.xml 文件，将新建的 custom.dic 配置其中，
重启 ES 服务器
自定义分析器
虽然 Elasticsearch 带有一些现成的分析器，然而在分析器上 Elasticsearch 真正的强大之
处在于，你可以通过在一个适合你的特定数据的设置之中组合字符过滤器、分词器、词汇单
元过滤器来创建自定义的分析器。在 分析与分析器 我们说过，一个 分析器 就是在一个包
里面组合了三种函数的一个包装器， 三种函数按照顺序被执行:
字符过滤器
字符过滤器 用来 整理 一个尚未被分词的字符串。例如，如果我们的文本是 HTML 格
式的，它会包含像 <p> 或者 <div> 这样的 HTML 标签，这些标签是我们不想索引的。我
们可以使用 html 清除 字符过滤器 来移除掉所有的 HTML 标签，并且像把 Á 转换
为相对应的 Unicode 字符 Á 这样，转换 HTML 实体。一个分析器可能有 0 个或者多个字符
过滤器。
分词器
一个分析器 必须 有一个唯一的分词器。 分词器把字符串分解成单个词条或者词汇单
元。 标准 分析器里使用的 标准 分词器 把一个字符串根据单词边界分解成单个词条，并
且移除掉大部分的标点符号，然而还有其他不同行为的分词器存在。
例如， 关键词 分词器 完整地输出 接收到的同样的字符串，并不做任何分词。 空格 分词
器 只根据空格分割文本 。 正则 分词器 根据匹配正则表达式来分割文本 。
词单元过滤器
经过分词，作为结果的 词单元流 会按照指定的顺序通过指定的词单元过滤器 。
词单元过滤器可以修改、添加或者移除词单元。我们已经提到过 lowercase 和 stop 词过滤
器 ，但是在 Elasticsearch 里面还有很多可供选择的词单元过滤器。词干过滤器 把单词 遏
制 为 词干。 ascii_folding 过滤器移除变音符，把一个像 "très" 这样的词转换为 "tres" 。ngram 和 edge_ngram 词单元过滤器 可以产生 适合用于部分匹配或者自动补全的词单元。
接下来，我们看看如何创建自定义的分析器：
# PUT http://localhost:9200/my_index
{
"settings": {
"analysis": {
"char_filter": {
"&_to_and": {
"type": "mapping",
"mappings": [ "&=> and "]
}},
"filter": {
"my_stopwords": {
"type": "stop",
"stopwords": [ "the", "a" ]
}},
"analyzer": {
"my_analyzer": {
"type": "custom",
"char_filter": [ "html_strip", "&_to_and" ],
"tokenizer": "standard",
"filter": [ "lowercase", "my_stopwords" ]
}}
}}}
索引被创建以后，使用 analyze API 来 测试这个新的分析器
# GET http://127.0.0.1:9200/my_index/_analyze
{
"text":"The quick & brown fox",
"analyzer": "my_analyzer"
}
下面的缩略结果展示出我们的分析器正在正确地运行
{
"tokens": [
{
"token": "quick",
"start_offset": 4,
"end_offset": 9,
"type": "<ALPHANUM>",
"position": 1
},
{
"token": "and",
"start_offset": 10,
"end_offset": 11,
"type": "<ALPHANUM>",
"position": 2
},
{
"token": "brown",
"start_offset": 12,
"end_offset": 17,
"type": "<ALPHANUM>",
"position": 3
},
{
"token": "fox",
"start_offset": 18,
"end_offset": 21,
"type": "<ALPHANUM>",
"position": 4
}
]
}
文档处理
当我们使用 index API 更新文档 ，可以一次性读取原始文档，做我们的修改，然后重
新索引 整个文档 。 最近的索引请求将获胜：无论最后哪一个文档被索引，都将被唯一存
储在 Elasticsearch 中。如果其他人同时更改这个文档，他们的更改将丢失。
很多时候这是没有问题的。也许我们的主数据存储是一个关系型数据库，我们只是将数
据复制到 Elasticsearch 中并使其可被搜索。 也许两个人同时更改相同的文档的几率很小。
或者对于我们的业务来说偶尔丢失更改并不是很严重的问题。
但有时丢失了一个变更就是 非常严重的 。试想我们使用 Elasticsearch 存储我们网上
商城商品库存的数量， 每次我们卖一个商品的时候，我们在 Elasticsearch 中将库存数量减
少。有一天，管理层决定做一次促销。突然地，我们一秒要卖好几个商品。 假设有两个 web
程序并行运行，每一个都同时处理所有商品的销售web_1 对 stock_count 所做的更改已经丢失，因为 web_2 不知道它的 stock_count 的
拷贝已经过期。 结果我们会认为有超过商品的实际数量的库存，因为卖给顾客的库存商品
并不存在，我们将让他们非常失望。
变更越频繁，读数据和更新数据的间隙越长，也就越可能丢失变更。
在数据库领域中，有两种方法通常被用来确保并发更新时变更不会丢失：
悲观并发控制
这种方法被关系型数据库广泛使用，它假定有变更冲突可能发生，因此阻塞访问资源以
防止冲突。 一个典型的例子是读取一行数据之前先将其锁住，确保只有放置锁的线程能够
对这行数据进行修改
乐观并发控制
Elasticsearch 中使用的这种方法假定冲突是不可能发生的，并且不会阻塞正在尝试的操
作。 然而，如果源数据在读写当中被修改，更新将会失败。应用程序接下来将决定该如何
解决冲突。 例如，可以重试更新、使用新的数据、或者将相关情况报告给用户。
乐观并发控制
Elasticsearch 是分布式的。当文档创建、更新或删除时， 新版本的文档必须复制到集
群中的其他节点。Elasticsearch 也是异步和并发的，这意味着这些复制请求被并行发送，并
且到达目的地时也许 顺序是乱的 。 Elasticsearch 需要一种方法确保文档的旧版本不会覆
盖新的版本。
当我们之前讨论 index ，GET 和 delete 请求时，我们指出每个文档都有一个 _version
（版本）号，当文档被修改时版本号递增。 Elasticsearch 使用这个 version 号来确保变更
以正确顺序得到执行。如果旧版本的文档在新版本之后到达，它可以被简单的忽略。
我们可以利用 version 号来确保 应用中相互冲突的变更不会导致数据丢失。我们通过
指定想要修改文档的 version 号来达到这个目的。 如果该版本不是当前版本号，我们的请
求将会失败。
老的版本 es 使用 version，但是新版本不支持了，会报下面的错误，提示我们用 if_seq_no
和 if_primary_term
{
"error": {
"root_cause": [
{
"type": "action_request_validation_exception",
"reason": "Validation Failed: 1: internal versioning can not be used
for optimistic concurrency control. Please use `if_seq_no` and `if_primary_term`
instead;"
}
],
"type": "action_request_validation_exception",
"reason": "Validation Failed: 1: internal versioning can not be used for
optimistic concurrency control. Please use `if_seq_no` and `if_primary_term`
instead;"
},
"status": 400
}
标签：index,索引,文档,分片,Elasticsearch,节点 来源： https://www.cnblogs.com/abldh12/p/16652156.html