# 7.2 运行时优化
# 7.2.1 索引优化建议
# 1. 设置合理的索引分片数和副本数
索引分片数建议设置为集群节点的整数倍，初始数据导入时副本数设置为 0，生产环境副本数建议设置为 1（设置 1 个副本，集群任意 1 个节点宕机数据不会丢失；设置更多副本会占用更多存储空间，操作系统缓存命中率会下降，检索性能不一定提升）。单节点索引分片数建议不要超过 3 个，每个索引分片推荐 10-40GB 大小，索引分片数设置后不可以修改，副本数设置后可以修改。 Elasticsearch6.X 及之前的版本默认索引分片数为 5、副本数为 1，从 Elasticsearch7.0 开始调整为默认索引分片数为 1、副本数为 1。
# 2. 索引使用前先做好映射
Elasticsearch可以动态创建映射，但并不适用于所有场景。先做好映射将有助于确保最佳性能。
# 7.2.2 写入优化建议
# 1. 使用批量请求
Elasticsearch的批量API允许在单个API调用中执行多个索引/删除操作。这大大提高了索引速度。
# 2. 使用多线程客户端索引数据
单个线程发送批量请求无法充分利用Elasticsearch集群的索引能力。通过多线程或多进程发送数据，将有助于利用集群的所有资源，降低每个fsync的成本，提高性能。
# 3. 增加刷新间隔
Elasticsearch中默认的刷新间隔为1秒，但如果搜索流量很小，可以增加此值以优化索引速度。
# 4. 使用自动生成的ID
在索引具有显式ID的文档时，Elasticsearch需要检查是否已经存在具有相同ID的文档，这是一项代价高昂的操作。使用自动生成的ID可以跳过此检查，使索引更快。
# 5. 配置事务日志参数
事务日志 translog 用于防止节点失败时的数据丢失。它的设计目的是帮助 shard 恢复操作，否则数据可能会从内存 flush 到磁盘时发生意外而丢失。事务日志 translog 的落盘(fsync)是 ES 在后台自动执行的，默认每 5 秒钟提交到磁盘上，或者当 translog 文件大小大于 512MB 提交，或者在每个成功的索引、删除、更新或批量请求时提交。 索引创建时，可以调整默认日志刷新间隔 5 秒，例如改为 60 秒，index.translog.sync_interval: “60s”。创建索引后，可以动态调整 translog 参数，“index.translog.durability”:“async” 相当于关闭了 index、bulk 等操作的同步 flush translog 操作，仅使用默认的定时刷新、文件大小阈值刷新的机制。
# 6. 避免大型文档
大型文档会给网络、内存使用和磁盘带来压力，导致索引速度缓慢，影响邻近搜索和高亮显示。
# 7.2.3 查询优化建议
# 1. 尽量使用 filter
区别如下：
- query 子句用于回答“这个文档与这个子句的匹配程度如何？
- filter（过滤器）子句用于回答“这个文档是否与这个子句匹配？” Elasticsearch只需要回答“是”或“否”。它不需要为过滤器子句计算相关性得分，而且过滤器结果可以被缓存。
# 2. 增加刷新间隔
增加刷新间隔有助于减少段数量，降低搜索的IO成本。而且，一旦刷新发生并且数据发生变化，缓存就会失效。增加刷新间隔可以使Elasticsearch更有效地利用缓存。
# 3. 合理设置副本数
合理增加副本数量会增加读性能，过多会导致性能下降。增加副本数量会消耗额外的存储空间和计算资源。需根据需求和资源限制权衡副本数量。
# 4. 仅检索必要字段
如果文档很大，且仅需要几个字段，请使用stored_fields仅检索所需字段，而不是所有字段。
# 5. 避免通配符查询
通配符查询可能会很慢且耗资源。最好尽量避免使用它们。
替代方案：Ngram分词。
# 6. 使用节点查询缓存
过滤器上下文中使用的查询结果将缓存在节点查询缓存中，以便快速查找。
过滤器上下文查询结果缓存的优势：
- 缓存命中率
过滤器查询具有较高的缓存命中率，常在多个查询中重复使用。
- 节省计算资源
缓存结果减少重复计算，节省资源。
- 提高查询速度
缓存加速查询，特别是复杂或数据量大的过滤器查询。
- 并发查询效果更好
节点查询缓存在高并发场景下发挥作用，提高性能。
注意：需平衡缓存使用与内存消耗。对于频繁变更或低缓存命中率的查询，缓存效果可能有限。
# 7. 使用分片查询缓存
可以通过将index.requests.cache.enable设置为true来启用分片查询缓存。