ES 搜索优化提升性能

痛定思痛。 2023-02-15 01:26 9阅读 0赞

众所周知，ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，功能非常强大。

在实际生成中，用的最多的也就是搜索，那么如何让搜索性能最大化，也是我们应该深入研究的方面。

下面本文将针对一些常规的地方讲诉一些优化技巧，主要从设计、通信、设备几个方面，涉及数据结构、磁盘I/O、CPU性能、网络通信开销、内存资源等

# **1.为文件系统cache预留足够的内存。** #

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

# **2.预索引数据** #

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

比如:将原本数据在存入的时候加入price\_range字段用于搜索（注：需要需求比较明确，会占用空间，典型的空间换时间）

![2020061509354960.png][]

搜索的时候就可以使用该字段（price\_range）进行聚合

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmd4dWVsZWkwMzY_size_16_color_FFFFFF_t_70][]

# **3.为只读索引执行force-merge** #

为不再更新得只读索引执行force merge,将Lucene索引整合为单个分片，可以提升查询数据。当一个Lucene索引存在多个分段时，每个分段会单独执行搜索再将结果合并，将只读索引强制合并为一个Lucene分段不仅可以优化搜索过程，对索引恢复速度也有好处。

基于如期进行轮询得索引的旧一般都不会再更新。例如：像每天生成一个新索引，然后用别名关联，或者使用索引通配符。这种，可以每天选一个时间对昨天的索引执行force-merge,Shrink等操作。

# **4.预热指定搜索** #

在某些情况下，比如将要搞某活动，我们也许能遇见某些搜索QPS会很高，我们可以提前自己将该类搜索进行预热，让ES将相应的文档以及数据缓存提前载入到缓存内存中。

# **5.调节搜索请求中的batched\_reduce\_size** #

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

# **6.优化日期搜索** #

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmd4dWVsZWkwMzY_size_16_color_FFFFFF_t_70 1][]

在上例，我们将日期四舍五入到分组，因此如果当前时间是16：31：29.那么range查询将匹配my\_date字段的值在15：31~16：31.如果几个用户同时运行一个包含此范围的查询，则查询缓存可以加快查询，用于舍入的时间间隔越长，查询缓存就越有帮助（注:太高的舍入也有可能造成用户体验丢失）

当然如果为了能够利用查询缓存，可以很容易将范围分割城一个大的可缓存部分和一个小的不可换乘部分

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmd4dWVsZWkwMzY_size_16_color_FFFFFF_t_70 2][]

篇幅过程，省略部分的反括号，这样的做法可能在某些情况下运行得更慢，因为bool查询引入得开销可能会册小利用查询缓存所节省得开销

# **7.优化es的线程池 ** #

cache：这是无限制的线程池，为每个传入的请求创建一个线程。

fixed：这是一个有着固定大小的线程池，大小由size属性指定，允许你指定一个队列（使用queue\_size属性指定）用来保存请求，直到有一个空闲的线程来执行请求。如果Elasticsearch无法把请求放到队列中（队列满了），该请求将被拒绝。有很多线程池（可以使用type属性指定要配置的线程类型），然而，对于性能来说，最重要的是下面几个。

index：此线程池用于索引和删除操作。它的类型默认为fixed，size默认为可用处理器的数量，队列的size默认为300。

search：此线程池用于搜索和计数请求。它的类型默认为fixed，size默认为可用处理器的数量乘以3，队列的size默认为1000。

suggest：此线程池用于建议器请求。它的类型默认为fixed，size默认为可用处理器的数量，队列的size默认为1000。

get：此线程池用于实时的GET请求。它的类型默认为fixed，size默认为可用处理器的数量，队列的size默认为1000。

bulk：你可以猜到，此线程池用于批量操作。它的类型默认为fixed，size默认为可用处理器的数量，队列的size默认为50。

percolate：此线程池用于预匹配器操作。它的类型默认为fixed，size默认为可用处理器的数量，队列的size默认为1000。

elasticsearch.yml中可以设置 ：

threadpool.index.type: fixed threadpool.index.size: 100 threadpool.index.queue\_size: 500

# **8.更快的硬件** #

这一点很明确，ES写入性能对CPU的性能更加敏感，而搜索性能在一般情况下更多的是在于I/O能力，使用SSD会比旋转类存储介质好得多。尽量避免使用NFS等远程文件系统，如果NFS比本地存储慢3倍，则在搜索场景下响应速度可能会慢10倍作用。这可能是因为搜索请求有更多的随机访问。

如果搜索类型属于计算比较多，考虑使用更快的CPU。

# **9.文档模型** #

为了让搜索时的成本更低，文档应该合理建模。特别是应该比秒join操作，嵌套（nested）会使查询慢几倍，父子（parent-child）关系可能使查询慢数百倍，因此，如果可以通过非规范化（denormalizing）文档来回答相同的问题，则可以显著地提高搜索速度

# **10.字段映射** #

有些字段的内容是数值，但并不意味着其总是应该被映射为数值类型，例如，一些标识符，将它们映射为keyword可能会比integer或long更好。

# **11.避免使用脚本** #

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

# **12.预热全局序号（global ordinals）** #

全局序号是一种数据结构，用于再keyword字段上运行terms聚合。它用一个数值来代表字段中的字符串然后为每一数值分配一个bucket。这需要一个对global ordinals 和 bucket的构建过程。默认情况下，它们被延迟构造，因为ES不知道哪些字段将用于terms聚合，哪些字段不会。可以通过配置映射再刷新（refresh）时告诉ES预先加载全局序号：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmd4dWVsZWkwMzY_size_16_color_FFFFFF_t_70 3][]

# **13.execution hint** #

terms聚合有两种不同的机制：

通过直接使用字段来聚合每个桶的数据（map）

通过使用字段的全局序号并为每个全局序号分配一个bucket（global\_ordinals）

ES使用global\_ordinals作为keyword字段的默认选项，它使用全局序号动态地分配bucket,因此内存使用与聚合结果中的字段数量是线性关系。大部分情况下，这种方式的速度很快。

当查询只会匹配少量文档时，可以考虑使用map。默认情况下，map只再脚本上运行聚合时使用，因为它们没有序号。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmd4dWVsZWkwMzY_size_16_color_FFFFFF_t_70 4][]

# **14.预加热cache** #

如果ES主机重启，则文件系统缓存将为空，此时搜索会比较慢，可以使用index.store.preload设置，通过执行文件扩展名，显式地告诉操作系统应该将文件加载到内存，

例如，配置到elasticsearch.yml文件中

![2020061510133347.png][]

或者在创建索引时设置：

![20200615101359694.png][]

如果文件系统缓存不够大，则无法保存所有数据，那么为太多文件预加载数据到文件系统缓存中会使搜索速度缓慢

# **15.转换查询表达式** #

在组合查询中可以通过bool过滤器进行and,or和not的多个逻辑组合检索，这种组合查询的表达式在下面的情况下可以做等价转换：

![20200615101801913.png][]

# **16.使用近似聚合** #

近似聚合是以少量的精度为代价，大幅度提高执行效率，降低了内存使用。近似聚合的使用方式可以参考官方手册

# **17.深度优先还是广度优先** #

ES 有两种不同的聚合方式：深度优先和广度优先。深度优先是默认设置，先构建完整的树，然后修剪无用节点。大多数情况下深度聚合都能 正常工作，但是有些特殊的场景更适合广度优先，先执行第一层聚合，再继续下一层聚合之前会先做修剪。

# **18.限制搜索请求的分片数** #

一个搜索请求涉及的分片数量越多，协调节点的CPU内存压力就越大。默认情况下，ES 会拒绝超过1000个分片的搜索请求。我们应该更好地组长数据，让搜索请求的分片数更下。如果向调节这个值，则可以通过action.search.shard\_count进行修改。

虽然限制了分片数并不能直接提升单个搜索请求的速度，但协调节点的压力会间接影响搜索速度。

# **19.利用自适应副本选择（ARS）提升ES响应速度** #

为了充分利用计算机资源和负载均衡，协调节点将搜索轮询转发到分片的每个副本，轮询策略是负载均衡中最简单的策略，任何一个负载均衡器都具有这种基础的策略，缺点是不考虑后端实际系统压力和健康水平。

ES希望搜索请求足够智能，提出了ARS负载策略，大致为：对每个搜索请求，将分片的每个副本进行排序，以确定哪个最可能是转发请求的“最佳”副本。与轮询方式向分片的每个副本发送请求不同，ES选择“最佳”副本并将请求路由到那里。

ES 7.0开始，ARS将默认开启。

[2020061509354960.png]: https://img-blog.csdnimg.cn/2020061509354960.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmd4dWVsZWkwMzY_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200615093504512.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmd4dWVsZWkwMzY=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmd4dWVsZWkwMzY_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200615094029167.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmd4dWVsZWkwMzY=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmd4dWVsZWkwMzY_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200615100052125.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmd4dWVsZWkwMzY=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmd4dWVsZWkwMzY_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20200615100821735.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmd4dWVsZWkwMzY=,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmd4dWVsZWkwMzY_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20200615101156110.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dhbmd4dWVsZWkwMzY=,size_16,color_FFFFFF,t_70
[2020061510133347.png]: https://img-blog.csdnimg.cn/2020061510133347.png
[20200615101359694.png]: https://img-blog.csdnimg.cn/20200615101359694.png
[20200615101801913.png]: https://img-blog.csdnimg.cn/20200615101801913.png