Elasticsearch开发进阶指南——如何选择合适的ES版本

2021年12月15日 249点热度 0条评论

Elasticsearch开发进阶指南——如何选择合适的ES版本

Elasticsearch不只是全文检索引擎的领头羊,现在也是各个大厂标配的大数据平台之一,被广泛用于搜索加速,用户标签、画像系统、向量搜索等领域,它不是传统的关系型数据库,但这个信息爆炸,数据堆积的时代,我们获取知识的方式已经极大的改变,搜索、提问成了获取知识的第一手段。对Elasticsearch工程师的要求已经不亚于甚至超过了对DBA的要求。那么,要如何才能成为一个被认可的Elasticsearch工程师?希望这个系列文章能够从一个开发工程师的角度,给你点点帮助

选择最新的版本永远是一个不会错的选择

在使用Elasticsearch之前,我们总是要先选择一个版本,选择最新的版本永远是一个不会错的选择。因为,Elasticsearch作为一个社区活跃的开源软件,有着极快的迭代着开发->反馈->再开发的模式。每个版本都可能有着大量的改进或者新功能,特别是大数据领域本身也在不停的进化着方法论,Elasticsearch从一个开始的只能做全文检索,到增加了列式存储、聚合框架、BKD Tree和优化稀疏数据存储,再到支持向量相似性,可以搜索语音、图片,直到几乎变成软件开发中搜索的代名词
因此,在最新的版本上做开发,基本上你会被Elasticsearch带着前进。
%title插图%num
%title插图%num
我也在不少公司仍然看到不少团队还在使用2.x版本的ES,每天和相对低下的性能和缺失的功能较劲。我这里大概列举一些在旧版本的ES上工作可能带来的烦恼:

  • 开始有大量的聚合需求,需对各种指标进行聚合,但性能受限,索引膨胀率高。聚合框架 + Block-KD tree (> 5.0)
  • 随着索引数据持续增加,分片变大,需要自动新建索引?Roll over API(> 5.0)
  • 随着数据量的增加或者集群横向扩容,需要动态的调整shard的数量? split API (> 6.2)
  • 更多的用户需要使用Elasticsearch,需要支持SQL查询? Elasticsearch SQL (> 6.3)
  • OOM问题?需要更精确计算的基于内存的断路器? real-memory circuit breaker(> 7.0)

或许这样说不是特别的直观,或者你觉得这些功能不是必须的,自己手动处理一下也没问题。那么我们从性能上看看。

从Benchmark上查看ES个版本在各场景上的性能差异

Elastic的运维团队针对各个版本的ES,在统一的硬件环境配置下,针对不同的数据场景和指标有一个每夜测试报告。测试结果在benchmark可以查看。

测试数据类型

我们先看看有哪些测试数据类型的覆盖:
%title插图%num
基本上算很全面了,我们场景的数据类型都有专门的测试。

再看看测试都运行在哪些环境。

不同的软件包配置

  • bare: Elasticsearch 运行在非加密硬盘上
  • ear: Elasticsearch 运行在使用linux dm-crypt磁盘加密的硬盘上
  • docker: Docker运行官方的Elasticsearch镜像
  • oss: Apache 2.0 license的Elasticsearch (不包含X-Pack)
  • basic: 包含 X-Pack 的Elasticsearch(basic licence)
  • trial-security: 包含 X-Pack 的Elasticsearch,安全功能全开并使用TLS链路加密

再看看,都在哪些版本的Elasticsearch上运行

不同的release

  • 1.7.6
  • 2.4.6
  • 5.6.16
  • 6.8.0
  • 7.4.0
  • master

根据不同的release的参数,我们可以很直观的对比不同版本的Elasticsearch在不同场景下不同的指标表现。

Nested 例子

我们以嵌套文档来举例,看看数据

%title插图%num
从上图,我们可以看到,从5.x版本之后开始,文档的索引速度有明显的提升,6.8.0基本上是2.x版本的2倍。
而在索引大小类似的情况下,索引过程多整个磁盘的IO消耗,再持续优化。
这里需要特别强调的是X-pack特别优秀的安全性能,无论是开启磁盘加密或是全链路的TLS/SSL加密,对性能的影响都是微乎其微的,有些数据甚至反常,这里得益于X-pack优秀的性能。这点是Search-Guard完全无法比拟。

%title插图%num
GC的时间优化更为明显,特别是Young GC的时间消耗,2.x是最差的,是6.8.0的7倍。
对于相同nested query的响应时间,6.8.0基本上比2.x版本缩短2倍。
%title插图%num
%title插图%num
在不排序的情况下的term query和match all,7.4的表现极其优秀,因此,Elastic也是注意到,目前Elasticsearch越来越多的用在查询加速的场景,在使用filter比较多时(不用排序),7.4做了特定的优化。

当我们拥有了每个新版本上提供的各种新功能的一个视野,当我们明细了各个版本在不同场景下的性能差异,做出选择哪个版本的ES不是一个难题。但还是有可能,现有的数据不能够完全匹配你的场景,你仍然希望在你自己的场景上去判断是否需要升级到最新的版本。这时,我们需要自己定制化的benchmark

使用Rally自己做性能测试和对比

rally是Elastic开源的专门用于Elasticsearch性能测试的工具,这里就不做过多的介绍,具体可以查看官方文档

这里只是简单介绍一下应该如何做自己的基线:

  • 使用和线上集群相同的硬件配置搭建单节点集群
  • 使用和线上集群相同的mapping,创建0副本,1分片的索引
  • 使用和线上集群相同的数据进行压测
  • 观察写入的性能,并使用和业务类似的查询请求观察搜索和聚合的性能
  • 压测数据持续导入ES集群,作为基线

可以根据以下教程,去自己生成和生产类似的数据用于测试
%title插图%num
当一切数据完备之后,就可以在不同的版本上进行对比测试了:
%title插图%num

总结

当完成以上套路之后,相信关于应该使用哪个版本的ES,你已经心知肚明了。。。是的,用最新的GA版本

文章来源于互联网:Elasticsearch开发进阶指南——如何选择合适的ES版本

harry

这个人很懒,什么都没留下

文章评论