共计 3165 个字符，预计需要花费 8 分钟才能阅读完成。
在学习 Elasticsearch 时候，因为各个版本的问题，搞不清，非常的头疼，官方也给出了各个版本更新的情况，不过是英文版本，版本更新信息又特别多，最近学习，看了很多资料，没有一个整理很清楚的，然后自己就统一整理下, 首先声明下面的整理都是各个版本个人认为比较重要点，因为每个大版本更新内容太多，也不能一一举例，详细需要参阅官方文档，文章底部有链接，我也是为了自己方便在整体上，了解 Elasticsearch 各个版本的迭代，可以更好的理解和使用 Elasticsearch 产品，所以有了这篇文章。
初始版本 0.7.0
2010 年 5 月 14 日发布, 第一个可以查询到发版信息的版本，重要特性：
- Zen Discovery 自动发现模块
- Groovy Client 支持
- 简单的插件管理机制
- 更好支持 ICU 分词器
- 更多的管理 API
初始化的版本，暂时不多介绍，先来这么多。
升级 1.0.0 版本
2014 年 2 月 14 日发布，重要特性：
-Snapshot/Restore API 备份恢复 API
- 支持聚合分析 Aggregations
- CAT API 支持
- 支持联盟查询
- 断路器支持
- Doc values 引入
2.0.0 版本
2015 年 10 月 28 日发布，重要特性：
- 增加了 pipleline Aggregations
- query/filter 查询合并，都合并到 query 中，根据不同的上下文执行不同的查询
- 存储压缩可配置
- Rivers 模块被移除
- Multicast 组播发现被移除，成为一个插件，生产环境必须配置单播地址
新特性 5.0.0 版本
2016 年 10 月 26 日发布，重要特性：
- Lucene 6.x 的支持，磁盘空间少一半；索引时间少一半；查询性能提升 25%；支持 IPV6。
- Internal engine 级别移除了用于避免同一文档并发更新的竞争锁，带来 15%-20% 的性能提升
- Shrink API，它可将分片数进行收缩成它的因数，如之前你是 15 个分片，你可以收缩成 5 个或者 3 个又或者 1 个，那么我们就可以想象成这样一种场景，在写入压力非常大的收集阶段，设置足够多的索引，充分利用 shard 的并行写能力，索引写完之后收缩成更少的 shard，提高查询性能
- 提供了第一个 Java 原生的 REST 客户端 SDK
- IngestNode，之前如果需要对数据进行加工，都是在索引之前进行处理，比如 logstash 可以对日志进行结构化和转换，现在直接在 es 就可以处理了
- 提供了 Painless 脚本，代替 Groovy 脚本
- 移除 site plugins，就是说 head、bigdesk 都不能直接装 es 里面了，不过可以部署独立站点（反正都是静态文件）或开发 kibana 插件
- 新增 Sliced Scroll 类型，现在 Scroll 接口可以并发来进行数据遍历了。每个 Scroll 请求，可以分成多个 Slice 请求，可以理解为切片，各 Slice 独立并行，利用 Scroll 重建或者遍历要快很多倍。
- 新增了 Profile API
- 新增了 Rollover API
- 新增 Reindex
- 提供了第一个 Java 原生的 REST 客户端 SDK
基于 HTTP 协议的客户端对 Elasticsearch 的依赖解耦，没有 jar 包冲突，提供了集群节点自动发现、日志处理、节点请求失败自动进行请求轮询，充分发挥 Elasticsearch 的高可用能力
- 引入新的字段类型 Text/Keyword 来替换 String
- 限制索引请求大小，避免大量并发请求压垮 ES
- 限制单个请求的 shards 数量，默认 1000 个
新特性 6.0.0 版本
2017 年 8 月 31 日发布，重要特性：
- 稀疏性 Doc Values 的支持
- Index sorting，即索引阶段的排序。
- 顺序号的支持，每个 es 的操作都有一个顺序编号（类似增量设计）
- 无缝滚动升级
- Removal of types，在 6.0 里面，开始不支持一个 index 里面存在多个 type
- Index-template inheritance，索引版本的继承，目前索引模板是所有匹配的都会合并，这样会造成索引模板有一些冲突问题，6.0 将会只匹配一个，索引创建时也会进行验证
- Load aware shard routing，基于负载的请求路由，目前的搜索请求是全节点轮询，那么性能最慢的节点往往会造成整体的延迟增加，新的实现方式将基于队列的耗费时间自动调节队列长度，负载高的节点的队列长度将减少，让其他节点分摊更多的压力，搜索和索引都将基于这种机制。
- 已经关闭的索引将也支持 replica 的自动处理，确保数据可靠。
新特性 7.0.0 版本
2019 年 4 月 10 日发布，重要特性：
- 集群连接变化：TransportClient 被废弃
以至于，es7 的 java 代码，只能使用 restclient。然后，个人综合了一下，对于 java 编程，建议采用 High-level-rest-client 的方式操作 ES 集群
- ES 程序包默认打包 jdk：
以至于 7.x 版本的程序包大小突然边 300MB+
对比 6.x 发现，包大了 200MB+，正是 JDK 的大小
- Lucene9.0
- 重大改进 - 正式废除单个索引下多 Type 的支持
es6 时，官方就提到了 es7 会删除 type，并且 es6 时已经规定每一个 index 只能有一个 type。在 es7 中使用默认的_doc 作为 type，官方说在 8.x 版本会彻底移除 type。
api 请求方式也发送变化，如获得某索引的某 ID 的文档：GET
index/_doc/id 其中 index 和 id 为具体的值
- 7.1 开始，Security 功能免费使用
- ECK-ElasticSearch Operator on Kubernetes
- 引入了真正的内存断路器，它可以更精准地检测出无法处理的请求，并防止它们使单个节点不稳定
- Zen2 是 Elasticsearch 的全新集群协调层，提高了可靠性、性能和用户体验，变得更快、更安全，并更易于使用
新功能
- New Cluster coordination
- Feature – Complete High Level REST Client
- Script Score Query
性能优化
- Weak-AND 算法提高查询性能
- 默认的 Primary Shared 数从 5 改为 1，避免 Over Sharding
- 更快的前 k 个查询
- 间隔查询 (Intervals queries)
某些搜索用例（例如，法律和专利搜索）引入了查找单词或短语彼此相距一定距离的记录的需要。
Elasticsearch 7.0 中的间隔查询引入了一种构建此类查询的全新方式，与之前的方法（跨度查询 span queries）相比，使用和定义更加简单。
与跨度查询相比，间隔查询对边缘情况的适应性更强。
总结
通过各个版本的迭代升级会发现，Elasticsearch 的产品的重大改善体验，了解了版本间的不同，会让你认知提高一个档次，网上文章一大片，有的时候你发现，文章作者操作的时候成功的，到了你这里就失败了，百思不得其中的奥秘，或者我的一个方法或者对象怎么就没了，谁对谁错，没有定论，懂得事情的本质才是重点，回到问题的根源，才是解决问题的根本。
希望本篇的介绍可以让你在学习 Elasticsearch 的路上更顺畅，等你学完了 Elasticsearch 最新版本后，回过头来再看这篇文章的时候，感觉是不是一样的，我觉得学习一门技术的时候，心里要对全部轮廓有个认知，不至于钻进一个空间，看不到整个森林的尴尬无效的境地。
就像本文标题所说，先看整个森林，再去钻研一课树木，才会更懂。
本文思维导图整理：
END
如有收获，请帮忙转发，后续会有更好文章贡献，您的鼓励是作者最大的动力！
欢迎关注我的公众号：架构师的修炼，获得独家整理的学习资源和日常干货推送。
参考文章：
- 官方文档 Elasticsearch7.0.0 版本更新 notes
- Elasticsearch Reference 官方文档，英文好的可以进入
- 01ElasticSearch 简介及其发展历史
- Lucene 的版本迭代
