亿级 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 查询
JVM 设置
32G 现象
Elasticsearch 默认安装后设置的堆内存是 1 GB。 对于任何一个业务部署来说, 这个设置都太小了。
比如机器有 64G 内存,那么我们是不是设置的越大越好呢?
其实不是的。
主要 Elasticsearch 底层使用 Lucene。Lucene 被设计为可以利用操作系统底层机制来缓存内存数据结构。 Lucene 的段是分别存储到单个文件中的。因为段是不可变的,这些文件也都不会变化,这是对缓存友好的,同时操作系统也会把这些段文件缓存起来,以便更快的访问。
如果你把所有的内存都分配给 Elasticsearch 的堆内存,那将不会有剩余的内存交给 Lucene。 这将严重地影响全文检索的性能。
标准的建议是把 50% 的可用内存作为 Elasticsearch 的堆内存,保留剩下的 50%。当然它也不会被浪费,Lucene 会很乐意利用起余下的内存。
同时了解过 ES 的同学都听过过「不要超过 32G」的说法吧。
其实主要原因是 :JVM 在内存小于 32 GB 的时候会采用一个内存对象指针压缩技术。
在 Java 中,所有的对象都分配在堆上,并通过一个指针进行引用。 普通对象指针(OOP)指向这些对象,通常为 CPU 字长 的大小:32 位或 64 位,取决于你的处理器。指针引用的就是这个 OOP 值的字节位置。
对于 32 位的系统,意味着堆内存大小最大为 4 GB。对于 64 位的系统, 可以使用更大的内存,但是 64 位的指针意味着更大的浪费,因为你的指针本身大了。更糟糕的是, 更大的指针在主内存和各级缓存(例如 LLC,L1 等)之间移动数据的时候,会占用更多的带宽.
所以最终我们都会采用 31 G 设置
-Xms 31g -Xmx 31g
假设你有个机器有 128 GB 的内存,你可以创建两个节点,每个节点内存分配不超过 32 GB。 也就是说不超过 64 GB 内存给 ES 的堆内存,剩下的超过 64 GB 的内存给 Lucene
参考
题外话
我在51CTO博客开了一个专栏——《带你玩转高可用》希望可以帮助有一定分布式系统架构知识,在架构方面力求进阶的分布式系统架构从业人员,提高架构可用性,实现高可用目标。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
蚂蚁搬家式迁移mysql数据库
乘机房搬迁的机会,打算做一次业务整合。现有的架构是在2010年规划并运营起来的,随着时间的推移,项目也越来越多。打开nginx配置文件,有四十多行include包含存在,每一个包含就是一个项目(有些是web,有些是app)。一整个机柜,老旧的设备,负载均衡高可用架构。为保证业务一致性和降低成本,业务数据(开发的应用程序及用户上传数据)共享一套NFS;各业务共享同一套物理数据库(一台物理服务器mysql创建多个库)。随着业务和访问量的增长,这种隐患越来越令人担忧,主要表现在以下几个方面: ◆安全问题 数十个站点共享目录,以nfs方式共享给各物理服务器,这几十个项目,只要任何一个有安全漏洞存在,有心人都能进来为所欲为,让站点全部沦陷。时不时的,被人注入恶意代码,针对性的进行清除,但没多久又被注入篡改。大家心里都有数,存在漏洞的地方,不一定是被篡改的那个。但站点太多,又没有隔离,根本无法用安全工具扫描(一个站点进行扫描,平均花费一天)。 [root@web57 ~]# more /usr/local/nginx/conf/nginx.confuser www www;worker_pro...
- 下一篇
记一次负载均衡+NFS博客站点搭建的总结
起因 原本是打算搭建个小博客站点做实验,突然想起之前遇到的一次负载均衡失效的经历,便打算做一次实验重现当初的情况并记录下来,防止日后再遇到类似的情况懵逼。 复现流程 架构体系 原环境:前端依赖nginx做负载均衡的调度器,web端是httpd+php-fpm分离,分别处理动态和静态页面,后端mariadb数据库做数据存储,NFS服务器提供站点文件作出共享,防止,web端出现站点文件不一致的情况。 模拟环境:nginx做负载均衡器,httpd和php-fpm共存在同一主机,NFS和mariadb分处2台主机,整个模拟一共使用5台主机。 软件环境与架构图 前提:所有节点主机全部关闭selinux,清空防火墙规则。 系统 httpd php nginx maiadb CentOS 7 httpd2.4 5.4.14 1.10.2 10.2.15 架构图 配置各个节点 配置nginx节点 1.安装nginx yum install nginx -y 2.编辑nginx配置文件 vim /etc/nginx/conf.d/upstream.co...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- CentOS8安装Docker,最新的服务器搭配容器使用
- CentOS7安装Docker,走上虚拟化容器引擎之路
- Linux系统CentOS6、CentOS7手动修改IP地址
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- Docker安装Oracle12C,快速搭建Oracle学习环境
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS7,CentOS8安装Elasticsearch6.8.6