Elastic Stack 7.0.0 版本于 4 月 10 日正式发布，包括 Elasticsearch，Kibana，Logstash，Beats 等应用同时发布 7.0.0 版本。
这一版本囊括来自 861 位提交者的超过 1 万项 pull request。
下载地址：https://www.elastic.co/cn/downloads/
其中，Elasticsearch 7.0.0 的重大更新包括：
- 性能提升 ;
- Top-K 检索更快 ;
- 自适应副本选择 ;
- 默认绑定 JDK;
- 支持 JSON 格式日志记录
Kibana 7.0.0 的重大更新包括：
- 清新，时尚的外观 ;
- 默认开启 Kibana 查询语言 ;
- 黑暗主题 ;
- 响应式仪表板 ;
- 时间戳和过滤器的新外观 ;
- 保存对象的结构改进
Logstash 7.0.0 的重大更新包括：
- 默认的 Java 管道执行 ;
- 自动索引生命周期管理
Elastic Stack 的 7.0 版本当中整体包含大量亮点，话不多说请看下文。
Kibana 7.0：新的设计与导航机制……外加黑暗模式！
在 Kibana 7.0 的设计当中关注重点放在内容身上，因此大家会发现新的 UI 在整个使用过程中将带来更轻便、更小巧的感觉。其中最突出的变化就是设计了新的全局导航机制，引入一个恒定的标题栏以切换 Kibana 空间、显示足迹，同时执行密码变更或者登出这类用户操作。为了实现这一目标并提高一致性水平，我们创建了 Elastic UI 框架。在过去一年中，我们几乎将整个 Kibana 都利用框架中的组件进行了转换。通过这些组件外加我们设计与工程团队的艰苦努力，我们还对样式与样式表的应用方式做出了大幅简化。
一致性的提升与样式表的改进，使我们能够进一步实现 Kibana 发展历史当中最为重大的功能要求之一——为 Kibana 提供整体黑暗模式。作为此次调整的另一大体现，Kibana 仪表板现在采用到响应式设计，这将成为其迈向移动设备可用性的重要第一步。
Elasticsearch 中新的集群协调
从起步阶段，我们就致力于确保 Elasticsearch 拥有更低的扩展门槛，同时高效适应各类灾难性故障。为了支持这些要求，我们采取了一系列方法，旨在使单一节点更具可扩展性与可靠性，进而对我们的集群协调层 Zen Discovery 做出持续改进。在 7.0 版本当中，我们在这一领域进一步引入了新的重大升级。
Zen2 是用于 Elasticsearch 的全新集群协调层， 速度更快、安全性更高且更易于使用。为了实现这一目标，我们首先利用形式模型设计验证了新的分布一致性算法理论的正确性。虽然目前市面上已经存在众多广为人知的共识算法，例如 Paxos、Raft、Zab 以及 Viewstamped Replication（简称 VR）等，但 Elasticsearch 集群明显需要更为可观的集群变更吞吐量，从而能轻松支持集群的规模伸缩，并通过无缝滚动升级策略使得 6.7 版本集群顺利升级至 7.0 版本。很明显，现有算法无法切实提供这些功能。
Zen2 当中还包含一系列能够显著降低人为错误发生机率的设计，同时允许用户在进行灾难恢复时拥有更为清晰的选项。一口气对可靠性、性能以及用户体验进行全面提升绝非易事，特别是在这样的核心组件层面。
Elasticsearch 当中的每一个节点在构建之时都充分考虑到弹性因素。如果向节点发送的请求过多或者过大，则节点会将其推回。我们通过 Elasticsearch 中的断路器程序实现这一效果，它负责确定节点能否处理给定的请求，并以要求客户端（可能位于其它不同节点上）重试的方式立即做出响应。对于 JVM 堆较小的节点而言，目前的普遍使用趋势是每个租户对应一个集群，而非多租户扎堆在一个大集群中。这种变化趋势非常重要。在 7.0 版本中，我们引入了真内存断路器（real memory circuit breaker），其能够更准确地检测到无法使用的请求，并防止其给单一节点造成的不稳定影响。
跨用例实现相关性与速度的提升
毫无疑问，良好的相关性与速度表现是成就强大搜索体验的基石。Elasticsearch 7.0 引入了多项可同时改进这两项指标的基本特性。
• 更快的 Top-K 查询: 在大多数搜索用例当中，快速查看 Top-K（比如前 20 条）查询结果往往足以带来令用户满意的命中率（即匹配查询的结果总数）。举例来说，如果有人在电商网站上搜索产品，他们往往只对清单中列出的前 10 条结果较感兴趣；换言之，没人会真的认真查看与搜索查询相匹配的十多万条额外结果。Elasticsearch 7.0（配合 Lucene 8.0）实现了一种新型算法（Block-Max WAND），能够在检索热门命中结果时带来巨大的速度提升。
• 间隔查询: 在某些搜索用例当中，例如法律与专利搜索，用户所查找的单词或短语之间可能存在着一定的距离。Elasticsearch 7.0 中的间隔查询功能引入了一种前所未有的查询构建方式。与之前的方法（跨度查询）相比，这种新方法的使用与定义更为简单，而且对于极端情况的适应性也更强。
• 函数评分 2.0: 定制化函数评分是高级搜索用例的实现基础，人们希望能够更好地控制相关性与结果排名。Elasticsearch 在早期版本当中就开始提供相关功能。而在 7.0 版本中，我们发布了下一代函数评分机制，这项功能带来了一种更简单、模块化且灵活性更强的方式，用以为每条记录生成排名分数。新的模块化结构允许用户将一组自述与距离函数混合起来并加以匹配，从而建立起任意函数评分计算，最终更好地控制搜索结果的得分与排名。
使用 geotile grid 平滑放大 Elastic Maps
多年以来，我们对于地理数据的支持能力一直在不断改进。在 7.0 版本中，我们继续进行这方面努力，包括在 Elasticsearch 当中引入一个新的聚类以处理（地理）图块，允许用户对地图进行放大与缩小且不对结果数据造成任何影响。新的 geotile_grid 聚类将 geo_points 分组为多个数据桶，用于表示网格内的各个单元，且每一个单元都与地图中的图块相关联。
在发布这一更新之前，地形的纹理可能会随着缩放级别的变化而略微改变，这是因为矩形片段会在不同缩放级别中发生方向变化。7.0 版本中的 Elastic Maps 功能通过新的聚类确保视图在放大与缩小的同时依旧保持稳定。无论是希望保护网络免受攻击者入侵，调查特定位置的缓慢应用程序响应速度，还是追踪好朋友在特定地理位置上的徒步旅行，这种准确性都显得非常重要。
纳秒及精准度加强支持时间序列用例
无论是基础设施指标、系统审计日志、网络流量还是火星上的流动考察站，时间序列数据在众多实际用例当中已经成为 Elastic Stack 的核心素材。换言之，在多个系统与服务之间对事件进行精确地排序与关联，成为决定业务结果的关键所在。
在此之前，Elasticsearch 仅能够以毫秒精度存储时间戳。但 7.0 版本将这一水平大幅提升，如今能够实现纳秒级别的精度，这使得调频数据采集用户能够获得精确存储及排序此类数据所必需的时间控制能力。只需要由原有 JODA 库迁移至 JDK 8 中的官方 Java time API，即可享受到这一升级带来的强大助力。
(本文章转载自infoq, 如有侵权, 请联系作者删除)
网友评论