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 数据类型。
Elasticsearch 警惕使用 wildcard 检索！然后呢？
3.6 使用节点查询缓存
过滤器上下文中使用的查询结果将缓存在节点查询缓存中，以便快速查找。
过滤器上下文查询结果缓存的优势：
缓存命中率
过滤器查询具有较高的缓存命中率，常在多个查询中重复使用。
节省计算资源
缓存结果减少重复计算，节省资源。
提高查询速度
缓存加速查询，特别是复杂或数据量大的过滤器查询。
并发查询效果更好
节点查询缓存在高并发场景下发挥作用，提高性能。
注意：需平衡缓存使用与内存消耗。对于频繁变更或低缓存命中率的查询，缓存效果可能有限。
Elasticsearch 缓存深入详解
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 可以让索引管理变得更简单、更可靠。
干货 | Elasticsearch 索引生命周期管理 ILM 实战指南
Elasticsearch ILM 索引生命周期管理常见坑及避坑指南
5.2 快照生命周期管理
SLM（快照生命周期管理）是 Elasticsearch 的一项功能，可自动化快照的管理和维护，具有以下好处：
简化快照管理：自动化快照的生命周期管理，包括创建、管理、删除和清理快照，减轻管理员的负担。
提高效率：自动化快照的创建、管理、删除和清理，提高管理效率。
减少存储成本：自动删除无用的快照，降低存储成本。
更好的可扩展性：根据需要自动调整快照设置和存储策略，使快照更好地适应不断增长和变化的数据。
使用 SLM 可以让快照管理变得更简单、更可靠，提高管理效率和降低存储成本。
Elasticsearch 快照生命周期管理 (SLM) 实战指南
5.3 用好监控
为了监视Elasticsearch集群的性能并检测任何潜在问题，应该定期跟踪以下指标：
集群健康状况节点和分片：监控集群中节点的数量以及分片及其分布。
搜索性能：请求延迟和速率 - 跟踪搜索请求的延迟以及每秒搜索请求的数量。
索引性能：刷新时间和合并时间 - 监控刷新索引所需的时间以及合并段所需的时间。
节点利用率：线程池 - 监控每个节点上线程池的使用情况，例如索引池。
6、小结
遵循这些最佳实践，可以确保Elasticsearch部署性能高、可靠且可扩展。
请记住，Elasticsearch是一个功能强大的搜索和分析引擎，可以快速并近乎实时地处理大量数据，但是要充分利用它，需要计划、优化和监控部署。
以上建议仅供参考，实操环节以 Elasticsearch 官方文档和自己集群的性能测试结论为准。没有普适的优化建议，只有适合自己的优化才是最好的优化。
推荐阅读
全网首发！从 0 到 1 Elasticsearch 8.X 通关视频
重磅 | 死磕 Elasticsearch 8.X 方法论认知清单
如何系统的学习 Elasticsearch ？
2023，做点事
JMeter 如何实现 Elasticsearch 8.X 性能测试？
Elasticsearch 检索性能优化实战指南
让Elasticsearch飞起来!——性能优化实践干货
Elasticsearch性能优化实战指南
Elasticsearch 聚合性能优化六大猛招
esrally 如何进行简单的自定义性能测试？
更短时间更快习得更多干货！
和全球 近2000+ Elastic 爱好者一起精进！
比同事抢先一步学习进阶干货！
