Elasticsearch 不同版本特性区别（概览）
说明：ES 在 小版本 中会持续加入特性与 breaking changes。本文按 5 / 6 / 7 / 8 大代际 归纳"代际差异 + 面试/架构常考点"。落地升级请以对应版本的 Release notes 与 Breaking changes 为准。
一、总览对照（按代际）
| 维度 | 5.x | 6.x | 7.x | 8.x |
|---|---|---|---|---|
| Mapping / 类型 | 多 _type 常见 |
新索引限制为单 type；与 7 过渡期并存 | Typeless API 成为主流；逐步废弃 URL/Body 中的 type | 接受 type 的 API 移除；统一无类型文档模型 |
| 集群与恢复 | 传统文件级恢复为主 | Sequence IDs，基于操作回放的分片恢复，重启/恢复更高效 | 持续优化（如副本选择、索引空闲优化等） | 安全与系统索引保护增强；运维面继续演进 |
| 跨集群 | --- | Cross Cluster Search（CCS） 等能力强化 | CCS 等持续迭代 | 与 Elastic Stack 8 一体化、安全默认开启等 |
| 时间/日期 | Joda 风格较多 | 过渡期 | Java Time 替代 Joda-Time（7.0 起） | 延续 |
| 安全 | X-Pack 商业特性逐步整合 | 生产模式下节点间 TLS 等要求收紧（X-Pack Security） | 安全能力成熟 | Security by default：TLS、认证、节点间加密等默认更强调开箱安全 |
| 向量 / 语义检索 | 无原生 kNN 体系 | 无 | dense_vector 等逐步演进 |
近似 kNN （HNSW 等）、semantic_text、向量检索与语义搜索方案成熟 |
| REST 兼容 | --- | --- | --- | 8.0 引入 7.x REST 兼容相关能力，便于平滑迁移（过渡期使用，长期应改客户端） |
二、5.x：关键词
- 索引兼容：5.0 可读 2.0+ 索引；更老版本需先迁移/重建（具体以该版本 breaking changes 为准）。
- Breaking 面较宽：脚本、聚合、REST、插件、CAT API 等在 5.0 有集中调整------老集群升级常需改查询与配置。
- 定位：大量历史系统仍可见其影子；新项目不建议再从 5 起步。
官方参考 ：Breaking changes 5.0
三、6.x：关键词
- 单 mapping type 收紧 ：新索引 每个索引只允许一个 type，为多 type 彻底退出铺路；与 Lucene 字段模型、压缩效率问题相关。
- Sequence IDs / 基于操作的恢复 ：分片恢复可重放缺失操作，减少整段文件拷贝，节点重启与故障恢复明显提速。
- 滚动升级：5 → 6 支持滚动升级路径（需满足兼容性条件；X-Pack 安全场景有额外约束）。
- 跨集群搜索（CCS）：可把旧集群留在 5.x，新数据在 6.x，统一查询，降低一次性迁移压力。
- 索引模板 ：模板匹配由
template过渡到index_patterns（6.0 起）。
官方参考 ：Breaking changes 6.0
四、7.x：关键词
4.1 数据模型与 API
- 移除 mapping types 路线 ：对外 API 走向 typeless （例如文档写入多为
PUT index/_doc/id），减少"多 type 同名字段冲突"类问题。 - 7.0 大范围 breaking ：除类型外，还涉及 Java Time、发现机制、REST/Java 客户端、脚本、聚合与 suggester 等多处------升级需按官方迁移清单逐项核对。
4.2 搜索与性能（代际内亮点示例）
- 自适应副本选择（ARS）：默认开启后，结合各副本延迟做路由，有利于降低尾延迟。
- Search idle ：长时间无搜索的 shard 可减少自动 refresh 频率，写多读少场景索引性能更好。
- Top-k 优化：对部分查询可跳过明显不会进入前 K 的文档打分，大结果集场景更有利。
4.3 存储与成本（7.10+ 常见考点）
- Searchable snapshots（可搜索快照）：冷数据放对象存储等，需要时以较低成本"可搜"，适合分层存储与归档检索（具体许可与部署形态依 Elastic 订阅与架构而定）。
官方参考 ：Breaking changes 7.0 · Removal of mapping types
五、8.x：关键词
5.1 安全与运维
- Security by default ：更强调集群与 Kibana 的 TLS、认证、授权 等默认安全基线；节点加入可通过 enrollment token 等简化流程（具体以 8.0 release highlights 为准）。
- 系统索引保护：降低误删/误改系统索引的风险。
5.2 API 与迁移
- REST API 变更 ：8.0 存在若干 breaking；提供 7.x 兼容请求/响应 的过渡手段（HTTP 头），便于分阶段改客户端。
- 彻底移除带 type 的旧 API：客户端与自动化脚本必须完成 typeless 改造。
5.3 向量检索与语义搜索（8.x 代际强项）
- 近似 kNN ：
dense_vector+knn查询/搜索选项；大规模生产多用 近似 （HNSW 等），与 精确 script_score 暴力检索在延迟与规模上取舍不同。 - 语义检索 ：
semantic_text等字段与 推理端点（inference） 结合，减少手工搭 ingest pipeline 的样板配置（能力随 8.x 小版本持续演进）。 - 向量相关优化 ：高维向量索引在较新版本中有 量化（如 BBQ）与 HNSW 等组合优化方向（以当前版本文档为准）。
官方参考 ：What's new in 8.0 · Current release highlights · Breaking changes
六、升级路径（架构/面试常用表述）
- 读官方 Breaking changes：先目标大版本，再逐个小版本看 deprecation。
- 先用 Deprecation API / 日志：在旧版本上消掉弃用用法，再滚动升级。
- 索引兼容 ：无法直接读的索引需 reindex 或中间版本跳板（尤其从很老版本跨越多代时）。
- 客户端 ：REST 路径、Java High Level REST、Transport 等在不同代际变化大，应用侧与集群版本要联动规划。
- 8.x ：预留时间处理 安全默认配置 、证书与账号体系，以及 向量/语义 新业务若用新字段类型需单独压测。
七、与 OpenSearch 的说明（可选）
2021 年起社区有 OpenSearch 分支，版本号与特性与 Elastic 官方 ES 不再一一对应 。若文档用于公司内部，需说明实际部署是 Elastic Elasticsearch 还是 OpenSearch，避免混用两套 release notes。
八、参考链接（Elastic 官方）
文档生成目的：版本选型、升级评审、面试问答速查；细节以部署版本官方文档为准。