ElasticSearch批量导入的优化实践

最新推荐文章于 2024-08-19 16:27:51 发布

技术菜逼

最新推荐文章于 2024-08-19 16:27:51 发布

阅读量1.5k

点赞数

分类专栏： elasticsearch 文章标签： elasticsearch 批量导入优化

本文链接：https://blog.csdn.net/w1346561235/article/details/105771807

版权

本文介绍了ElasticSearch跨集群批量导入的三种方法，并重点分享了应用编程优化实践，包括使用slice scroll查询、bulk API导入、去掉不必要的索引、控制refresh频率、调整translog和merge设置等，通过这些策略将5000万条数据从5小时导入时间优化到1小时内。同时，文章指出在导入过程中需要注意磁盘读取高峰及其对性能的影响。

摘要由CSDN通过智能技术生成

最近在做es跨集群批量导入的优化工作，将自己get到的点总结一下。

跨集群导入有三种方法：

1，应用编程，从源集群读取，导入目标集群；这种方法的优点在于，整个导入过程的各个环节是自己编码控制的，每个环节都能做到可控，哪里有问题就可以针对性修改代码进行调优。正所谓哪里有问题点哪里。并且导出和导入是同时进行的，可以将导入程序部署在第三台机器上，充分利用各节点机器资源。但同时优点也是缺点，就是各个环节都要自己编码，需要对es有较深入的理解。

2，跨集群_reindex api；这种方法主要的优点在于简单，一个脚本搞定。其内部的实现是es自己提供的，应该说代码质量还是有保证的，导入过程中不会遇到各种奇奇怪怪的问题。省心。缺点在于，跨集群reindex不能使用多线程slice，只能单线程操作，这对扩展性是个问题。这个单线程就是整个导入性能的瓶颈。既使你的es集群后面的硬件再牛逼，对不起，用不上。

3，snapshot、restore；通过导出导入的方式进行。优点也是简单，相对较快。但是snapshot与restore两个环节是割裂的，必须串行执行，整个的导入时间需要备份时间+还原时间。如果两个es集群之间没有共享存储的话，还要加上文件copy的时间。

我的测试是5000w的数据导入，primary分片总大小175G，通过enable=false去掉各种字段索引之后，97G大小。在我的测试中，导入速度由快到慢为snapshot/restore 快于应用编程快于跨集群_reindex api。这里虽然snapshot/restore排在了第一位，但是我还是抛弃它选择了应用编程。一个原因是snapshot