本篇内容主要讲解“ElasticSearch的一站式搜索实例分析”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“ElasticSearch的一站式搜索实例分析”吧!
ElasticSearch 在滴滴的应用场景
滴滴自 2016 年 4 月开始组建团队,解决 ElasticSearch 在使用过程中遇到的性能问题。搜索平台的建设是随着业务体量的发展逐步演进的,如今已经发展到有超过 3500+ ElasticSearch 实例, 5PB 的数据存储,峰值写入 TPS 超过了 2000W/S 的超大规模,每天近 10 亿次检索查询。
ElasticSearch 在滴滴有着非常丰富的应用场景:
不同场景业务方对写入的及时性、查询的 RT、整体稳定性的要求都是不一样的,我们对平台提供的服务抽象为索引模板服务,用户可以自助开通相应的服务。
我们内部经过压测、线上调优以及引擎的一些优化,已经将最佳实践,沉淀到标准的 Docker 镜像中,个性化的需求都在索引模板的服务级别进行设置与管控,部分优化如下:
平台稳定性面临的风险与挑战
超大的集群规模和丰富的场景给滴滴 ElasticSearch 平台带来了极大的风险与挑战。主有以下几个方面:
线上业务场景
准线上业务场景
离线快速导入时效性要求分钟级,实时导入 10 亿条数据需要 5 个小时,导入时在线资源消耗严重,线上服务基本不可用,导入成本消耗过大;
安全与日志场景
那么,如何解决这些问题呢?欢迎到 QCon 全球软件开发大会(广州站)现场与我面对面交流。
如何打造“存储成本低”的搜索中台
目前,在日志与安全分析场景下,存储成本压力很大,属于典型的“写多查少”的场景,我们对存储成本的耗散点进行了深入的分析,整体情况如下:
针对资源耗散点,我们在架构层面进行了优化,整体成本降低了 30%,累积节省了 2PB 的存储,分别从以下几个方面进行了优化
存储索引分离:日志原文与索引进行分开存储
不合理的索引字段 Mapping 自动优化
冷热数据进行了分级存储
ES On Docker&Ceph 改造
未来发展规划
基于 ElasticSearch 的搜索中台给用户带来的收益
服务了超过 1200+ 平台业务方,其中 20+ 线上 P0 级应用,200+ 准实时应用;
索引服务接入效率从原来的两周降低到 5 分钟;
服务稳定性有保障:线上场景 99.99%,日志场景 99.95%;
高频运维操作一键自助完成,90% 的问题,5 分钟完成定位;
整体存储成本是业内云厂商的 1/3。
不足点
目前滴滴 90% 的集群还是在 ElasticSearch 2.3.3 版本,内部修复的 BUG 与优化,无法跟社区进行同步;
目前通过 ES-GateWay 的方式支持了多集群方案很好的满足了业务发展的需求,但是集群变多之后的,版本维护与升级、整体资源利用率提升、容量规划都变得非常艰难。
发展规划
解架构之“熵”
提引擎迭代效率
聚焦价值问题
到此,相信大家对“ElasticSearch的一站式搜索实例分析”有了更深的了解,不妨来实际操作一番吧!这里是编程之家网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!