简体   繁体   English

将Elastic Search 1.7升级到新版本

[英]Upgrade Elastic Search 1.7 to a newer version

We are preparing to upgrade Elastic Search 1.7 to a newer version. 我们正准备将Elastic Search 1.7升级到新版本。

What we should be caring of before starting the upgrade, also is there any suggestions about the version that we should upgrade to it? 在开始升级之前,我们应该注意的是什么,还有关于我们应该升级到该版本的建议吗?

Is it technically possible to upgrade from 1.7 to 5.x or we should upgrade to 2.x first? 从1.7升级到5.x在技术上是否可行,还是我们应该先升级到2.x?

Having been through this recently, there are two approaches to Elasticsearch upgrades when you're far behind: 最近经历了此过程,您有两种落后的Elasticsearch升级方法:

Take a leap and do it all at once, or take it one major version at a time. 跨越式发展,一次完成所有工作,或者一次完成一个主要版本。

The latter is probably safer, but slower. 后者可能更安全,但速度较慢。 It's possible due to Elasticsearch's very nice compatibility policy: any breaking changes in major version X will throw a deprecation warning in version X-1, but will continue to work. 可能是由于Elasticsearch的兼容性政策非常好:主要版本X中的任何重大更改都会在版本X-1中引发弃用警告,但仍会继续起作用。

Personally I'd recommend taking it one version at a time, and since that approach is more complicated, I'll describe it in a bit more detail. 我个人建议一次使用一个版本,并且由于该方法较为复杂,因此我将对其进行详细描述。

This allows for a pattern like the following: 这允许如下所示的模式:

  1. Fix all deprecation warnings on version 1 修复版本1上的所有弃用警告
  2. Test on version 2, and when satisfied roll out to production. 在版本2上进行测试,并在满意时将其投入生产。 If there are issues you can always roll back to version 2 (however you will have to create a new index from scratch) 如果有问题,您可以随时回滚到版本2(但是您必须从头开始创建新索引)
  3. Fix all deprecation warnings on version 2 修复版本2上的所有弃用警告
  4. Test and upgrade to version 5 (there was no 3 or 4) 测试并升级到版本5(没有3或4)
  5. etc... on through all the versions if you'd like 等等...如果您愿意,可以浏览所有版本

Here's some general principles that are worth considering 这是一些值得考虑的一般原则

Rebuild indicies from scratch for new versions 从头开始为新版本重建索引

Yes, the docs say that, for example, you can load an index created in ES 1.7 into ES2 , but I would recommend against it. 是的,文档说,例如,您可以将ES 1.7中创建的索引加载到ES2中 ,但是我建议您反对它。 In my experience, some queries will actually be slower when you do this, even though newer versions of Elasticsearch usually at least maintain if not improve performance. 以我的经验,这样做时,某些查询实际上实际上会变慢 ,即使较新版本的Elasticsearch通常至少可以保持改善的性能。

There are query changes, and schema changes. 有查询更改和架构更改。 Treat them accordingly 相应地对待他们

In general, each update will require some level of change to your Elasticsearch schema mapping, and some changes to your query structure. 通常,每次更新都需要对Elasticsearch模式映射进行一定程度的更改,并对查询结构进行某些更改。 The query structure is usually much easier to iterate on, since it's in your application code and can be improved or rolled back at any time. 由于查询结构位于应用程序代码中,并且可以随时进行改进或回滚,因此通常容易进行迭代。 Schema changes are harder, since they generally require you to create a new index from scratch and migrate over somehow. 模式更改比较困难,因为它们通常要求您从头开始创建新索引并以某种方式迁移。

However, just keep in mind that both types of changes exist. 但是,请记住,两种类型的更改都存在。 Simply adjusting your Elasticsearch schema until it works on the new version, and failing to update your queries can lead to surprises! 只需调整您的Elasticsearch模式直到它在新版本上可用,否则无法更新查询会导致意外!

Now finally, here's a rough list of the major pain points that I recall from each upgrade 现在,最后,这是我从每次升级中回顾的主要痛点的粗略清单

ES 1 -> ES 2 ES 1-> ES 2

ES 2 -> ES5 ES 2-> ES5

  • String datatype has split into text and keyword datatypes 字符串数据类型已分为文本和关键字数据类型
  • TF/IDF scoring replaced with BM25 . TF / IDF得分被BM25取代。 This one won't require any work on your part but may change the result of some of your queries. 这不需要您做任何工作,但可能会更改某些查询的结果。 In ES5, and especially ES6, BM25 scoring is more configurable, but you may simply not be able to get exactly the same results in ES5 and ES2 在ES5(尤其是ES6)中,BM25评分更具可配置性,但是您可能根本无法在ES5和ES2中获得完全相同的结果

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM