亿级Elasticsearch性能优化已关闭评论
168 views

A+

【摘要】最近一年使用 Elasticsearch 完成亿级别日志搜索平台「ELK」，亿级别的分布式跟踪系统。在设计这些系统的过程中，底层都是采用 Elasticsearch 来做数据的存储，并且数据量都超过亿级别，甚至达到百亿级别。所以趁着有空，就花点时间整理一下具体怎么做 Elasticsearch 性能优化，希望能对 Elasticsearch 感兴趣的同学有所帮助。

亿级Elasticsearch性能优化

前言

最近一年使用 Elasticsearch 完成亿级别日志搜索平台「ELK」，亿级别的分布式跟踪系统。在设计这些系统的过程中，底层都是采用 Elasticsearch 来做数据的存储，并且数据量都超过亿级别，甚至达到百亿级别。

所以趁着有空，就花点时间整理一下具体怎么做 Elasticsearch 性能优化，希望能对 Elasticsearch 感兴趣的同学有所帮助。

背景

Elasticsearch 是一个基于 Lucene 的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于 RESTful web 接口。Elasticsearch 是用 Java 开发的，并作为 Apache 许可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。

作为一个开箱即用的产品，在生产环境上线之后，我们其实不一定能确保其的性能和稳定性。如何根据实际情况提高服务的性能，其实有很多技巧。

下面我就从三个方面分别来讲解下优化服务的性能：

索引效率优化
查询效率优化
JVM 配置优化

索引效率优化

索引优化主要是在 Elasticsearch 插入层面优化，如果瓶颈不在这块，而是在产生数据部分，比如 DB 或者 Hadoop 上，那么优化方向就需要改变下。同时，Elasticsearch 本身索引速度其实还是蛮快的，具体数据，我们可以参考官方的 benchmark 数据。

批量提交

当有大量数据提交的时候，建议采用批量提交。

比如在做 ELK 过程中，Logstash indexer 提交数据到 Elasticsearch 中，batch size 就可以作为一个优化功能点。但是优化 size 大小需要根据文档大小和服务器性能而定。

像 Logstash 中提交文档大小超过 20MB ，Logstash 会请一个批量请求切分为多个批量请求。

如果在提交过程中，遇到 EsRejectedExecutionException 异常的话，则说明集群的索引性能已经达到极限了。这种情况，要么提高服务器集群的资源，要么根据业务规则，减少数据收集速度，比如只收集 Warn、Error 级别以上的日志。

优化硬件

优化硬件设备一直是最快速有效的手段。

在经济压力能承受的范围下，尽量使用固态硬盘 SSD。SSD 相对于机器硬盘，无论随机写还是顺序写，都较大的提升。
磁盘备份采用 RAID0。因为 Elasticsearch 在自身层面通过副本，已经提供了备份的功能，所以不需要利用磁盘的备份功能，同时如果使用磁盘备份功能的话，对写入速度有较大的影响。

增加 Refresh 时间间隔

为了提高索引性能，Elasticsearch 在写入数据时候，采用延迟写入的策略，即数据先写到内存中，当超过默认 1 秒（index.refresh_interval）会进行一次写入操作，就是将内存中 segment 数据刷新到操作系统中，此时我们才能将数据搜索出来，所以这就是为什么 Elasticsearch 提供的是近实时搜索功能，而不是实时搜索功能。

当然像我们的内部系统对数据延迟要求不高的话，我们可以通过延长 refresh 时间间隔，可以有效的减少 segment 合并压力，提供索引速度。在做全链路跟踪的过程中，我们就将 index.refresh_interval 设置为 30s，减少 refresh 次数。

同时，在进行全量索引时，可以将 refresh 次数临时关闭，即 index.refresh_interval 设置为 -1，数据导入成功后再打开到正常模式，比如 30s。

减少副本数量

Elasticsearch 默认副本数量为 3 个，虽然这样会提高集群的可用性，增加搜索的并发数，但是同时也会影响写入索引的效率。

在索引过程中，需要把更新的文档发到副本节点上，等副本节点生效后在进行返回结束。使用 Elasticsearch 做业务搜索的时候，建议副本数目还是设置为 3 个，但是像内部 ELK 日志系统、分布式跟踪系统中，完全可以将副本数目设置为 1 个。

查询效率优化

路由

当我们查询文档的时候，Elasticsearch 如何知道一个文档应该存放到哪个分片中呢？它其实是通过下面这个公式来计算出来

shard = hash(routing) % number_of_primary_shards

routing 默认值是文档的 id，也可以采用自定义值，比如用户 id。

不带 routing 查询

在查询的时候因为不知道要查询的数据具体在哪个分片上，所以整个过程分为 2 个步骤

分发：请求到达协调节点后，协调节点将查询请求分发到每个分片上。
聚合: 协调节点搜集到每个分片上查询结果，在将查询的结果进行排序，之后给用户返回结果。

带 routing 查询

查询的时候，可以直接根据 routing 信息定位到某个分配查询，不需要查询所有的分配，经过协调节点排序。

向上面自定义的用户查询，如果 routing 设置为 userid 的话，就可以直接查询出数据来，效率提升很多。

Filter VS Query

Ebay 曾经分享过他们使用 Elasticsearch 的经验中说到：

Use filter context instead of query context if possible.
尽可能使用过滤器上下文（Filter）替代查询上下文（Query

Query：此文档与此查询子句的匹配程度如何？
Filter：此文档和查询子句匹配吗？

Elasticsearch 针对 Filter 查询只需要回答「是」或者「否」，不需要像 Query 查询一下计算相关性分数，同时 Filter 结果可以缓存。

大翻页

在使用 Elasticsearch 过程中，应尽量避免大翻页的出现。

正常翻页查询都是从 From 开始 Size 条数据，这样就需要在每个分片中查询打分排名在前面的 From + Size 条数据。协同节点收集每个分配的前 From + Size 条数据。协同节点一共会受到 N * （ From + Size ）条数据，然后进行排序，再将其中 From 到 From + Size 条数据返回出去。

如果 From 或者 Size 很大的话，导致参加排序的数量会同步扩大很多，最终会导致 CPU 资源消耗增大。

可以通过使用 Elasticsearch scroll 和 scroll-scan 高效滚动的方式来解决这样的问题。具体写法，可以参考 Elasticsearch: 权威指南 - scroll 查询