Elasticsearch集群优化
版本配置：
ES版本：7.16.1
OS内存64G。
1、磁盘选择
Elasticsearch重度使用磁盘，磁盘的效率越高，Elasticsearch的执行效率就越高。
优化磁盘：
1）使用SSD（固态硬盘）。
2）使用RAID0模式，即将连续的数据分散到多个硬盘存储，这样可以并行进行IO操作。代价是一块硬盘发生故障就会引发系统故障。
3）不要使用远程挂载的存储。即在ES服务器中，而非ES服务器之外的存储。
2、分片策略
每个分片的底层都是一个Lucene索引，会消耗一定的系统资源。搜索请求需要命中索引中的所有分片，分片过多会降低搜索的性能。
分片原则：
1）每个分片占用的磁盘容量不超过ES的JVM的最大堆空间设置（一般设置不超过32G）。
2）分片数一般不超过节点数的三倍。
3）推迟分片分配：节点中断后集群会重新分配分片。但默认集群会等待一分钟来查看节点是否重新加入。可以设置等待的时长，减少分配的次数。
PUT /product/_settings
{
"settings":{
"index.unassigned.node_left.delayed_timeout": "5m"
}
}
减少副本数量：进行写入操作时，需要把写入的数据都同步到副本中，副本越多写入的效率就越慢。进行大批量写入操作时可以先设置副本数为0，写入完成后再修改回正常的状态。
3、内存设置
- 如果是64G的，建议设置
31G
ES默认占用内存时4G，可以修改config/jvm.option文件设置ES的堆内存大小。
1）Xms表示堆内存的初始大小，Xmx表示可分配的最大内存。
2）Xmx和Xms的大小设置为相同时，可以减轻伸缩堆大小带来的压力。
3）Xmx和Xms不要超过物理内存的50%，因为ES内部的Lucene也要占据一部分物理内存。
4）Xmx和Xms不要超过32G，由于JAVA语言的特性，堆内存超过32G会浪费大量系统资源，所以在内存足够的情况下，最终都会采用设置为31G。
4.禁止内存交换：
- 修改/etc/sysctl.conf 中
- vm.swappiness = 1
- elasticsearch.yml中，设置这个：
- bootstrap.mlockall：true
5.修改ES启动用户可使用的系统文件句柄数等。
6.节点分开部署：
- master、data、coordinate
7.冷热分离架构：
- 热数据SSD存储，冷数据普通硬盘存储。
二、合理的Index Mapping：
1.特殊字段：如Boolean、IP、时间等。
2.字符串：
- 尽量使用keyword，默认的text会被analyze。keyword最大32766字节。在仅查询的情况下，如果有 range 查询需求，使用 numeric，否则使用 keyword。
3.调整refresh间隔：
-
refresh_interval: 30s，默认的1秒会导致大量segment产生，影响性能。
-
PUT /my_logs/_settings { “refresh_interval”: “30s” }
4.调整translog刷新机制为异步：
“index”: {
“translog”: {
“flush_threshold_size”: “512mb”, （默认512M，不建议修改）
“sync_interval”: “30s”, (默认5s，可适当增大)
“durability”: “async” （默认request，每次更新都会写trans log，修改为异步）
}
}
5.Segment的排序方式
- 创建新索引时，可以配置每个分片中的Segment的排序方式，index sorting是优化检索性能的非常重要的方式之一：
{
“settings” : {
“index” : {
“sort.field” : “date”,
“sort.order” : “desc”
}
},
“mappings”: {
“properties”: {
“date”: {
“type”: “date”
}
}
}
}
三、ES参数调整：
针对data节点，设置elasticsearch.yml中：
-
thread_pool.bulk.queue_size: 1024 （增大）
-
indices.fielddata.cache.size: 1gb （默认10%，可适当调小）
-
indices.queries.cache.size: 1gb（默认10%，可适当调小）
-
indices.memory.index_buffer_size: 15% （默认10%，会影响写入性能，写入的分片数更多，则需要更多的buffer）
-
cluster.routing.allocation.disk.include_relocations: false （加快shard分配，在建索引的时候，不考虑迁移的任务）
熔断circuit-breaker调整（调低，减小OOM风险）：
-
indices.breaker.total.limit: 50%
-
indices.breaker.request.limit: 10%
-
indices.breaker.fielddata.limit: 10%
-
cluster.routing.allocation.same_shard.host：true
如果机器具有128 GB的RAM，可以运行两个节点，每个节点配置31GB内存，Lucene将使用剩余64GB内存。如果这样搭建data节点，在配置中设置cluster.routing.allocation.same_shard.host为true。这将阻止主副本分片被分配到同一台物理机，提高可用性。
四、设置合理的分片数和副本数：
1.对于数据量较小（100GB以下）的index：一般设置3~5个shard
2.对于数据量较大（100GB以上）的index：一般把单个shard的数据量控制在20GB~40GB
3.对于30G内存的节点，shard数量最好控制在600个（即每1GB内存的shard数在20以内）
4.副本数：一般副本数为1，对数据可用性有高要求的，可以设置为2
五、索引管理、段合并（Segment Merge）
1.基于数据大小和保存时长，按天、周、月、年去创建、关闭、删除索引。
2.索引太多时，索引预创建：每天定时任务把明天需要的索引先创建好（从6.7版本开始kibana自带索引生命周期管理ILM）。
3.关闭索引（文件仍然存在于磁盘，只是释放掉内存），需要的时候可以重新打开。
4.通过_forcemerge API进行合并，减少segments数量，同时提高查询效率：max_num_segments取值为：max_num_segments =（单个索引的大小G/分片数/2G）
5.通过_reindex API将历史小索引合并成大索引，减少索引数和分片数。
6.数据roll up（预聚合，物化视图）
六、写入：
写入调优主要从索引，集群trandlog参数配置入手优化。
索引创建默认分配5个分片，1副本。但是并不建议用默认参数。
1、分片大小优化：
- 根据自己的数据量评估总分片，分片数=数据量G/30G。
2、副本个数：
- 可以通过写入时副本=0关闭主从复制提高写入速率，写完再设置合适副本
3、bulk写入优化：
- 采用bulk写入,线程数默认是服务器线程数+1。批大小建议5-15M，从 5–15 MB 开始测试批量请求大小，缓慢增加这个数字，直到你看不到性能提升为止。报EsRejectedExecutionException达到写入极限。也可通过观察iostat 、 top 看节点资源瓶颈。
4、translog优化，降低io和segment频率。
提高 translog flush：减少刷盘操作，降低IO压力
index.translog.flush_threshold_size: 1024mb
index.translog.flush_threshold_period: 120m
5、设置合适的mapping
- 避免不必要的字段开启index、source，all。source会存储原始文档，all用于全文搜索会占用资源（关闭可节省40%的资源）。
6、集群参数优化
index.refresh_interval：控制数据可被搜索的时间，同时也会控制生成的segment段数。时间太短会生成太多的段占用io和cpu去合并，影响写入速度。如果对实时性要求不高，可以适当提高采用延迟写入的策略，比如120S。
thread_pool.bulk.queue_size:1000 写入线程队列大小 ，默认200，线程池参数只用调优这一个。
7、存储优化
磁盘采用ssd固态硬盘，阵列模式使用raid0来避免数据复制提升性能
使用多块硬盘，并通过多个 path.data 目录配置把数据分配到它们上面
8、segment段合并
max_num_segments =1
段合并的计算量庞大，而且还要吃掉大量磁盘 I/O。
有时候合并会拖累写入速率。如果这个真的发生了，Elasticsearch 会自动限制索引（写入）请求到单个线程里。这个可以防止出现 段爆炸 问题，即数以百计的段在被合并之前就生成出来。如果 Elasticsearch 发现合并拖累索引写入了，它集群日志中会记录一个INFO 级别 now throttling indexing 的 信息。
七、查询：
-
尽量使用filter而不是query。使用filter不会计算评分score，只计算匹配。
-
如果不关心文档返回的顺序，则按_doc排序。
-
避免通配符查询。
-
不要获取太大的结果数据集，如果需要大量数据使用scroll API。
- 分页查询使用：from+size
- 遍历使用：scroll
- 并行遍历使用：scroll+slice
-
关于数据聚合去重
- terms 指定字段聚合 + topN：合理设置聚合的topN，聚合结果是不精确的，是取每个分片的Top size元素后综合排序后的值。
- ES5以后的新特性collapse：按某个字段进行“折叠”，这个collapse只针对query出来的结果，只能用在keyword或者numeric类型。
- ES6以后支持分页的聚合：Composite Aggregation，可以获取全量的聚合数据，只能用于Terms、Histogram、Date histogram、GeoTile grid。
-
indices索引参数调优
indices.queries.cache.size：控制过滤器缓存的内存大小（在使用filter过滤时候会用到）。接受百分比值（如5%）或精确值（如 ）512mb。默认为10%.每个节点上的配置。
index.queries.cache.enabled设置单个索引的是否开启缓存配置。接受true（默认）或 false。
indices.fielddata.cache.size：30% 或具体值10GB来。在聚类或排序时，field data cache会使用频繁 -
进行segment段合并，减少扫描时间
默认写入合并时=1G会停止合并。写入完成后可以通过定时任务去强制合并，减小segment数据，提高查询速度。
-
查询条件优化
采用filter过滤器查询提高效率，减少返回的数据量，es不适合返回大数据量，默认10000
禁用source返回。将 _source 设置为 false。
filter的查询速度比query快很多，query会对doc计算score并进行排序
{
“_source”: false,
“query”: { }
}
https://www.elastic.co/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster
https://www.elastic.co/guide/en/elasticsearch/reference/6.2/general-recommendations.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/tune-for-search-speed.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/tune-for-indexing-speed.html文章来源：https://www.toymoban.com/news/detail-451849.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/tune-for-disk-usage.html文章来源地址https://www.toymoban.com/news/detail-451849.html
到了这里，关于Elasticsearch集群优化的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
