elasticsearch - 将Elastic Search 1.7升级到新版本

Question

我们正准备将Elastic Search 1.7升级到新版本。

在开始升级之前，我们应该注意的是什么，还有关于我们应该升级到该版本的建议吗？

从1.7升级到5.x在技术上是否可行，还是我们应该先升级到2.x？

Answer 1

最近经历了这一过程，您有两种落后的Elasticsearch升级方法:

大步向前，一次完成所有操作，或者一次完成一个主要版本。

后者可能更安全，但速度较慢。可能是由于Elasticsearch的兼容性政策非常好:主要版本X中的任何重大更改都会在版本X-1中引发弃用警告，但仍会继续起作用。

我个人建议一次使用一个版本，并且由于这种方法更加复杂，因此我将对其进行详细描述。

这允许如下所示的模式:

修复版本1

上的所有弃用警告

在版本2上进行测试，并在满意时将其投入生产。如果有问题，您可以随时回滚到版本2(但是必须从头开始创建新索引)

修复版本2

上的所有弃用警告

测试并升级到版本5(没有3或4)

等...如果需要

，请浏览所有版本

这是一些值得考虑的一般原则

从头开始为新版本重建索引

是的，文档说，例如，您可以 load an index created in ES 1.7 into ES2，但是我建议不要这样做。以我的经验，这样做时，某些查询实际上实际上会变慢，即使较新版本的Elasticsearch通常至少可以保持即使不能提高性能。

有查询更改和架构更改。相应地对待他们

通常，每次更新都需要对Elasticsearch模式映射进行一定程度的更改，并对查询结构进行某些更改。由于查询结构位于您的应用程序代码中，并且可以随时进行改进或回滚，因此通常更容易进行迭代。模式更改比较困难，因为它们通常要求您从头开始创建新索引并以某种方式迁移。

但是，请记住，两种类型的更改都存在。只需调整您的Elasticsearch模式直到它在新版本上可用，否则无法更新查询可能会导致意外!

现在，最后，这是我每次升级都记得的主要痛点的粗略 list

ES 1-> ES 2

Filtered query is deprecated。如果您正在使用它，则必须切换到bool query

ES 2-> ES5

String datatype已拆分为text and keyword datatypes

TF / IDF评分已替换为BM25。这不需要您做任何工作，但是可能会更改某些查询的结果。在ES5中，尤其是在ES6中，BM25评分更具可配置性，但是您可能根本无法在ES5和ES2中获得完全相同的结果