我们现在在使用 2.2.2 很长时间，一直没有升级，官方社区有句话说的好：”版本差的越多，升级越困难“，今天站在 2.2.2 一直看到 7.X 看看官网描述：都做了哪些重大调整，提前了解新功能，更完善的进行迁移，并且做好升级出现问题的心理准备。
回首ES
首先，回过头从ES 2.2 到 7.X 追溯各个版本的变化,重点关心字段、索引、文档 相关的 feature。
2.3
- nested、groovy、API 小调整
Breaking changes in 2.3 | Elasticsearch Reference [2.3] | Elastic
2.4
- 弃用 optimize_bbox 地理位置查询参数
- 索引模板的调整
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 重大调整
- 增加迁移数据到 5.0 的插件，但要求 2.3 以上
搜索：
- fields 参数已取代 stored_fields
- filtered 、and 、 or 使用 bool 子句
- missing → exists limit → terminate_after
- fquery query 过时
query_binary filter_binary 移除
字段映射：(重点看)
string字段替换为text/keyword字段 （但向下兼容string）- text 预先分词，keyword 不分词，默认 256 字符。
- 数字字段、geo_point 地理位置字段，采用新的 BKD 树结构，磁盘空间占用更少，查询更快。
- 所有字段类型：
"index": "not_analyzed"只能写成"index": "false"反之同理true，除非你还是用 string。 - 动态映射包含浮点数的字段时，该字段现在默认为使用
float而不是double，原因是，在大多数情况下，浮子应该绰绰有余，但会大大降低存储需求。 正则表达式过滤器已不再受支持，在升级时将被删除。- 为了防止映射爆炸，5.x 最多 1000 字段 ，最大深度 20，nested 最多 50 字段。
- 不能再使用
_ttl或_timestamp启用创建索引, 但是从 2.3 以上迁移的还是可以继续工作的。 - 5.x 不允许空白字段
创建索引：
- 不再支持
-或+开头的索引，（当然我估计还是不支持大写）
文档：
- refresh 查等待有调整：www.elastic.co/guide/en/el…
API：
- 终于可以用 Delete-By-Query 了：www.elastic.co/guide/en/el…
- java api 调整不少：www.elastic.co/guide/en/el…
插件：
- 禁止网站插件，Kibana 代替，或者 chrome 拓展插件（导致我们自研的插件失效，不过问题不大）
Breaking changes in 5.0 | Elasticsearch Reference [5.0] | Elastic
5.1 5.2
- 调整不大,研发无感
Breaking changes in 5.1 | Elasticsearch Reference [5.1] | Elastic
Breaking changes in 5.2 | Elasticsearch Reference [5.2] | Elastic
5.3
- 新增 es.log （运维相关）
- bool 的 value 更严谨了，除了 false，“false”，true 和 " true" 其他的都不可以，字段映射和搜索都是按此要求。
Breaking changes in 5.3 | Elasticsearch Reference [5.3] | Elastic
5.4 5.5
- Delete By Query 的小调整
- 调整不大
Breaking changes in 5.4 | Elasticsearch Reference [5.6] | Elastic
Breaking changes in 5.5 | Elasticsearch Reference [5.6] | Elastic
5.6
- 发布新的 JAVA 客户端，可以使用与使用相同的Core Java类来执行搜索，索引，删除，更新和批量操作
TransportClient
Breaking changes in 5.6 | Elasticsearch Reference [5.6] | Elastic
6.0 重大调整
- 新的大版本，老规矩会提供连续版本 5.x 到 6.x 的升级方案，一次升级一个节点，之前和之后的版本都这样，一般都不支持跨版本。
- Index 中不再支持多个 type（后面完全移除了，官方说index下不同实体太多，切分布稀疏不均匀，严重干扰 Lucene 压缩文档的能力）
- 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.
官方的替代办法：
1、为每个文档创建一个索引，这样的好处好处，分布密集，更适合压缩，更符合 Lucene 规范坏处就是，ES 索引和分片是一对多的关系，可能因为几个小小的配置表，三五条数据，就浪费了几个分片。。
2、自定义类型字段，维护一个原来所有 type 字段总和数量的超大 Index ，然后加个 Type 字段，坏处很多：type 是个常用字，很可能与之前业务冲突，调整麻烦，而且文档压缩问题依旧跟 2.x 一样，得不偿失，好处就是不用浪费分片。
文档：
- 之前 bool 可以是：true、false、on、off、yes、no、0、1 都可以现在，只能用 true、false 字符串或者 bool
查询：
关于 query 的诸多调整：www.elastic.co/guide/en/el…
6.2
- 增加了开箱即用的 GC 日志记录，默认 2G 日志，64M 轮一次，方便排查 ES 问题。
Breaking changes in 6.2 | Elasticsearch Reference [6.8] | Elastic
6.3
- 从6.3版开始，所有X-Pack功能均随附Elasticsearch的默认发行版。（安全认证）
Breaking changes in 6.3 | Elasticsearch Reference [6.8] | Elastic
7.0 重大变化
- 集群设置：search.max_buckets 最大 10000 分片。
- _all 被移除
Breaking changes in 7.1 | Elasticsearch Reference [7.1] | Elastic
7.0 直到 7.8 粗略预览一遍，已经没有什么结构上的大变动了。
大版本预览
V5.x
- Lucene 6.x,
- 性能提升，默认打分机制从 TF-IDF 改为 BM 25
- 支持 Ingest 节点、 Completion suggested 、Java REST 客户端
- Type 标记成 deprecated,支持了 Keyword 的类型
- 性能优化
- 减少了内部争竞争，防止对同一文档进行并发更新的竞争以及在同步事务日志时减少了锁定要求，索引吞吐量已得到了极大的提高
- Instant Aggregations，在 Shard 层面提供了 Aggregation 缓存
- 新增了 Profile API
V6.x
- Lucene 7.x
- Removal of types，在 6.0 里面，开始不支持一个 index 里面存在多个 type
- 跨多个Elasticsearch集群搜索，保留原来的索引在 5.x 群集，跨群集搜索来同时搜索 6.x 和 5.x 群集
- 跨群集复制（CCR）
- 更友好的的升级及数据迁移，在主要版本之间的迁移更为简化，体验升级
- 性能优化
- 稀疏区域改进，降低了存储成本
- 通过索引排序，可加快排序的查询性能
V7.x
- Lucene 8.0
- 重大改进-正式废除单个索引下多 Type 的支持（只有_doc这一个默认type）
- 7.1开始，Security 功能免费使用
- ECK，允许用户在 Kubernetes 上配置，管理和操作 Elasticsearch 集群
- TransportClient 被废弃以至于，ES7 的 Java 代码，只能使用 restclient
- 新功能
- 新的集群协调
- 功能更完善的 REST Client
- Script Score Query，下一代的评分方式
- 性能优化
- 默认的 Primary Shard 数从 5 改为 1，避免 Over Sharding
- 性能优化，更快的 Top K 检索
