前言 #

ES 7.10 可能是现在比较常见的 ES 版本。但是对于一些相迭代比较慢的早期业务系统来说，ES 6.8 是一个名副其实的“钉子户”。 借着工作内升级调研的任务东风，我整理从 ES 6.8 到 ES 7.10 ELastic 重点列出的新增功能和优化内容。将分为 6 个篇幅给大家详细阐述。 本系列文章主要针对 Elasticsearch 传统的使用功能和基础的模块，像是集群任务的管理、搜索、聚合还有字段类型这样的功能。对于付费功能或者全新的模块，比如：CCR、机器学习和数据流，这里不去深入探讨。 内容的主要来源于 Elastic 各个版本的发布信息，这里主要比对 ES 6.8 版本到 7.10 版本的差异，并不一一枚举各个新的功能点出现的时间版本。 下面是第一篇：关于 ES 性能的优化

ES 7.10 的性能优化 #

集群协调算法升级 #

基于 Elastic 博客提供的资料，Elasticsearch 7.0 的核心改进在于集群协调层的彻底重构，取代了旧版 Zen Discovery 的局限性，引入更健壮、自动化的分布式共识机制。从理论上来说这次优化有着不少的进步，可以显著提升了高可用性与运维效率

主要的优化点有下面三点：

1. 消除分裂脑（Split Brain）风险：通过自动化计算，确保集群状态更新的安全性。旧版 minimum_master_nodes 的手动配置被移除，避免人为误操作。

2. 提升集群稳定性与恢复速度：节点故障时，集群更快达成一致，减少服务中断窗口。

3. 简化运维复杂度：可以动态扩缩容无需手动调整配置，系统自动管理选举配置。同时提供更清晰的日志和错误提示，加速故障诊断。

而在优化的原则里，Elastic 更强调安全第一。比如，在半数以上主节点永久丢失的风险场景下，ES 7.0 之前的集群会静默等待恢复，允许通过启动新空节点强制恢复，这样可能会导致数据不一致或丢失。在 Elasticsearch 7.0 以及更高版本中，这种不安全活动受到了更多限制。集群宁愿保持不可用状态，也不会冒这种风险（除非使用 elasticsearch-node 恢复工具）。

这次优化显著降低了人为错误的风险：移除脆弱的手动配置，减少运维使用的理解成本。同时提升关键业务连续性：快速故障恢复与明确的容错机制，能适合更多场景需求。

当然也并不是尽善尽美的，也会存在大集群下投票节点过多导致竞争激烈而 无法选主的问题,这种情况下，建议部署独立的主节点，并且可以考虑适当增大 cluster.election.duration 的配置。

Top K 对检索的加速 #

这里的 Top K 主要是指在普通检索时展示前列的数据 Top K。也就是说 Elasticsearch 7.0 对检索数据的查询性能做了明显的改善。那是做了所有查询场景的提升么？

ELastic 做了这么一个场景假设：如果用户通常只关注搜索结果的第一页，且并不关心具体匹配的文档总数，对于超出一定数量的数据搜索引擎可以展示“超过 10,000 条结果”并提供分页浏览来优化搜索效率。但是在实际过程中用户常在查询中使用高频词（如“the”或“a”），这迫使 Elasticsearch 为大量文档计算评分，明显占用了查询资源的使用，即使这些常见词对相关性排序贡献甚微。

而现在，Elasticsearch 现在可以跳过那些在早期阶段就被判定为不会进入结果集顶部的低排名记录的评分计算，从而显著提升查询速度。这里主要涉及了 block-max WAND 算法的实现。这是一个复杂且漫长的优化过程，有兴趣的同学可以阅读一下这段 Magic WAND: Faster Retrieval of Top Hits in Elasticsearch。

从 Elastic 的测试结果来看，新算法的优化让 term 查询加速了 3-7 倍。当然从场景背景可以看出，这个优化主要在大数据量下有明显效果（小数据量也不会有太多的日常高频词）。

默认开启 soft-delete 减少 translog #

从 Elasticsearch 7.4 开始,副本的数据恢复，不再完全依赖 translog 了,而是通过索引的 soft-delete 特性（Elasticsearch 7.0 起所有新索引默认启用软删除 soft-deletes）。这样就可以缩小 translog 的使用场景，从而 translog 的保留大小也可以减少了。

那原来使用 translog 是什么样的呢？

translog 是 ES 用于保证数据安全性的重要工具。同时副分片进行恢复时，它也起着重要作用，只要副分片待获取的差异数据是在 translog 所保留的数据范围内，就可以只从 trasnlog 复制差异的部分数据，而不用拖取整个分片。在之前的版本中，Elasticsearch 默认会保留 512M 或 12 小时的 translog 用于副本恢复。

那现在使用的 soft-delete 是什么呢？

soft-deletes 是 Lucene 中实现的特性。这个软删除有时候会和 lucene 本身的标记删除概念发生混淆。为了方便理解，我们在这里归纳一下，lucene 实现删除的方式是一种标记删除的方式，而这种标记删除可以分为硬删除和软删除。软删除和硬删除有一个明显的区分点是：硬删除，被删除的文档对应的文档号用索引文件 .liv 来描述。软删除 soft-delete，被标记为删除的文档不使用索引文件.liv 来描述，而是通过索引文件 .dvd .dvm 来描述。

这里再扩展一下，.liv 文件主要实现 fixedbitset 数据结构。而 .dvd .dvm 则组合实现了 docvalue 这种正排数据结构。

正排索引的数据结构助力了 translog 的‘减负’，副本可以相对简便的通过软删除中的数据标记来实现数据恢复的处理。

相比较简洁高效的位图索引，docvalue 虽然实现了更多的功能，满足更多的场景，也会带来更多的问题。最明显的就是对于 update 操作，会导致 refresh 变得慢，有些压力场景下 refresh 会达到 10s 以上。

数值/日期排序查询加速 #

Elasticsearch 7.6 版本提升了按日期或数值（即任何存储为有符号 64 位整数（long 类型）的字段）进行排序的查询性能。

这背后的优化原理和之前 top K 使用的 Block-Max WAND 算法有点相似，都是利用算法跳过非竞争性文档来实现加速。

实际效果可能因环境而异，受多种参数影响。在 Elastic 进行的测试场景下，可以达到 35 倍的速度优化。

FST 内存使用迁移到堆外 #

Elastic 7.3 版本实现了这个优化，是藏在 release note 里的彩蛋。

Also mmap terms index (.tip) files for hybridfs #43150 (issue: #42838)

看似不经意的一行，但是带来效果却不小。FST 从堆内转移到堆外后，JVM 的空间可以空余出很客观的一部分。

一直以来，ES 堆中常驻内存中占据比重最大是 FST，即 tip(terms index) 文件占据的空间，1TB 索引大约占用 2GB 或者更多的内存，因此为了节点稳定运行，业界通常认为一个节点 open 的索引不超过 5TB。现在，从 ES 7.3 版本开始，将 tip 文件修改为通过 mmap 的方式加载，这使 FST 占据的内存从堆内转移到了堆外由操作系统的 pagecache 管理。

存储字段压缩优化 #

Elasticsearch 7.10 基于 Apache Lucene 8.7 引入了对存储字段（stored fields）的更高压缩率优化。不管是对于基于 DEFLATE 的 index.codec: best_compression 还是基于 LZ4 的index.codec: default都有不错的表现，在 Elastic 的测试场景下，最大可达到 10%的存储空间减少。

对于数据压缩 lucene 这次主要做了两个优化。

1. Elastic 研究发现在存储数据的时候，底层的 block 越大，压缩效果越好，因为中间被压缩的重复数据可能越多。但是大块的 block 也可能因为解码重复数据降低查询速度。

2. block 间通过共享字典来维持检索效率和数据压缩之间的平衡。

   2.1. 首先为压缩算法提供一个数据字典，它也可以用于字符串重复数据删除。如果在要压缩的数据流和字典之间有许多重复的字符串，那么最终可以得到更好的压缩比。在解压缩时也通过字典来快速补足。

2.2. 同时，ES 使用更大的数据块，这些数据块本身被分成一个字典和 10 个子块，这些子块使用这个字典进行压缩。

而对于实际业务场景中，日志和监控数据的重复率往往会很好，因此在这两个场景中的压缩效果也是最明显的。

小结 #

当然，除了这几项外，ES 在各个版本中也做了不少优化，比如：调整 search.max_buckets 增加到 65534；Date histogram 聚合性能优化等等。有兴趣的同学可以参照各个版本的 release highlight

参考资料：

1. Save space and money with improved storage efficiency in Elasticsearch 7.10
2. Elasticsearch 7.3 的 offheap 原理
3. Elasticsearch 7.4 的 soft-deletes 是个什么鬼