4、ES新版本特性

Elasticsearch 6.0.0 部分特性

无宕机升级：

使之能够从 5 的最后一个版本滚动升级到 6 的最后一个版本，不需要集群的完整重启。无宕机在线升级，无缝滚动升级。

跨多个 Elasticsearch 群集搜索

和以前一样，Elasticsearch 6.0 能够读取在 5.x 中创建的 Indices ，但不能读取在 2.x 中创建的 Indices 。不同的是，现在不必重新索引所有的旧 Indices ，你可以选择将其保留在 5.x 群集中，并使用跨群集搜索同时在 6.x 和 5.x 群集上进行搜索。

迁移助手

Kibana X-Pack 插件提供了一个简单的用户界面，可帮助重新索引旧 Indices ，以及将 Kibana、Security 和 Watcher 索引升级到 6.0 。 群集检查助手在现有群集上运行一系列检查，以帮助在升级之前更正任何问题。 你还应该查阅弃用日志，以确保您没有使用 6.0 版中已删除的功能。

使用序列号更快地重启和还原

6.0 版本中最大的一个新特性就是序列 ID，它允许基于操作的分片恢复。 以前，如果由于网络问题或节点重启而从集群断开连接的节点，则节点上的每个分区都必须通过将分段文件与主分片进行比较并复制任何不同的分段来重新同步。 这可能是一个漫长而昂贵的过程，甚至使节点的滚动重新启动非常缓慢。 使用序列 ID，每个分片将只能重放该分片中缺少的操作，使恢复过程更加高效。

使用排序索引更快查询

通过索引排序，只要收集到足够的命中，搜索就可以终止。它对通常用作过滤器的低基数字段（例如 age, gender, is_published）进行排序时可以更高效的搜索，因为所有潜在的匹配文档都被分组在一起。

稀疏区域改进

以前，每个列中的每个字段都预留了一个存储空间。如果只有少数文档出现很多字段，则可能会导致磁盘空间的巨大浪费。现在，你付出你使用的东西。密集字段将使用与以前相同的空间量，但稀疏字段将显着减小。这不仅可以减少磁盘空间使用量，还可以减少合并时间并提高查询吞吐量，因为可以更好地利用文件系统缓存。

官方文档：https://www.elastic.co/blog/elasticsearch-6-0-0-released

Elasticsearch 7.0.0 部分特性

Elasticsearch 集群协调迎来新时代

从一开始，我们便专注于让 Elasticsearch 可轻松进行扩展，并且拥有弹性以应对灾难性故障。为了满足这些要求，我们采取了多种方法，从提高单个节点的可扩展性和可靠性，到持续改善我们的集群协调层 Zen Discovery。在 7.0 中，我们再一次在这两方面实现了重大改进。

Elasticsearch 包含一个全新的集群协调层，更快捷，更安全，也更易于使用。为了实现这一目的，我们在开始时专注于使用 Formal 模型来对设计进行验证，以确认我们全新分布式一致性算法的理论正确性。尽管已经有很多广为人知的一致性算法，例如 Paxos、Raft、Zab 和 Viewstamped Replication (VR)，但由于 Elasticsearch 集群要求实现更高的集群变更吞吐量，支持轻松扩大或压缩集群，且能够提供无缝的滚动升级策略以允许 6.7 集群滚动升级至 7.0，所以前边提到的算法均无法达到这些要求。新的集群协调层同时还包括很多能够降低人为错误几率的变更，并且从灾难性故障中恢复时可以提供更加明确的选项。要想一下子同时提高可靠性、性能和用户体验，这可不是一件简单的事，在这样一个集中式的组件中尤为如此。我们对新的集群协调层以及自己取得这一成果的过程充满自豪。如需了解详情，请阅读博文。

我们在 Elasticsearch 中构建单独节点时已将弹性考虑在内。如果您向某个节点发送过多请求，或者如果您的请求过大，节点可能会将您的请求推回。我们在 Elasticsearch 中通过采用断路器来实现这一过程，如果断路器确定节点无法处理特定请求，会立即发送响应并要求客户端重试（可能需要换一个节点）。对于 JVM 堆规模较小的节点（随着用户开始改用单租户集群模型，而不再使用大型的多租户集群，此情况越来越普遍），这一点尤其重要。在 7.0 中，我们推出了真正的内存断路器，此工具能够在极大程度上提高针对无法处理请求情况的检测准确性，并防止这些请求导致单个节点不稳定。如果希望深入了解这一变更如何改善整体节点和集群的可靠性，请阅读博文。

提高各种用例的相关度和速度

相关度和速度是良好搜索体验的基石。Elasticsearch 7.0 推出了多项基础功能来对这两方面加以改善。

• Top K 查询的速度更快：在很多用例中，用户在查询时，快速看到排名前 K（Top K，例如排名前 20）的结果比看到准确的匹配条数（亦即符合查询条件的结果总数）要重要得多。举例说明，如果某人正在电商网站上搜索一件商品，他/她可能更关心相关性最高的前 10 条结果，而对符合查询条件的另外 120,897 条结果则可能根本不在乎。Elasticsearch 7.0（以及 Lucene 8.0）采用了新算法 (Block-Max WAND)，该算法在检索前 K 个结果时能够巨幅提高查询速度。

• 间隔查询：某些搜索用例（例如法律和专利搜索）需要查找单词或短语间距离在特定范围内的记录。Elasticsearch 7.0 中的间隔查询针对此类查询引入了一种全新的构建方式，与之前的方法（span 查询）相比，可极大简化使用和定义过程。与 span 查询相比，间隔查询针对边缘用例的弹性也要出色得多。

• 函数分数 2.0：自定义评分是高级搜索用例中最基础的内容，因为用户在高级搜索用例中希望更精细地控制相关度和结果排名。Elasticsearch 从早期就实现了这样的功能。7.0 推出了新一代函数分数功能，此功能可以通过更简单、更灵活的模块化方式针对每条记录生成一个排名分数。通过新的模块化结构，用户能够混合和匹配一组算术和距离函数，从而构建任意的函数分数计算方式，进而在更大程度上控制结果的评分和排名方式。

使用 geotile 网格在 Elastic Maps 中更平滑地缩放地图

多年以来，我们针对地理数据的支持一直在不断提升，从早期向 Elasticsearch 首先添加地理数据支持功能，到向 Lucene 中推出 Bkd 树数据结构并通过此结构将地理形状的查询性能提高超过 25 倍，再到在 Kibana 中为全球基础地图提供支持的 Elastic Maps 服务，都是我们的硕硕成果。

在 7.0 中，我们继续投入精力改善这一领域，在 Elasticsearch 中推出了新的聚合来对地图磁贴进行处理，以便让用户能够在不更改结果数据形状的前提下对地图进行缩放。新的 geotilegrid 聚合会将 geopoints 组合到代表网格中单元格的 bucket（桶）中，其中每个单元格均对应至地图中的磁贴。在此次变更之前，由于矩形磁贴在不同缩放级别下会更改方向，所以，形状边缘会随着缩放级别的变化发生轻微改变。7.0 中的 Elastic Maps 业已采用这种新聚合，确保您的视图在缩放过程中会保持稳定。无论您希望保护自己的网络免受攻击，还是调查为何特定地点的应用程序响应时间长，或者跟踪弟弟在太平洋屋脊步道上徒步，实现这种级别的准确性都至关重要。

支持达到纳秒级精度，强化时序型用例

无论是基础设施指标、系统审计日志、网络流量，还是火星漫步者，时序型数据都是很多用户使用 Elastic Stack 完成的中心工作。用户需要能够精准地跨多个系统和多项服务对事件进行排序和相关性分析，这一点至为关键。

截至今日，Elasticsearch 仅支持以毫秒级精度存储时间戳。7.0 则将小数点又往后推了好几位，可以实现纳秒级精度，这样有高频数据收集需求的用户便能实现所需精度以准确地存储和排序相关数据。之所以能够实现这一改进，是因为我们从传统的 JODA 库迁移到了 JDK 8 中官方的 Java time API。

官方文档：https://www.elastic.co/cn/blog/elastic-stack-7-0-0-released