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

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

文章目录

选择最新的版本永远是一个不会错的选择
从Benchmark上查看ES个版本在各场景上的性能差异
- 测试数据类型
- 不同的软件包配置
- 不同的release
- Nested 例子
使用Rally自己做性能测试和对比
总结

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

在使用Elasticsearch之前，我们总是要先选择一个版本，选择最新的版本永远是一个不会错的选择。因为，Elasticsearch作为一个社区活跃的开源软件，有着极快的迭代着开发->反馈->再开发的模式。每个版本都可能有着大量的改进或者新功能，特别是大数据领域本身也在不停的进化着方法论，Elasticsearch从一个开始的只能做全文检索，到增加了列式存储、聚合框架、BKD Tree和优化稀疏数据存储，再到支持向量相似性，可以搜索语音、图片，直到几乎变成软件开发中搜索的代名词。
因此，在最新的版本上做开发，基本上你会被Elasticsearch带着前进。

我也在不少公司仍然看到不少团队还在使用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可以查看。

测试数据类型

我们先看看有哪些测试数据类型的覆盖：

基本上算很全面了，我们场景的数据类型都有专门的测试。

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

不同的软件包配置

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 例子

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

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

GC的时间优化更为明显，特别是Young GC的时间消耗，2.x是最差的，是6.8.0的7倍。
对于相同nested query的响应时间，6.8.0基本上比2.x版本缩短2倍。

在不排序的情况下的term query和match all，7.4的表现极其优秀，因此，Elastic也是注意到，目前Elasticsearch越来越多的用在查询加速的场景，在使用filter比较多时（不用排序），7.4做了特定的优化。

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

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

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

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

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

可以根据以下教程，去自己生成和生产类似的数据用于测试

当一切数据完备之后，就可以在不同的版本上进行对比测试了：

总结

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