死磕elasticsearch(七)搜索速度优化

文章目录

  • 1 为文件系统cache预留足够的内存
  • 2 使用更快的硬件
  • 3 文档模型
  • 4 预索引数据
  • 5 避免使用脚本
  • 6 优化日期搜索
  • 7 为只读索引执行force-merge
  • 8 预热文件系统cache
  • 9 调节搜索请求中的batched_reduce_size
  • 10 利用自适应副本选择(ARS)提升ES响应速 度

1 为文件系统cache预留足够的内存

    在一般情况下,应用程序的读写都会被操作系统“cache”(除了 direct方式),cache保存在系统物理内存中(线上应该禁用swap),命中 cache可以降低对磁盘的直接访问频率。搜索很依赖对系统 cache 的命中,如果某个请求需要从磁盘读取数据,则一定会产生相对较高的延 迟。应该至少为系统cache预留一半的可用物理内存,更大的内存有更 高的cache命中率。

2 使用更快的硬件

    写入性能对CPU的性能更敏感,而搜索性能在一般情况下更多的是 在于I/O能力

  1. 使用SSD会比旋转类存储介质好得多。
  2. 尽量避免使用 NFS 等远程文件系统,如果 NFS 比本地存储慢3倍,则在搜索场景下响 应速度可能会慢10倍左右。
        这可能是因为搜索请求有更多的随机访问。 如果搜索类型属于计算比较多,则可以考虑使用更快的CPU。

3 文档模型

    为了让搜索时的成本更低,文档应该合理建模。特别是应该避免:

	join操作,嵌套(nested)会使查询慢几倍。
	父子(parent-child)关系可能使查询慢数百倍。

    因此,如果可以通过非规范化(denormalizing)文 档来回答相同的问题,则可以显著地提高搜索速度。

4 预索引数据

    还可以针对某些查询的模式来优化数据的索引方式。例如,如果所 有文档都有一个 price字段,并且大多数查询在一个固定的范围上运行 range聚合,那么可以通过将范围“pre-indexing”到索引中并使用terms聚 合来加快聚合速度。

5 避免使用脚本

    一般来说,应该避免使用脚本。如果一定要用,则应该优先考虑 painless和expressions。

6 优化日期搜索

    在使用日期范围检索时,使用now的查询通常不能缓存,因为匹配 到的范围一直在变化。但是,从用户体验的角度来看,切换到一个完整的日期通常是可以接受的,这样可以更好地利用查询缓存。

7 为只读索引执行force-merge

    为不再更新的只读索引执行force merge,将Lucene索引合并为单个 分段,可以提升查询速度。当一个Lucene索引存在多个分段时,每个分段会单独执行搜索再将结果合并,将只读索引强制合并为一个Lucene分 段不仅可以优化搜索过程,对索引恢复速度也有好处。
    基于日期进行轮询的索引的旧数据一般都不会再更新。此前的章节 中说过,应该避免持续地写一个固定的索引,直到它巨大无比,而应该 按一定的策略,例如,每天生成一个新的索引,然后用别名关联,或者 使用索引通配符。这样,可以每天选一个时间点对昨天的索引执行 force-merge、Shrink等操作。

8 预热文件系统cache

    如果ES主机重启,则文件系统缓存将为空,此时搜索会比较慢。可 以使用index.store.preload设置,通过指定文件扩展名,显式地告诉操作 系统应该将哪些文件加载到内存中。
    如果文件系统缓存不够大,则无法保存所有数据,那么为太多文件 预加载数据到文件系统缓存中会使搜索速度变慢,应谨慎使用。

9 调节搜索请求中的batched_reduce_size

    该字段是搜索请求中的一个参数。默认情况下,聚合操作在协调节 点需要等所有的分片都取回结果后才执行,使用 batched_reduce_size 参 数可以不等待全部分片返回结果,而是在指定数量的分片返回结果之后 就可以先处理一部分(reduce)。这样可以避免协调节点在等待全部结 果的过程中占用大量内存,避免极端情况下可能导致的OOM。该字段 的默认值为512,从ES 5.4开始支持。

10 利用自适应副本选择(ARS)提升ES响应速 度

    为了充分利用计算资源和负载均衡,协调节点将搜索请求轮询转发 到分片的每个副本,轮询策略是负载均衡过程中最简单的策略,任何一 个负载均衡器都具备这种基础的策略,缺点是不考虑后端实际系统压力 和健康水平。
    例如,一个分片的三个副本分布在三个节点上,其中Node2可能因 为长时间GC、磁盘I/O过高、网络带宽跑满等原因处于忙碌状态,如下图所示。
死磕elasticsearch(七)搜索速度优化_第1张图片
如果搜索请求被转发到副本2,则会看到相对于其他分片来说,副 本2有更高的延迟。 · 分片副本1:100ms。
· 分片副本2(degraded):1350ms。
· 分片副本3:150ms。
由于副本2的高延迟,使得整个搜索请求产生长尾效应。
    ES希望这个过程足够智能,能够将请求路由到其他数据副本,直到 该节点恢复到足以处理更多搜索请求的程度。在ES中,此过程称为“自 适应副本选择”。
    ES的ARS实现基于这样一个设定:对每个搜索请求,将分片的每个 副本进行排序,以确定哪个最可能是转发请求的“最佳”副本。与轮询方 式向分片的每个副本发送请求不同,ES选择“最佳”副本并将请求路由到那里。

你可能感兴趣的:(Elasticsearch)