干货 | Elasticsearch 8.X 性能优化实战
Elasticsearch 是实现用户无缝搜索体验的关键工具。它通过提供快速、准确和相关的搜索结果,彻底改变了用户与应用程序的互动方式。然而,要确保 Elasticsearch 部署达到最佳性能,就必须关注关键指标,并对诸如索引、缓存、查询、搜索以及存储等各种组件进行优化。
在本博文中,我们将深入探讨如何调整 Elasticsearch 以实现最佳性能和发挥最大潜能的最佳实践与技巧,从优化集群健康、搜索性能和索引,到精通缓存策略和存储选项。无论你是经验丰富的 Elasticsearch 专家,还是初涉此领域的新手,遵循一些最佳实践以确保部署具备性能、可靠性和可扩展性都至关重要。
1、通用优化建议
1.1 使用合适的硬件
Elasticsearch是一个内存密集型应用程序,因此使用足够内存的硬件非常重要。此外,建议使用固态硬盘(SSD)作为存储设备,因为它们可以显著提高索引和搜索性能。
尽管 SSD 的 I/O 性能优于传统硬盘,但如果 Elasticsearch 集群中的节点数量较多,I/O 性能仍然可能成为瓶颈。为了保证性能,可以采取一些优化措施,如使用 RAID 配置、合理的磁盘划分和负载均衡等。
RAID级别 | 优点 | 缺点 | 适用场景 |
RAID 0 | 高I/O性能,实现并行读写 | 无冗余,磁盘故障可能导致数据丢失 | 性能敏感型应用,可接受数据恢复时间 |
RAID 1 | 数据冗余,磁盘故障时数据不丢失 | 写入性能不如RAID 0 | 数据安全性和可靠性较高的应用 |
RAID 5 | 数据冗余,一定程度的I/O性能优势 | 写入性能不如RAID 0 | 需要在性能和数据安全性之间取得平衡的应用 |
RAID 10 | 结合RAID 0和RAID 1的优点,高I/O性能和数据冗余 | 需要更多磁盘,成本较高 | 既需要保证性能又需要保证数据安全性的应用 |
1.2 规划索引策略
Elasticsearch设计用于处理大量数据,但需要考虑如何索引这些数据。这包括需要多少分片和副本,数据将如何索引,以及如何处理更新和删除。
- 分片数量
选择合适数量的分片以实现水平扩展和负载均衡。
默认情况下,每个索引有 1 个主分片。根据数据量和节点数量调整分片数量。尽量避免使用过多分片,因为每个分片都需要额外的资源和开销。
- 副本数量
增加副本数量以提高搜索性能和系统容错能力,但要辩证看,后文会详细解读。
默认情况下,每个分片有 1 个副本。根据负载和可用性需求调整副本数量。
- 数据索引策略
使用基于时间的索引生命周期管理策略(ILM)以提高查询性能和降低资源消耗。例如,为每天、每周或每月的数据创建一个新索引。
选择合适的字段类型和分析器。优化映射以减少存储空间和提高查询性能。
使用 Index Templates 自动应用映射和设置。
- 更新和删除处理
使用 Update API 更新文档,避免删除和重新索引整个文档。
合理使用 Elasticsearch 的版本控制特性。
考虑使用 Index Lifecycle Management (ILM) 自动管理索引的生命周期。根据具体业务需求和场景,灵活调整上述建议以优化 Elasticsearch 集群性能。
1.3 优化查询
Elasticsearch是一个功能强大的搜索引擎,但要确保查询性能优化。这包括尽可能使用过滤器而不是查询,并使用分页限制返回结果的数量。
- 使用过滤器而不是查询:
- 提高查询速度:过滤器不计算相关性得分。
- 结果可被缓存:相同过滤条件直接获取结果。
- 使用分页限制返回结果数量:
- 降低计算和传输负担:提高查询性能。
- 注意深度分页可能导致性能问题:考虑使用
search_after
参数。
优化查询性能有助于降低响应时间、提高吞吐量并确保集群在高负载下保持稳定。
1.4 保持Elasticsearch版本更新
Elasticsearch是一个活跃的项目,定期发布新版本以修复错误并提供新功能。保持版本更新至关重要,以利用这些改进并避免已知问题。
1.5 监控集群
Elasticsearch 提供了各种监控工具,如Elasticsearch Head、Kibana monitoring(优先推荐)插件,可用于监控集群的健康和性能。需要密切关注磁盘使用情况、CPU和内存使用情况以及搜索请求的数量。
在通用最佳实践的基础上,我们将深入探讨索引、查询和搜索、扩展、性能和监控等具体领域。
2、写入(索引化)优化建议
2.1 使用批量请求
Elasticsearch的批量API允许在单个API调用中执行多个索引/删除操作。这大大提高了索引速度。如果请求中的一个失败,顶层错误标志将设置为true,并在相关请求下报告错误详细信息。
使用 Elasticsearch 的批量 API 的原因:
- 提高性能
减少网络开销和连接建立时间,提高索引速度。
- 减少资源消耗
降低服务器和客户端资源消耗,提高系统效率和吞吐量。
- 错误处理
灵活且可控的错误处理方式,即使部分操作失败,其他操作仍可继续执行。
使用批量 API 可实现高效的数据索引和删除操作,同时提高系统的稳定性和可靠性。
2.2 使用多线程客户端索引数据
单个线程发送批量请求无法充分利用Elasticsearch集群的索引能力。
通过多线程或多进程发送数据,将有助于利用集群的所有资源,降低每个fsync的成本,提高性能。
2.3 增加刷新间隔(index.refresh_interval)
Elasticsearch中默认的刷新间隔为1秒,但如果搜索流量很小,可以增加此值以优化索引速度。
2.4 使用自动生成的ID
在索引具有显式ID的文档时,Elasticsearch需要检查是否已经存在具有相同ID的文档,这是一项代价高昂的操作。
使用自动生成的ID可以跳过此检查,使索引更快。
2.5 index.translog.sync_interval
此设置控制translog何时提交到磁盘,无论写操作如何。默认值为5秒,但不允许使用小于100毫秒的值。
官方文档地址:
https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-translog.html
2.6 避免大型文档
大型文档会给网络、内存使用和磁盘带来压力,导致索引速度缓慢,影响邻近搜索和高亮显示。
高亮处理推荐 fvh 高亮方式。
推荐阅读:Elasticsearch大文件检索性能提升20倍实践(干货)
2.7 显式设置映射
Elasticsearch可以动态创建映射,但并不适用于所有场景。显式设置(strict)映射将有助于确保最佳性能。
显式设置映射的优势:
- 准确的字段类型
确保查询和聚合操作正确性。
- 优化存储和性能
降低存储空间,提高查询性能。
- 避免不必要的映射更新
减少映射更新操作和性能开销。
2.8 避免使用嵌套Nested类型
虽然嵌套类型在某些场景下很有用,但它们也带来了一定的性能影响:
- 查询速度较慢
与查询非嵌套文档中的普通字段相比,查询嵌套字段速度较慢。
这是因为嵌套字段的查询需要执行额外的处理步骤,例如过滤器和关联。这可能导致较低的查询性能,特别是在处理大量数据时。
- 额外的减速
在检索匹配嵌套字段的文档时,Elasticsearch 需要对嵌套层文档进行关联。这意味着它需要将嵌套文档与其外层文档匹配,以确定哪些文档实际上包含匹配的嵌套字段。这个过程可能导致额外的性能开销,尤其是在查询结果集很大时。
为了避免嵌套类型带来的性能影响,可以考虑使用以下方法:
- 扁平化数据结构(俗成大宽表):尽可能将嵌套字段转换为扁平化的数据结构,例如使用多个普通字段表示原本的嵌套字段。
- 使用关键词类型(keyword类型):对于具有固定集合值的字段,可以使用关键词类型进行索引,以提高查询速度。
- 使用 join 类型(父子关联类型):在某些场景下,可以使用 join 类型替代嵌套类型。
但请注意,join 类型也可能导致性能问题,尤其是在需要频繁修改文档关系时。
3、查询和搜索优化建议
3.1 尽可能使用 filter 而不是 query
- query 子句用于回答“这个文档与这个子句的匹配程度如何?
- filter(过滤器)子句用于回答“这个文档是否与这个子句匹配?” Elasticsearch只需要回答“是”或“否”。它不需要为过滤器子句计算相关性得分,而且过滤器结果可以被缓存。
3.2 增加刷新间隔
增加刷新间隔有助于减少段数量,降低搜索的IO成本。
而且,一旦刷新发生并且数据发生变化,缓存就会失效。增加刷新间隔可以使Elasticsearch更有效地利用缓存。
3.3 辩证的看待增加副本数量对检索性能的影响
直接给出企业级测试结论——副本数对检索性能的影响非正相关。也就是说:不是副本越多,检索性能越高。
增加副本数量的优势:
- 负载均衡
分散查询请求负载,实现负载均衡。
- 高可用性
提高集群的可用性和容错能力。
- 并行处理
加快查询速度,提高吞吐量。
注意:增加副本数量会消耗额外的存储空间和计算资源。需根据需求和资源限制权衡副本数量。
3.4 仅检索必要字段
如果文档很大,且仅需要几个字段,请使用stored_fields仅检索所需字段,而不是所有字段。
3.5 避免通配符查询
通配符查询可能会很慢且耗资源。最好尽量避免使用它们。
替代方案:Ngram分词、设置 wildcard 数据类型。
3.6 使用节点查询缓存
过滤器上下文中使用的查询结果将缓存在节点查询缓存中,以便快速查找。
过滤器上下文查询结果缓存的优势:
- 缓存命中率
过滤器查询具有较高的缓存命中率,常在多个查询中重复使用。
- 节省计算资源
缓存结果减少重复计算,节省资源。
- 提高查询速度
缓存加速查询,特别是复杂或数据量大的过滤器查询。
- 并发查询效果更好
节点查询缓存在高并发场景下发挥作用,提高性能。
注意:需平衡缓存使用与内存消耗。对于频繁变更或低缓存命中率的查询,缓存效果可能有限。
3.7 使用分片查询缓存
可以通过将“index.requests.cache.enable”设置为true来启用分片查询缓存。
设置参考如下:
PUT /my-index-000001
{
"settings": {
"index.requests.cache.enable": false
}
}
官方文档地址:
https://www.elastic.co/guide/en/elasticsearch/reference/current/shard-request-cache.html
3.8 使用索引模板
索引模板可以帮助自动将设置和映射应用于新索引。
使用索引模板的优势:
- 一致性
确保新索引具有相同的设置和映射,实现集群一致性。
- 简化操作
自动应用预定义的设置和映射,减少手动配置。
- 易于扩展
快速创建具有相同配置的新索引,便于集群扩展。
- 版本控制和更新
实现模板版本控制,确保新索引使用最新配置。
4、性能优化建议
4.1 活动分片应与CPU成比例
活动分片=主分片+副本分片数之和。
活动分片与 CPU 成比例的原因:
- 并行处理
更多活动分片提高并行处理能力,加速查询和索引请求。与 CPU 核心数成比例确保充分利用 CPU 资源。
- 避免资源竞争
将活动分片与 CPU 核心数成比例,避免多分片竞争同一 CPU 核心,提高性能。
- 负载均衡
成比例的活动分片数有助于在多节点间分散请求,避免单节点资源瓶颈。
- 性能优化
与 CPU 核心数成比例的分片数根据可用计算资源为分片分配处理能力,优化查询和索引操作。
注意:实际部署需考虑其他因素,如内存、磁盘和网络资源等。
如前所述,为了提高写入密集型用例的性能,应将刷新间隔增加到较大的值(例如,30秒),并增加主分片以将写请求分发到不同节点。对于读取密集型用例,增加副本分片以在副本之间平衡查询/搜索请求会有所帮助。
4.2 如果查询具有日期范围 filter 过滤器,请按日期组织数据。
对于日志或监控场景,按每日、每周或每月组织索引并按指定日期范围获取索引列表可以提高性能。
Elasticsearch只需要查询较小的数据集,而不是整个数据集,而且在数据过期时缩小/删除旧索引会很容易。
负面案例:之前有客户超大规模(100TB)以上的数据没有日期格式字段或者出现字段格式不规范的问题。
4.3 如果查询具有过滤字段且其值可枚举,则将数据分割成多个索引。
如果我们的查询中包含可枚举的过滤字段(例如,地区),则可以通过将数据分割成多个索引来提高查询性能。
例如,如果数据包含来自美国、欧洲和其他地区的记录,并且经常使用“region”过滤查询,那么可以将数据分割成三个索引,每个索引包含一组地区的数据。
这样,当执行带有过滤子句“region”的查询时,Elasticsearch 只需要在包含该地区数据的索引中搜索,从而提高查询性能。
5、扩展建议
5.1 索引状态管理
定义自定义管理策略以自动执行常规任务,并将其应用于索引和索引模式。例如,可以定义一项策略,使索引在30天后进入只读状态,然后在90天后将其删除。
ILM(索引生命周期管理)是 Elasticsearch 的一项功能,可自动化索引的管理和维护,具有以下好处:
- 简化索引管理:自动化索引的生命周期管理,包括索引的创建、更新、删除和存档,减轻管理员的负担。
- 提高性能:自动优化索引设置,包括调整分片大小、缩小索引和删除过期数据等,有助于提高查询性能和减少存储空间的使用。
- 降低成本:自动归档和删除过期数据,降低存储成本,减少管理员的工作量和时间成本。
- 更好的可扩展性:根据需要自动调整索引设置和存储策略,使索引更好地适应不断增长和变化的数据。
使用 ILM 可以让索引管理变得更简单、更可靠。
5.2 快照生命周期管理
SLM(快照生命周期管理)是 Elasticsearch 的一项功能,可自动化快照的管理和维护,具有以下好处:
- 简化快照管理:自动化快照的生命周期管理,包括创建、管理、删除和清理快照,减轻管理员的负担。
- 提高效率:自动化快照的创建、管理、删除和清理,提高管理效率。
- 减少存储成本:自动删除无用的快照,降低存储成本。
- 更好的可扩展性:根据需要自动调整快照设置和存储策略,使快照更好地适应不断增长和变化的数据。
使用 SLM 可以让快照管理变得更简单、更可靠,提高管理效率和降低存储成本。
Elasticsearch 快照生命周期管理 (SLM) 实战指南
5.3 用好监控
为了监视Elasticsearch集群的性能并检测任何潜在问题,应该定期跟踪以下指标:
- 集群健康状况节点和分片:监控集群中节点的数量以及分片及其分布。
- 搜索性能:请求延迟和速率 - 跟踪搜索请求的延迟以及每秒搜索请求的数量。
- 索引性能:刷新时间和合并时间 - 监控刷新索引所需的时间以及合并段所需的时间。
- 节点利用率:线程池 - 监控每个节点上线程池的使用情况,例如索引池。
6、小结
遵循这些最佳实践,可以确保Elasticsearch部署性能高、可靠且可扩展。
请记住,Elasticsearch是一个功能强大的搜索和分析引擎,可以快速并近乎实时地处理大量数据,但是要充分利用它,需要计划、优化和监控部署。
以上建议仅供参考,实操环节以 Elasticsearch 官方文档和自己集群的性能测试结论为准。没有普适的优化建议,只有适合自己的优化才是最好的优化。
文章转载自公众号: 铭毅天下Elasticsearch