We have been using 2.2.2 for a long time now, and have not upgraded. There is a saying in the official community: “The more bad the version, the more difficult it is to upgrade.” What major changes have been made, learn about new features in advance, make the migration better, and be prepared for problems with the upgrade.

Looking back on ES

First, go back to ES 2.2 to 7.x to trace the changes of each version, focusing on fields, indexes and document-related features.

2.3

  • Nested, Groovy, API minor tweaks

Breaking changes in 2.3 | Elasticsearch Reference [2.3] | Elastic

2.4

  • Deprecate the Optimize_bbox geolocation query parameter
  • Index template adjustment

Each index template must now be independently valid prior to merging. This means, for example, that you can no longer reference analyzers, filters, or tokenizers from a shared template.

Breaking changes in 2.4 | Elasticsearch Reference [2.4] | Elastic

5.0 Major Adjustments

  • Added a plug-in to migrate data to 5.0, but required above 2.3

Search:

  • The fields parameter has replaced stored_fields
  • Filtered, and, or use the bool clause
  • Missing → exists limit → terminate_after
  • Fquery query outdated
  • Query_binary filter_binary removed

Field mapping :(focus)

  • stringFields are replaced bytext/ keywordField (but backward compatiblestring)
  • Text indicates the pre-word segmentation. Keyword indicates the non-word segmentation. The default value is 256 characters.
  • Digital field, geo_point geographical location field, using the new BKD tree structure, less disk space, faster query.
  • All field types:"index": "not_analyzed"Can only be written as"index": "false"Vice versatrueUnless you still use string.
  • When dynamically mapping a field containing a floating point number, the field is now used by defaultfloatRather thandoubleThe reason is that, in most cases, the float should be more than adequate, but will greatly reduce storage requirements.
  • Regular expression filterIs no longer supported and will be removed when upgrading.
  • To prevent mapping explosions, 5.x has a maximum of 1000 fields, a maximum depth of 20, and a maximum of 50 fields.
  • No longer usable_ttl 或 _timestampIndex creation is enabled, but those migrated from above 2.3 will continue to work.
  • 5. X does not allow blank fields

Create index:

  • No longer supported- 或 +Index at the beginning, (of course I guess I still don’t support capitalization)

Documents:

  • Refresh check waiting for adjustment: www.elastic.co/guide/en/el…

API:

  • Finally can use the Delete – By – the Query: www.elastic.co/guide/en/el…
  • Java API adjustment: www.elastic.co/guide/en/el…

Plug-in:

  • Ban web plugins, Kibana substitutes, or Chrome extensions (cause our own plugins to fail, but not a problem)

Breaking changes in 5.0 | Elasticsearch Reference [5.0] | Elastic

5.1 5.2

  • Adjustment is not big, no sense of research and development

Breaking changes in 5.1 | Elasticsearch Reference [5.1] | Elastic

Breaking changes in 5.2 | Elasticsearch Reference [5.2] | Elastic

5.3

  • Added es. Log (O&M related)
  • Bool value is more rigorous, except for false, “false”, true, and “true”, and field mapping and search are required to do so.

Breaking changes in 5.3 | Elasticsearch Reference [5.3] | Elastic

5.4 5.5

  • Minor adjustments to Delete By Query
  • Adjust the little

Breaking changes in 5.4 | Elasticsearch Reference [5.6] | Elastic

Breaking changes in 5.5 | Elasticsearch Reference [5.6] | Elastic

5.6

  • Release a new JAVA client that uses the same Core JAVA classes to perform search, index, delete, update, and batch operationsTransportClient

Breaking changes in 5.6 | Elasticsearch Reference [5.6] | Elastic

6.0 Major Adjustment

  • New major releases, the old rule will provide a continuous version 5.x to 6.x upgrade scheme, one node at a time, before and after the same, generally do not support cross-version.
  • Multiple types are no longer supported in Index. There are too many different entities under Index, which severely interferes with Lucene’s ability to compress documents.
  • The first alternative is to have an index per document type. Instead of storing tweets and users in a single twitter index, you could store tweets in the tweets index and users in the user index. Indices are completely independent of each other and so there will be no conflict of field types between indices.

The official alternative:

1, for each document to create an index, the benefits of such benefits, dense distribution, more suitable for compression, more in line with Lucene specification disadvantages is, ES index and sharding is one-to-many relationship, may be because of a few small configuration tables, three or five data, a few fragments wasted.

Select * from ‘Index’ where ‘type’ = ‘Index’; select * from ‘Index’ where ‘type’ = ‘Index’; Type is a common word, and it is likely to conflict with the previous business, which is difficult to adjust, and the document compression problem is still the same as 2.x, the benefit is not wasted sharding.

Documents:

  • Before, a bool could be true, false, ON, off, yes, no, 0, 1. Now, you can only use true, false strings or bool

Query:

Adjustment of the query: www.elastic.co/guide/en/el…

6.2

  • Added out-of-the-box GC log recording, default 2G log, 64 MB round, easy to troubleshoot ES problems.

Breaking changes in 6.2 | Elasticsearch Reference [6.8] | Elastic

6.3

  • Starting with version 6.3, all X-Pack features ship with the default distribution of Elasticsearch. (Safety Certification)

Breaking changes in 6.3 | Elasticsearch Reference [6.8] | Elastic

7.0 Major Changes

  • Cluster Settings: Search. Max_buckets A maximum of 10000 fragments.
  • _all removed

Breaking changes in 7.1 | Elasticsearch Reference [7.1] | Elastic

After a rough preview of 7.0 through 7.8, there are no major structural changes.

Large version preview

V5.x

  • Lucene 6.x,
  • Performance improved, default scoring mechanism changed from TF-IDF to BM 25
  • Support for Ingest nodes, Completion Suggested, and Java REST clients
  • Type is marked deprecated, supporting the Keyword Type
  • Performance optimization
    • Index throughput has been greatly improved by reducing internal contention, preventing concurrent updates to the same document from competing, and reducing locking requirements when synchronizing transaction logs
    • Instant Aggregations, which provides Aggregation caching at the Shard level
    • New Profile API

V6.x

  • Lucene 7.x
  • Removal of Types, in 6.0, multiple types in an index were initially dissupported
  • Search across multiple Elasticsearch clusters, keeping the original index in the 5.x cluster, and search across clusters to search both 6.x and 5.x clusters
  • Cross-cluster Replication (CCR)
  • Friendlier upgrades and data migration, easier migration between major releases, experience upgrades
  • Performance optimization
    • Sparse area is improved to reduce storage cost
    • You can use index sort to speed up query performance

V7.x

  • Lucene 8.0
  • Major improvements – officially abolishing support for multiple types within a single index (only _doc is the default Type)
  • 7.1 From now on, the Security function is free of charge
  • ECK allows users to configure, manage, and operate Elasticsearch clusters on Kubernetes
  • TransportClient is obsolete so that ES7 Java code can only use RestClient
  • New features
    • New cluster coordination
    • More fully functional REST Client
    • Script Score Query, the next generation of scoring methods
  • Performance optimization
    • The default Primary Shard number was changed from 5 to 1 to avoid Over Sharding
    • Performance optimization for faster Top K retrieval