ES7.x小记
ES学习小记
- ES与MYSQL基本概念对比
- ES核心概念
-
- 映射Mapping
- 分片Shards
- 副本Replicas
- 分配Allocation
- ES中倒排索引
- 常用接口
-
- PUT和POST请求的区别
- 创建/查看/删除index
- 查看所有index
- 创建随机id的doc（一条数据）
- 操作自定义id的doc
- 查找索引下所有数据
- 请求体带参数查询
- 全文检索 & 完全匹配 & 高亮查询
- 聚合查询
- 映射关系-mapping
- ES集群架构
- 集群测试
-
- 安装es head插件
- 创建一个3个分片，1个副本的索引
- 扩容节点
- 动态调整副本数
- 故障模拟--干掉1个节点
- 路由计算
- 数据写流程
- 数据读流程
- 更新流程
- 批量操作流程
-
- 用单个 mget 请求获取多个文档
- 用bulk API 在单个批量请求中执行多个创建、索引、删除和更新请求
- 文档搜索
-
- 不可改变的倒排索引
- 动态更新索引
- 文档刷新-刷写-合并
-
- 近实时搜索
- 段合并
- 文档分析
-
- 分析器的作用
- 默认分析器
- IK中文分析器
-
- IK分析器参数：
- 自定义IK分析器词汇
- 自定义分词器
- 文档控制
-
- 悲观锁
- 乐观锁ES
- 优化参考
-
- 硬件
- 分片策略
-
- 合理设置分片数
- 延迟分片分配
- 路由策略
- 写入速度优化
- 合理使用合并
- 减少 Refresh 的次数
- 加大 Flush 设置
- 减少副本的数量
- 内存设置
- 集群配置
- 参考文档
参考：https://blog.csdn.net/u011863024/article/details/115721328
ES 是一个开源的高扩展的分布式全文搜索引擎
ES与MYSQL基本概念对比
Index（数据库）
Type（表）7.X版本中type概念已经被删除
Document（行，代表一条文档数据）
Fields（字段，对文档数据根据不同属性进行分类标识）
ES核心概念
映射Mapping
处理数据的方式和规则方面做一些限制，如：某个字段的数据类型、默认值、分析器、是否被索引等。
分片Shards
Elasticsearch 提供了将索引划分成多份的能力，每一份就称之为分片。
- 允许你水平分割 / 扩展你的内容容量。
- 允许你在分片之上进行分布式的、并行的操作，进而提高性能/吞吐量。
被混淆的概念是，一个 Lucene 索引 我们在 Elasticsearch 称作 分片 。 一个Elasticsearch 索引 是分片的集合。 当 Elasticsearch 在索引中搜索的时候， 他发送查询到每一个属于索引的分片（Lucene 索引），然后合并每个分片的结果到一个全局的结果集。
副本Replicas
- 在分片/节点失败的情况下，提供了高可用性。因为这个原因，注意到复制分片从不与原/主要（original/primary）分片置于同一节点上是非常重要的。
- 扩展你的搜索量/吞吐量，因为搜索可以在所有的副本上并行运行。
分配Allocation
将分片分配给某个节点的过程，包括分配主分片或者副本。如果是副本，还包含从主分片复制数据的过程。这个过程是由 master 节点完成的。
ES中倒排索引
ES文档分词并使用“倒排索引”存储。
当输入"小明"，ES会自动分为"小"和"明"关键字进行倒排索引的匹配
正排索引如mysql中是通过id找到对应的值
id content
-----------------
101 my name is zhang san
102 my name is li si
而ES中是通过keyword找对应的id
keyword id
-----------------
name 101,102
zhang 101
常用接口
PUT和POST请求的区别
PUT是幂等的：即请求会自动校验数据是否存在。不存在则create
POST请求则每次请求都是create数据，只有指定ID一样的情况下是update
创建/查看/删除index
PUT/GET/DELETE http://127.0.0.1:9200/shopping
查看所有index
GET http://127.0.0.1:9200/_cat/indices?v
创建随机id的doc（一条数据）
POST http://127.0.0.1:9200/shopping/_doc
{
"title":"小米手机",
"category":"小米",
"images":"http://www.gulixueyuan.com/xm.jpg",
"price":3999.00
}
操作自定义id的doc
- 删除一个文档不会立即从磁盘上移除，它只是被标记成已删除（逻辑删除）
- POSX和PUT每次都会删除再创建新数据
GET/POST/PUT/DELETE http://127.0.0.1:9200/shopping/_doc/1
查找索引下所有数据
GET http://127.0.0.1:9200/shopping/_search
请求体带参数查询
GET http://127.0.0.1:9200/shopping/_search
查询category字段包含关键字小米
{
"query":{
"match":{
"category":"小米"
}
}
}
查询所有数据
{
"query":{
"match_all":{}
}
}
查询指定title字段
{
"query":{
"match_all":{}
},
"_source":["title"]
}
分页查询
{
"query":{
"match_all":{}
},
"from":0,
"size":2
}
查询排序，以price排序
{
"query":{
"match_all":{}
},
"sort":{
"price":{
"order":"desc"
}
}
}
多条件查询，（must相当于数据库的 && ）bool表示条件。
匹配category是小米且price是1999
{
"query":{
"bool":{
"must":[{
"match":{
"category":"小米"
}
},{
"match":{
"price":1999.00
}
}]
}
}
}
范围查询
查询小米和华为的牌子，且价格小于2000（should相当于数据库的 || ）
{
"query":{
"bool":{
"should":[{
"match":{
"category":"小米"
}
},{
"match":{
"category":"华为"
}
}],
"filter":{
"range":{
"price":{
"lt":2000
}
}
}
}
}
}
全文检索 & 完全匹配 & 高亮查询
- 全文检索：这功能像搜索引擎那样，如品牌输入“小华”，返回结果带回品牌有“小米”和华为的，ES会将"小"和"华"分词，进行倒排索引匹配。
- 完全匹配：精确匹配关键字
- 高亮查询：像百度搜索一样高亮显示的关键字
全文检索
{
"query":{
"match":{
"category" : "小华"
}
}
}
完全匹配
{
"query":{
"match_phrase":{
"category" : "为"
}
}
}
高亮查询
{
"query":{
"match_phrase":{
"category" : "为"
}
},
"highlight":{
"fields":{
"category":{}//<----高亮这字段
}
}
}
聚合查询
聚合允许使用者对 es 文档进行统计分析，类似与关系型数据库中的 group by，当然还有很多其他的聚合，例如取最大值max、平均值avg等等。
接下来按price字段进行分组：
{
"aggs":{//聚合操作
"price_group":{//名称，随意起名
"terms":{//分组
"field":"price"//分组字段
}
}
}
}
上面返回结果会附带原始数据的。若不想要不附带原始数据的结果添加字段"size":0
{
"aggs":{
"price_group":{
"terms":{
"field":"price"
}
}
},
"size":0
}
对所有手机价格求平均值。
{
"aggs":{
"price_avg":{//名称，随意起名
"avg":{//求平均
"field":"price"
}
}
},
"size":0
}
映射关系-mapping
mapping：类似于数据库(database)中的表结构(table)。拥有哪些字段和约束信息
创建索引
PUT http://127.0.0.1:9200/user
创建mapping
PUT http://127.0.0.1:9200/user/_mapping
{
"properties": {
"name":{
"type": "text", //全文检索
"index": true
},
"sex":{
"type": "keyword", // 精确匹配
"index": true
},
"tel":{
"type": "keyword",
"index": false // 没有设置索引，无法直接查询
}
}
}
查询mapping
GET http://127.0.0.1:9200/user/_mapping
添加数据
PUT http://127.0.0.1:9200/user/_create/1001
{
"name":"小米",
"sex":"男的",
"tel":"1111"
}
查询name含有"小"的数据，可以全文检索到
GET http://127.0.0.1:9200/user/_search
{
"query":{
"match":{
"name":"小"
}
}
}
查询sex含有"男"的失败，keyword需要精确匹配才能查询到
GET http://127.0.0.1:9200/user/_search
{
"query":{
"match":{
"sex":"男"
}
}
}
ES集群架构
- 集群是由拥有相同cluster.name 配置的节点组成， 它们共同承担数据和负载的压力。
- 当有节点加入集群中或者从集群中移除节点时，集群将会重新平均分布所有的数据。
- 主节点负责管理集群范围内的所有变更。
- 客户端可以将请求发送到集群中的任何节点 ，每个节点都知道任意文档所处的位置，并且能够将我们的请求直接转发到存储我们所需文档的节点。
集群测试
安装es head插件
安装google浏览器es head插件
创建一个3个分片，1个副本的索引
PUT http://127.0.0.1:9200/users
{
"settings" : {
"number_of_shards" : 3,
"number_of_replicas" : 1
}
}
可以看到3个主分片已经成功了，但是副本状态为Unassigned，它们都没有被分配到任何节点。 在同 一个节点上既保存原始数据又保存副本是没有意义的。
扩容节点
当启动了第二个节点，集群将会拥有两个节点 : 所有主分片和副本分片都被分配 。
当启动了第三个节点，集群为了分散负载而对分片进行重新分配 。
动态调整副本数
PUT http://127.0.0.1:1001/users/_settings
{
"number_of_replicas" : 2
}
users 索引现在拥有 9 个分片： 3 个主分片和 6 个副本分片。 这意味着我们可以将集群扩容到 9 个节点，每个节点上一个分片。相比原来 3 个节点时，集群搜索性能理论上可以提升 3 倍。
故障模拟–干掉1个节点
我们关闭一个主节点。集群必须拥有一个主节点来保证正常工作，所以发生的第一件事情就是选举一个新的主节点： Node 3 。在我们关闭 Node 1 的同时也失去了主分片 1 和 2 ，并且在缺失主分片的时候索引也不能正常工作。 如果此时来检查集群的状况，我们看到的状态将会为 red ：不是所有主分片都在正常工作。
因为在其它节点上存在着这两个主分片的完整副本， 所以新的主节点立即将这些分片在 Node 2 和 Node 3 上对应的副本分片提升为主分片， 此时集群的状态将会为yellow。这个提升主分片的过程是瞬间发生的。
当把node1节点恢复，集群可以将缺失的副本分片再次进行分配，那么集群的状态也将恢复成之前的状态。只是master节点换了
路由计算
Elasticsearch 通过下列算法知道一个文档应该存放到哪个分片中。其中routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。
shard = hash(routing) % number_of_primary_shards
为什么我们要在创建索引的时候就确定好主分片的数量并且永远不会改变这个数量？
因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。
所有的文档API ( get . index . delete 、 bulk , update以及 mget ）都接受一个叫做routing 的路由参数，通过这个参数我们可以自定义文档到分片的映射。一个自定义的路由参数可以用来确保所有相关的文档都被存储到同一个分片中。
使用routing寻址会提高读写速度？
数据写流程
新建、索引和删除请求都是写操作， 必须在主分片上面完成之后才能被复制到相关的副本分片。
- 客户端请求任意节点（协调节点）
- 协调节点将请求转换到指定节点
- 主分片保存数据
- 主分片同步数据至副本
- 副本保存后进行反馈
- 主分片进行反馈
- 客户端获取反馈
数据读流程
- 客户端发送请求到任意节点（协调节点）
- 协调节点返回数据所在分片及所有副本位置
- 将请求发给具体节点
- 节点返回查询结果返回给客户端
更新流程
- 客户端请求到node1节点（主分片在node3）
- node1做为协调节点将请求转发至node3
- node3从主分片修改文档
- 成功更新文档后，将新版本并行发送到副本分片，重新建立索引。一旦所有节点返回成功，node3向协调节点返回成功，协调节点再给客户端返回。
批量操作流程
mget和 bulk API的模式类似于单文档模式。区别在于协调节点知道每个文档存在于哪个分片中。它将整个多文档请求分解成每个分片的多文档请求，并且将这些请求并行转发到每个参与节点。协调节点一旦收到来自每个节点的应答，就将每个节点的响应收集整理成单个响应，返回给客户端。
用单个 mget 请求获取多个文档
- 客户端像node1发送mget请求
- node1为每个分片构建多文档获取请求，并行转发到每个住分片或副本分片节点上。一旦收到所有答复，node1构建响应并将其返回给客户端
用bulk API 在单个批量请求中执行多个创建、索引、删除和更新请求
- 客户端向node1发送bulk请求
- node1为每个节点创建一个批量请求，并将这些请求并行转发到每个包含主分片的节点主机。主分片按顺序执行每个操作。当每个操作成功后，主分片并行转发请求（创建/删除）到副本分片，然后执行下一个操作。当副本报告所有操作成功，该节点向协调节点报告成功，最终返回客户端
文档搜索
不可改变的倒排索引
倒排索引被写入磁盘后是不可改变的：它永远不会修改。
-
不需要锁。如果你从来不更新索引，你就不需要担心多进程同时修改数据的问题。
-
一旦索引被读入内核的文件系统缓存，便会留在哪里，由于其不变性。只要文件系统缓存中还有足够的空间，那么大部分读请求会直接请求内存，而不会命中磁盘。这提供了很大的性能提升。
-
其它缓存(像filter缓存)，在索引的生命周期内始终有效。它们不需要在每次数据改变时被重建，因为数据不会变化。
-
写入单个大的倒排索引允许数据被压缩，减少磁盘IO和需要被缓存到内存的索引的使用量。
- 如果你需要让一个新的文档可被搜索，你需要重建整个索引。
- 这要么对一个索引所能包含的数据量造成了很大的限制，要么对索引可被更新的频率造成了很大的限制。
动态更新索引
如何在保留不变性的前提下实现倒排索引的更新？
用更多的索引。通过增加新的补充索引来反映新近的修改，而不是直接重写整个倒排索引。每一个倒排索引都会被轮流查询到,从最早的开始查询完后再对结果进行合并。
Elasticsearch基于Lucene，这个java库引入了按段搜索的概念，每一段本身都是一个倒排索引，最早的会被先查询。因为倒排索引是不可改变的，所以既不能把文档从旧的段中移除，也不能修改旧的段来进行反映文档的更新。
当一个文档被"删除"时，它实际上只是在 .del 文件中被标记删除（逻辑删除） 一个被标记删除的文档仍然可以被查询匹配到，但它会在最终结果被返回前从结果集中移除。
当多个倒排索引合并为一个新的时，则可以把标记删除的倒排索引删除（物理删除）
文档更新也是类似的操作方式:当一个文档被更新时，旧版本文档被标记删除，文档的新版本被索引到一个新的段中。可能两个版本的文档都会被一个查询匹配到，但被删除的那个旧版本文档在结果集返回前就已经被移除。
文档刷新-刷写-合并
近实时搜索
与数据库不同，数据库是先写入log，再写入memory。ES刚好相反，因为memory操作很复杂，必须保证操作成功后再记录log。
- 客户端将数据写入内存index
- 内存中形成 segment 数据对象，继而写入 translog 防止主机重启/断电丢失数据
- 将内存中的 segment refresh（默认1s） 到 os cache（提高搜索速度，此时数据已经可以被查询到）中的 segment，随后再将os cache中的segment flush（默认30m）/或 translog 太大刷到磁盘中的 segment
- segment落盘后会自动进行segment合并，小的合并成大的，合并时会删除被标注为del的数据
并不是所有的情况都需要每秒刷新。可能你正在使用Elasticsearch索引大量的日志文件，你可能想优化索引速度而不是近实时搜索，可以通过设置refresh_interval （可动态更新），降低每个索引的刷新频率。在生产环境中，当你正在建立一个大的新索引时，可以先关闭自动刷新，待开始使用该索引时，再把它们调回来。
# 关闭自动刷新
PUT /users/_settings
{ "refresh_interval": -1 }
# 每30秒刷新
PUT /users/_settings
{ "refresh_interval": "30s" }
段合并
由于自动刷新流程每秒会创建一个新的段，这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。每一个段都会消耗文件句柄、内存和 cpu运行周期。更重要的是，每个搜索请求都必须轮流检查每个段；所以段越多，搜索也就越慢。
合并大的段需要消耗大量的 I/O 和 CPU 资源，如果任其发展会影响搜索性能。 Elasticsearch在默认情况下会对合并流程进行资源限制，所以搜索仍然有足够的资源很好地执行。
文档分析
分析器的作用
- 将一块文本分成适合于倒排索引的独立的词条。
- 将这些词条统一化为标准格式以提高它们的“可搜索性”。
默认分析器
#GET http://localhost:9200/_analyze
{
"analyzer": "standard",
"text": "Text to analyze"
}
- token是实际存储到索引中的词条。
- start_ offset 和end_ offset指明字符在原始字符串中的位置。
- position指明词条在原始文本中出现的位置。
{
"tokens": [
{
"token": "text",
"start_offset": 0,
"end_offset": 4,
"type": "",
"position": 1
},
{
"token": "to",
"start_offset": 5,
"end_offset": 7,
"type": "",
"position": 2
},
{
"token": "analyze",
"start_offset": 8,
"end_offset": 15,
"type": "",
"position": 3
}
]
}
IK中文分析器
实际场景下还需要用到中文分析器，而IK分析器是大家推荐的：下载IK分析器
将解压后的后的文件夹放入 ES 根目录下的 plugins 目录，重启
IK分析器参数：
- ik_max_word：会将文本做最细粒度的拆分。
- ik_smart：会将文本做最粗粒度的拆分。
# GET http://localhost:9200/_analyze
{
"text":"测试单词",
"analyzer":"ik_max_word"
}
{
"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
}
]
}
自定义IK分析器词汇
有的词汇使用默认分词规则无法匹配到，但确实是词组，这种情况下可以使用扩展词汇。
- 首先进入 ES 根目录中的 plugins 文件夹下的 ik 文件夹，进入 config 目录，创建 custom.dic文件，写入“弗雷尔卓德”。
- 同时打开 IKAnalyzer.cfg.xml 文件，将新建的 custom.dic 配置其中。
- 重启 ES 服务器 。
<properties>
<comment>IK Analyzer 扩展配置comment>
<entry key="ext_dict">custom.dicentry>
<entry key="ext_stopwords">entry>
properties>
自定义分词器
可以将一些字符转换，如将&符号转换为字母and这种。这种不太常用，但是ES都是支持的。
文档控制
悲观锁
这种方法被关系型数据库广泛使用，它假定有变更冲突可能发生，因此阻塞访问资源以防止冲突。一个典型的例子是读取一行数据之前先将其锁住，确保只有放置锁的线程能够对这行数据进行修改。这种锁对性能有很大的影响
乐观锁ES
Elasticsearch 中使用乐观锁假定冲突是不可能发生的，并且不会阻塞正在尝试的操作。如果源数据在读写当中被修改，更新将会失败。应用程序接下来将决定该如何解决冲突。例如，可以重试更新、使用新的数据、或者将相关情况报告给用户。
每个文档都有一个_version（版本号），当文档被修改时版本号递增。Elasticsearch使用这个version号来确保变更以正确顺序得到执行。
优化参考
硬件
使用SSD
使用多块磁盘
不实用NFS之类的远程存储
分片策略
合理设置分片数
分片数设置完成后因为路由机制无法修改，需要了解：
-
一个分片的底层即为一个 Lucene 索引，会消耗一定文件句柄、内存、以及 CPU运转。
-
每一个搜索请求都需要命中索引中的每一个分片，如果每一个分片都处于不同的节点还好， 但如果多个分片都需要在同一个节点上竞争使用相同的资源就有些糟糕了。
-
用于计算相关度的词项统计信息是基于分片的。如果有许多分片，每一个都只有很少的数据会导致很低的相关度。
业务需要多大分片需要预估，通常遵循以下原则：
- 控制每个分片占用的硬盘容量不超过 ES 的最大 JVM 的堆空间设置（一般设置不超过 32G，参考下文的 JVM 设置原则），因此，如果索引的总容量在 500G 左右，那分片大小在 16 个左右即可；当然，最好同时考虑原则 2。
- 考虑一下 node 数量，一般一个节点有时候就是一台物理机，如果分片数过多，大大超过了节点数，很可能会导致一个节点上存在多个分片，一旦该节点故障，即使保持了 1 个以上的副本，同样有可能会导致数据丢失，集群无法恢复。所以， 一般都设置分片数不超过节点数的 3 倍。
- 主分片，副本和节点最大数之间数量，我们分配的时候可以参考以下关系：
节点数<=主分片数 *（副本数+1）
延迟分片分配
对于节点瞬时中断的问题，默认情况，集群会等待一分钟来查看节点是否会重新加入，如果这个节点在此期间重新加入，重新加入的节点会保持其现有的分片数据，不会触发新的分片分配。这样就可以减少 ES 在自动再平衡可用分片时所带来的极大开销。
通过修改参数 delayed_timeout ，可以延长再均衡的时间，可以全局设置也可以在索引级别进行修改：
#PUT /_all/_settings
{
"settings": {
"index.unassigned.node_left.delayed_timeout": "5m"
}
}
路由策略
routing 默认值是文档的 id，也可以采用自定义值，比如 userid。
-
不带routing查询分两步：
分发：请求到达协调节点后，协调节点将查询请求分发到每个分片上。
聚合：协调节点搜集到每个分片上查询结果，在将查询的结果进行排序，之后给用户返回结果。 -
带routing查询
查询的时候，可以直接根据routing 信息定位到某个分片查询，不需要查询所有的分片，经过协调节点排序。向上面自定义的用户查询，如果routing 设置为userid 的话，就可以直接查询出数据来，效率提升很多。
写入速度优化
针对于搜索性能要求不高，但是对写入要求较高的场景，可以考虑以下几个方面来提升写索引的性能：
- 加大translog flush，目的是降低IOPS、WriteBlock。
- 增加index refresh interval，目的是减少Segment Merge的次数。
- 调整 Bulk 线程池和队列。
- 优化节点间的任务分布。
- 优化Lucene层的索引建立，目的是降低CPU及IO。
合理使用合并
Lucene 以段的形式存储数据。当有新的数据写入索引时， Lucene 就会自动创建一个新的段。
减少 Refresh 的次数
如果我们对搜索的实效性要求不高， Refresh 周期默认为1秒，可以延长至 30 秒。
这样可以有效地减少段刷新次数，但这同时消耗更多的 Heap 内存。
加大 Flush 设置
Flush 的主要目的是把文件缓存系统中的段持久化到硬盘，当 Translog 的数据量达到 512MB 或者 30 分钟时，会触发一次 Flush。index.translog.flush_threshold_size 参数的默认值是 512MB，适当调大可以在事务日志里积累出更大的段。
减少副本的数量
当写索引时，需要把写入的数据都同步到副本节点，副本节点越多，写索引的效率就越慢。
如果我们需要大批量进行写入操作，可以先禁止Replica复制，设置
index.number_of_replicas: 0 关闭副本。在写入完成后， Replica 修改回正常的状态。
内存设置
ES 堆内存的分配需要满足以下两个原则：
-
不要超过物理内存的 50%： Lucene 的设计目的是把底层 OS 里的数据缓存到内存中。Lucene 的段是分别存储到单个文件中的，这些文件都是不会变化的，所以很利于缓存，同时操作系统也会把这些段文件缓存起来，以便更快的访问。如果我们设置的堆内存过大， Lucene 可用的内存将会减少，就会严重影响降低 Lucene 的查询性能。
-
堆内存的大小最好不要超过 32GB：在 Java 中，所有对象都分配在堆上，然后有一个 Klass Pointer 指针指向它的类元数据。这个指针在 64 位的操作系统上为 64 位， 64 位的操作系统可以使用更多的内存（2^64）。在 32 位
的系统上为 32 位， 32 位的操作系统的最大寻址空间为 4GB（2^32）。
但是 64 位的指针意味着更大的浪费，因为你的指针本身大了。浪费内存不算，更糟糕的是，更大的指针在主内存和缓存器（例如 LLC, L1 等）之间移动数据的时候，会占用更多的带宽。
最终我们都会采用 31 G 设置
-Xms 31g
-Xmx 31g
假设你有个机器有 128 GB 的内存，你可以创建两个节点，每个节点内存分配不超过 32 GB。也就是说不超过 64 GB 内存给 ES 的堆内存，剩下的超过 64 GB 的内存给 Lucene。
集群配置
- cluster.name：配置 ES 的集群名称，默认值是 ES，建议改成与所存数据相关的名称， ES 会自动发现在同一网段下的 集群名称相同的节点。
- node.name：集群中的节点名，在同一个集群中不能重复。节点 的名称一旦设置，就不能再改变了。当然，也可以 设 置 成 服 务 器 的 主 机 名 称 ， 例 如 node.name:${HOSTNAME}。
- node.master：指定该节点是否有资格被选举成为 Master 节点，默 认是 True，如果被设置为 True，则只是有资格成为 Master 节点，具体能否成为 Master 节点，需要通 过选举产生。
- node.data：指定该节点是否存储索引数据，默认为 True。数据 的增、删、改、查都是在 Data 节点完成的。
- index.number_of_shards：设置都索引分片个数，默认是 1 片。也可以在创建 索引时设置该值，具体设置为多大都值要根据数据 量的大小来定。如果数据量不大，则设置成 1 时效 率最高
- index.number_of_replicas：设置默认的索引副本个数，默认为 1 个。副本数越 多，集群的可用性越好，但是写索引时需要同步的 数据越多。
- transport.tcp.compress：设置在节点间传输数据时是否压缩，默认为 False， 不压缩，建议设置为true
- discovery.zen.minimum_master_nodes：设置在选举 Master 节点时需要参与的最少的候选 主节点数，默认为 1。如果使用默认值，则当网络 不稳定时有可能会出现脑裂。 合 理 的 数 值 为 (master_eligible_nodes/2)+1 ， 其 中 master_eligible_nodes 表示集群中的候选主节点数
- discovery.zen.ping.timeout：设置在集群中自动发现其他节点时 Ping 连接的超 时时间，默认为 3 秒。 在较差的网络环境下需要设置得大一点，防止因误 判该节点的存活状态而导致分片的转移
查询index配置
GET /_settings
查询集群配置
GET /_cluster/settings
使用curl修改示例
curl -X PUT “localhost:9200/_settings” -H ‘Content-Type: application/json’ -d’{“index” : {“translog”:{“durability”: “async”,“sync_interval”:“10s”}}}’
参考文档
https://www.elastic.co/guide/en/elasticsearch/reference/7.x/how-to.html
https://www.elastic.co/guide/en/elasticsearch/reference/7.x/tune-for-indexing-speed.html
https://www.elastic.co/guide/en/elasticsearch/reference/7.x/tune-for-disk-usage.html
https://www.elastic.co/guide/en/elasticsearch/reference/7.x/tune-for-search-speed.html
https://blog.csdn.net/u011863024/article/details/115721328