泉缘泉 发表于 2025-1-5 22:28:02

ElasticSearch10-性能优化

零、文章目录

ElasticSearch10-性能优化

1、硬件优化

(1)存储设置



[*]ElasticSearch 是基于Lucene 的,Lucene将数据存储在磁盘上,磁盘的IO就是 ElasticSearch 的瓶颈地点。
[*]Elasticsearch 默认的数据存储路径是在 Elasticsearch 安装目录下的 data 子目录中。不过,这个路径是可以设置的,详细的默认路径可能因操纵体系和安装方式的不同而有所差异。
[*]对于不同的操纵体系,Elasticsearch 的默认数据路径通常是:

[*]Linux:/usr/share/elasticsearch/data
[*]macOS:/usr/local/var/lib/elasticsearch/data
[*]Windows:C:\ProgramData\Elasticsearch\data

[*]**设置数据存储路径:**可以在 elasticsearch.yml 设置文件中设置 path.data 属性。例如:
path.data: /var/lib/elasticsearch/data


[*]注意事项

[*]Elasticsearch 允许你设置多个数据路径,以便于实现数据的冗余存储和负载均衡。这可以通过在 path.data 后面跟上多个路径实现,路径之间用逗号分隔。
[*]确保 Elasticsearch 历程对该路径有读写权限。
[*]建议不要将数据存储在体系盘上,以制止体系盘空间不足导致的题目。

(2)优化建议



[*]使用 SSD,性能远高于机械磁盘。
[*]使用 RAID 0,条带化 RAID 会进步磁盘 I/O,代价显然就是当一块硬盘故障时整个就故障了。不要使用镜像或者奇偶校验 RAID 因为副本已经提供了这个功能。
[*]使用多块硬盘,并允许 Elasticsearch 通过多个 path.data 目录设置把数据条带化分配到它们上面。
[*]不要使用长途挂载的存储,好比 NFS 或者 SMB/CIFS。这个引入的延迟对性能来说完全是南辕北辙。
2、分片优化

(1)设置合理分片数量



[*]数据规模:估算你存储的数据总量,并参考每个分片的最佳大小(通常在10GB到50GB之间)。这样可以确保分片既不会过大导致恢复时间过长,也不会过小导致资源开销增加。
[*]并发量和负载分布:考虑查询的并发性,更多的分片可以分散查询负载。但是,分片数量过多会导致管理开销增加,每个搜刮哀求都会调度到索引的每个分片中,如果分片分散在不同的节点上题目不大,但如果分片开始竞争相同的硬件资源时,性能便会逐步下降。
[*]硬件资源:每个节点上可以存储的分片数量与可用的堆内存大小成正比关系。一个经验法则是,确保对于节点上已设置的每个GB,将分片数量保持在20以下。例如,如果节点有30GB的堆内存,那么最多可以有600个分片。但是,从8.3版本开始,Elasticsearch减少了每个分片的堆使用量,因此这个经验法则也举行了更新,请根据现实环境调整。
[*]数据增长趋势:考虑数据集的增长趋势,制止为将来可能的数据量做过多分配。如果你担心数据的快速增长,可以将分片最大容量限制为30GB,然后再对分片数量做合理估算。例如,如果你的数据能达到200GB,推荐最多分配7到8个分片。
[*]查询性能:对于需要频仍更新或删除的数据,较小的分片(10GB-20GB)可能更符合,因为这样可以减少段合并的开销。对于静态数据或只增加不修改的数据,更大的分片(靠近50GB)通常更有效。
[*]集群扩展性:随着数据量的增加,可以通过增加分片数和呆板数来扩展集群。Elasticsearch会主动迁移分片以重新均衡集群。
[*]索引和分片的资源开销:每个索引和分片都会产生肯定的资源开销。因此,合理规分别片数量和大小对于集群的性能至关重要。
[*]综上所述,合理设置分片数量需要根据详细的业务需求、数据增长预测、集群资源和性能目的来综合考虑。通常,一个均衡的做法是保持每个分片在10GB到50GB之间,并根据节点的堆内存大小来合理设置分片数量,同时考虑到高可用性和吞吐量的需求。
(2)推迟分片分配



[*]对于节点瞬时中断的题目,默认环境,集群会等候一分钟来查看节点是否会重新加入,如果这个节点在此期间重新加入,重新加入的节点会保持其现有的分片数据,不会触发新的分片分配。这样就可以减少 ES 在主动再均衡可用分片时所带来的极大开销。
[*]通过修改参数 delayed_timeout,可以延长再均衡的时间,可以全局设置也可以在索引级别举行修改:
PUT /_all/_settings
{
    "settings": {
            "index.unassigned.node_left.delayed_timeout": "5m"
    }
}
(3)自适应副本选择



[*]**自适应副本选择(Adaptive Replica Selection,ARS):**是一个用于进步搜刮性能的功能,它允许副天职片参与搜刮哀求,而不需要主分片的参与。ARS在7.0版本中引入默认开启,用于减少跨节点搜刮的网络开销。
[*]启用自适应副本选择:自适应副本选择默认是启用的,但如果需要确认或启用该功能,可以在elasticsearch.yml设置文件中设置以下参数,这个设置允许Elasticsearch在实行搜刮时考虑长途副天职片。
search.remote_cluster_aware: true


[*]设置集群名称:为了使用自适应副本选择,需要确保所有参与的Elasticsearch集群都设置了相同的cluster.name。这可以在elasticsearch.yml文件中设置:
cluster.name: my-application


[*]设置副天职配:如果需要,可以设置副天职片的分配策略,以确保副天职片被分配到不同的节点或机架上,从而进步搜刮的效率和可靠性。这个例子中,副天职片将被分配到具有rack_id为1或2的节点上。
PUT /_cluster/settings
{
"persistent": {
    "cluster.routing.allocation.replicas.include.rack_id": "1,2"
}
}
3、路由优化

(1)路由参数原理



[*]**路由公式:**shard_num = hash(_routing) % num_primary_shards。
[*]减少查询分片数:通过指定routing参数,查询可以被限制在特定的分片上实行,而不是遍历所有的分片。这样可以减少查询的分片数量,从而进步查询效率。
[*]制止协调节点二次排序:在没有指定routing的环境下,查询哀求会分发到所有分片,然后协调节点需要对所有分片返回的结果举行排序和聚合,这会增加额外的性能开销。而指定routing后,可以直接在目的分片上完成搜刮,制止了协调节点的二次排序。
[*]进步查询速度:使用Routing信息查找的效率很高,因为可以直接定位到目的分片,制止了多余的查询,从而加快了查询速度。
[*]优化数据布局:通过合理地使用Routing,可以控制数据的物理布局,将干系的文档路由到相同的分片上,这样可以减少跨分片查询的需要,进步查询性能。
[*]确保数据同等性:自定义路由可以确保对具有相同路由值的文档的读取和写入操纵都在同一个分片上实行,从而减少数据不同等的风险。
[*]进步查询效率:在设计Elasticsearch Mapping时,合理使用Routing信息可以提升查询的效率。例如,可以将都会ID作为Routing的条件,让同一个都会的数据落在相同的分片中,这样查询时可以直接指定Routing,进步查询效率。
(2)索引文档时指定路由值



[*]当索引一个新文档时,可以在哀求中包含routing参数来指定路由值。

[*]通过指定routing=user123,告诉Elasticsearch将文档路由到与user123哈希值对应的分片上。
[*]如果以后需要检索或更新这个文档,也需要在哀求中包含相同的路由值。

# 创建索引
PUT my_index_2

# 创建文档
PUT /my_index_2/_doc/1?routing=user123
{
"user_id": "user123",
"title": "My first blog post"
}

# 返回
{
"_index" : "my_index_2",
"_type" : "_doc",
"_id" : "1",
"_version" : 1,
"result" : "created",
"_shards" : {
    "total" : 2,
    "successful" : 1,
    "failed" : 0
},
"_seq_no" : 0,
"_primary_term" : 1
}
(3)查询时指定路由值



[*]在实行查询时,也可以指定路由值来限制查询只在特定的分片上实行。

[*]此搜刮哀求将仅在与“user1”和“user2”路由值关联的分片上实行。

GET my_index_2/_search?routing=user1,user2
{
"query": {
    "match": {
      "title": "document"
    }
}
}
(4)设置routing为必选参数



[*]对于使用routing写入的文档,在举行GET、UPDATE或DELETE操纵时如果不指定routing参数会出现异常。
[*]Elasticsearch提供了一个索引mapping级别的设置_routing.required,来强制用户在INDEX、GET、DELETE、UPDATE一个文档时必须使用routing参数。
POST my_index_2/_doc
{
"mappings": {
      "_routing": {
      "required": true
      }
}
}
4、写入优化

(1)数据批量处理



[*]**使用 Bulk API:**支持批量操纵,进步写入效率。
[*]**批量提交数据量:**默认不凌驾 100M,单次批处理数据大小从 5MB 到 15MB 逐渐增加,直到性能不再提升。
(2)减少副本数量



[*]减少副本数量:在大量写入过程中,减少副本数量可以提升写入性能,写入后再恢复原来的副本数量。
[*]修改现有索引的副本数量:对于活动的索引库,副本数量可以随时修改。可以通过以下命令将副本数量设置为0
PUT my_index/_settings
{
"index": {
    "number_of_replicas": 0
}
}


[*]修改所有索引的副本数量
PUT /_all/_settings
{
"index": {
    "number_of_replicas": 0
}
}


[*]设置索引模板:如果盼望之后创建的索引默认副本数量为0,可以设置一个索引模板。
PUT /_template/default_template
{
"index_patterns": ["*"],
"settings": {
    "number_of_replicas": 0
}
}


[*]创建索引时指定副本数量
PUT my_index
{
"settings": {
    "index": {
      "number_of_replicas": 0
    }
}
}
(3)优化 flush 设置



[*]index.translog.flush_threshold_period

[*]这个参数控制了Flush时间间隔。默认值是 30 m,加大此参数可以减少数据写入磁盘的频率,从而减少磁盘I/O频率。

PUT /_cluster/settings
{
"persistent" : {
    "index.translog.flush_threshold_period": "120m"
}
}


[*]index.translog.flush_threshold_size

[*]这个参数控制了Translog达到多大时会触发flush操纵。默认值通常是512MB。增加这个值可以减少flush操纵的频率,从而可能进步写入性能。

PUT /your_index/_settings
{
"index.translog.flush_threshold_size": "1gb"
}


[*]index.translog.sync_interval

[*]这个参数控制了Translog多久同步一次到磁盘。默认是 5 秒。增加这个值可以减少磁盘I/O,从而可能进步写入性能。

PUT /your_index/_settings
{
"index.translog.sync_interval": "30s"
}


[*]**注意:**调整这些参数可能会影响数据的安全性和查询性能。
(5)减少Refresh的次数



[*]动态调整Refresh间隔

[*]Elasticsearch默认的Refresh间隔是1秒,这意味着每秒索引会革新一次,使得新的文档可以被搜刮到。在数据导入阶段,可以增加这个间隔,例如设置为30秒,以减少Refresh操尴尬刁难性能的影响。

PUT /my_index/_settings
{
"index.refresh_interval": "30s"
}
- 数据导入完成后,可以再将Refresh间隔调回原来的值,比如1秒:
PUT /my_index/_settings
{
"index.refresh_interval": "1s"
}


[*]临时禁用Refresh:

[*]在举行大量数据写入时,可以暂时禁用主动革新,待批量索引完成后再启用。这可以通过将Refresh间隔设置为-1来实现,表示不主动革新:

PUT /my_index/_settings
{
"index.refresh_interval": "-1"
}
- 完成批量索引后,再重新启用Refresh:
PUT /my_index/_settings
{
"index.refresh_interval": "1s"
}


[*]注意:衡量性能和实时性需求
5、内存优化

(1)JVM堆内存设置

- **<font style="color:rgba(0, 0, 0, 0.9);">不超过物理内存的 50%:</font>**文件系统缓存用于处理I/O操作,建议至少将物理机一半的内存分配给文件系统缓存。例如,如果物理机内存为64GB,则至少分配32GB给文件系统缓存。
- **最大不超过32GB:**这是因为超过32GB后,JVM会启用压缩指针,导致性能下降。
- **初始堆内存和最大堆内存相同:**在`jvm.options`配置文件中设置Xms和Xmx参数,确保初始堆内存和最大堆内存相同,减少垃圾回收开销。
- **综上所述:**对于128GB内存的机器,建议配置两个Elasticsearch节点,每个节点的堆内存设置为31GB。
-Xms31g
-Xmx31g
(2)禁用Swap



[*]确保操纵体系不会将Elasticsearch历程swap出去,这会极大低落Elasticsearch的索引速度。可以通过实行sudo swapoff -a命令来禁用swap。
(3)调整索引缓存大小



[*]确保每个索引分片能获得至少512M的缓存,即indices.memory.index_buffer_size设置为512M。凌驾512M没有更多提升结果。
(4)监控内存使用环境



[*]使用Elasticsearch提供的API监控内存使用环境,例如GET _cat/nodes?h=name,*heap*,*memory*,*Cache*&format=json和GET _cat/indices/*?h=*memory*&format=json。

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
页: [1]
查看完整版本: ElasticSearch10-性能优化