优化ElasticSearch写入效率

栏目: 后端 · 发布时间: 6年前

内容简介:最近在做日志搜集系统,涉及到Kafka到ES的数据解析写入,但是Kafka的写入效率远远高于ES,造成大量的数据在Kafka中积累,且ES的数据更新非常缓慢,最终造成了在Kibana中查询的时候发现,ES中的数据有接近9个小时的数据延迟,这显然是不可接受的。因此,必须着手优化ES的写入效率。在尽可能不改变已有配置的情况下,写入效率优先可以考虑以下两点。一开始我们的解析器是通过单条数据的形式提交的数据,很明显这种方式在大数据量的时候就越来越慢,因此我们必须修改为批量提交的方式。ES的bulk提交有个限制就是

最近在做日志搜集系统,涉及到Kafka到ES的数据解析写入,但是Kafka的写入效率远远高于ES,造成大量的数据在Kafka中积累,且ES的数据更新非常缓慢,最终造成了在Kibana中查询的时候发现,ES中的数据有接近9个小时的数据延迟,这显然是不可接受的。因此,必须着手优化ES的写入效率。在尽可能不改变已有配置的情况下,写入效率优先可以考虑以下两点。

必须使用bulk方式提交写入数据

一开始我们的解析器是通过单条数据的形式提交的数据,很明显这种方式在大数据量的时候就越来越慢,因此我们必须修改为批量提交的方式。ES的bulk提交有个限制就是一次性提交的数据量不能超过15MB,因此,在考虑一次性提交多少条数据比较合适的时候,这个参数无比重要。根据分析,我们目前的数据量一次性bulk提交5000条数据比较合适,约为5-6MB的样子。当然不是越多越好,也不是满满地一定要达到15MB的限制,那样的风险太大,对于我们来讲,能够提升速率满足需求即可。并且我们的程序优化过后能够满足随时根据参数调整bulk请求数量的参数。我们的k8s中对应的容器配置是这样的:

优化ElasticSearch写入效率

可根据实际情况调整bulk queue size

bulk queue size是ES的数据处理队列大小,由于ES在接收到数据之后需要做一些索引处理,因此需要将接收到的请求暂放到队列中进行缓冲处理,这个队列默认的值是根据机器的配置动态计算的,一般为200左右。为什么说要根据实际情况来调整呢?因为默认情况下,200左右的队列大小已经够用,比如我们现在的情况客户端配置的队列大小只有50。当然并发量实在是太大的时候,可以适当调整这个参数。需要在配置文件 elasticsearch.yml 中增加以下配置:

thread_pool.bulk.queue_size: 5000

其他一些临时修改方案

主要是2个参数:index.refresh_interval 和 index.number_of_replicas 。为什么说是临时修改方案呢?因为这些方案需要修改索引配置,并且不能长期保持该方案运行,否则会引起稳定性的问题,必须在适当时候再调整回来。参考官方文档: https://www.elastic.co/guide/en/elasticsearch/guide/current/indexing-performance.html

参考链接:

https://blog.csdn.net/jiao_fuyou/article/details/78518209


以上所述就是小编给大家介绍的《优化ElasticSearch写入效率》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

SRE

SRE

贝特西 拜尔 (Betsy Beyer)、等 / 孙宇聪 / 电子工业出版社 / 2016-10-1 / CNY 108.00

大型软件系统生命周期的绝大部分都处于“使用”阶段,而非“设计”或“实现”阶段。那么为什么我们却总是认为软件工程应该首要关注设计和实现呢?在《SRE:Google运维解密》中,Google SRE的关键成员解释了他们是如何对软件进行生命周期的整体性关注的,以及为什么这样做能够帮助Google成功地构建、部署、监控和运维世界上现存最大的软件系统。通过阅读《SRE:Google运维解密》,读者可以学习到......一起来看看 《SRE》 这本书的介绍吧!

随机密码生成器
随机密码生成器

多种字符组合密码

XML 在线格式化
XML 在线格式化

在线 XML 格式化压缩工具

UNIX 时间戳转换
UNIX 时间戳转换

UNIX 时间戳转换