当前位置:网站首页>滴滴 Elasticsearch 集群跨版本升级与平台重构之路

滴滴 Elasticsearch 集群跨版本升级与平台重构之路

2020-11-06 01:15:41 InfoQ

导读: 前不久,滴滴ES团队将维护的30多个ES集群,3500多个ES节点,8PB的数据,从2.3.3跨大版本无缝升级到6.6.1。在对用户查询写入基本零影响和改动的前提下,解决了ES跨大版本协议不兼容、文件格式不兼容、mapping不兼容等难题,整个过程对绝大部分用户完全透明。同时还完成了Arius的架构升级,取得了单机查询性能提升40%,整体集群cpu下降10%,写入tps提升30%,集群资源使用率提升20%、0故障、运维成本下降60%的成绩。

本文将系统的介绍滴滴在从2.3.3跨大版本升级到6.6.1过程中的遇到的问题和解决方案,以及在搜索平台建设过程中的体系化思考。

01 背景介绍

1. 集群规模

目前滴滴使用的ES版本是2.3.3,集群个数有40多个,节点规模有3500+,集群总容量有8PB。

2. 业务规模

1200多个平台应用方在使用ES,30多个核心应用在使用ES,写入的TPS有1500W,查询的QPS有25W。

02 问题分析

针对以上规模的ES集群,从2.3.3升级到6.X版本,小版本会根据最后分析的结果确定,需要对潜在可能的问题进行分析和区分。

1. 问题分析

主要先从四大问题域进行区分分析:

  • 引擎侧:由于从2.3.3升级到6.X版本,版本差距过大,在文件格式和协议上都不兼容,因此无法进行原地滚动直接升级,需要双写搬迁升级,这样会耗费大量的机器去参与其中
  • 用户侧:6.X版本开始逐渐的不支持TCP接口,因此需要用户适配和升级;查询和返回值也有一定差异,如果用户侧做适配,会极大影响升级的进度
  • 资源侧:由于无法直接原地滚动直接升级,需要双写使用大量的机器,但是无法提供升级所需要的机器,如果升级过程中资源无法得到保障,那也会极大影响升级的进度
  • 操作侧:新版本的多集群如何进行运维管控?升级的结果如何验证?查询的效率和质量如何保障和保证的?这些问题都需要考虑

原文链接:【https://www.infoq.cn/article/J6BFzWfJA0cbmgzN7R1w】。未经作者许可,禁止转载。

版权声明
本文为[InfoQ]所创,转载请带上原文链接,感谢
https://www.infoq.cn/article/J6BFzWfJA0cbmgzN7R1w?utm_source=rss&utm_medium=article