广州做网站设计,天心区网站建设公司,如何做设计网站页面,郑州买房三大网站一、看点 在 2022 年 2 月 11 日#xff0c;Elasticsearch#xff08;ES#xff09;正式发布了 8.0 版本#xff0c;而截止到 2023 年 10 月#xff0c;历经一年半时间#xff0c;ES官方已经连续发布了多个版本#xff0c;最新版本为 8.10.4。这一系列的更新引入了众多引… 一、看点 在 2022 年 2 月 11 日ElasticsearchES正式发布了 8.0 版本而截止到 2023 年 10 月历经一年半时间ES官方已经连续发布了多个版本最新版本为 8.10.4。这一系列的更新引入了众多引人注目的新特性按照功能模块和重要性进行整理下面我们将介绍一些核心且引人瞩目的新功能。整体有以下看点 向量检索可以在集群中嵌入NLP模型ES适合做时序数据处理开箱即用的安全配置功能底层存储优化更丰富的地图搜索功能 二、最引人注目的就是向量检索 在 8.0版本 中提供新的kNN 搜索 API。这是一个里程碑的版本在此之前ES虽然支持向量检索但是是以脚本的方式提供的。虽然此方法可以保证准确的结果但它通常会导致搜索速度缓慢并且无法很好地适应大型数据集。它的性能是极低的。在8.0中引入了 kNN search API | Elasticsearch Guide [8.0] | Elastic的技术预览版。使用dense_vector字段k-nearest neighbor (kNN) search | Elasticsearch Guide [8.0] | Elastic可找到与查询向量最接近的k个向量通过相似性度量来衡量。kNN 通常用于为推荐引擎提供支持并根据自然语言处理 (NLP) 算法对相关性进行排名。以前Elasticsearch 仅支持使用script_score带有向量函数的查询进行精确的 kNN 搜索。虽然此方法可以保证准确的结果但它通常会导致搜索速度缓慢并且无法很好地适应大型数据集。作为索引速度较慢和准确性不完美的代价新的 kNN 搜索 API 允许您以更快的速度对更大的数据集运行近似 kNN 搜索。 在 8.4版本中把knn搜索加入到search API中以支持 ANN 搜索。它由与旧 _knn_search端点相同的 Lucene ANN 功能提供支持。该knn选项可以与其他搜索功能例如查询和聚合结合使用。 在 8.7版本中允许多个 KNN 搜索子句。某些向量搜索场景需要使用几个 kNN 子句进行相关性排名例如当基于多个字段进行排名时每个字段都有自己的向量或者当文档包含图像向量和文本向量时。用户可能希望获得基于所有这些 kNN 子句的组合的相关性排名。 在 8.8版本 中将 Introducing Elastic Learned Sparse Encoder: Elastic’s AI model for semantic search — Elastic Search Labs 模型引入到我们的机器学习模型库中您可以开箱即用。ELSER 通过启用语义搜索来提高搜索结果的相关性。这种搜索方法考虑单词的含义而不是仅仅依赖字面术语。ELSER 是一种预训练的域外稀疏向量模型无需对特定源数据进行微调。它从一开始就为您提供相关的搜索结果。并且在此版本中还提升了KNN检索语法加入了similarity参数允许过滤给定相似性之外的最近邻结果。 在8.9版本中。text_embedding query_vector_builderkNN 搜索的扩展普遍可用。 在8.10版本中启用跨段并行 knn 搜索使得 knn 查询对由多个段组成的分片更快来优化knn搜索的性能。 三、ES 开始支持 NLP模型能力 在8.0版本中可以上传在 Elasticsearch 之外训练的PyTorch模型并在摄取时使用它们进行推理。第三方模型支持将现代自然语言处理 (NLP)和搜索用例引入 Elastic Stack例如 Fill-maskNamed entity recognition (NER)Text classificationText embeddingZero-shot classification 在8.2版本中可以统计数据 NLP 推理速度。有三项新统计数据是 每分钟峰值吞吐量最后一分钟吞吐量平均推理时间毫秒最后分钟 目的是表明推理当前是否满足要求或者集群是否需要扩展以满足需求。最后一分钟的统计数据可以快速反馈以显示机器学习节点扩展的效果。 四、发布时间序列数据流TSDS功能 在 8.8 版本中Elasticsearch 提供对时间序列数据流 (TSDS) 索引的支持。TSDS 索引是包含时间序列指标数据作为数据流一部分的索引。Elasticsearch 将传入文档路由到 TSDS 索引中以便特定时间序列的所有文档都位于同一分片上然后按时间序列和时间戳对分片进行排序。这种结构有几个优点 1.同一时间序列的文档在分片上彼此相邻因此在磁盘上彼此相邻存储因此操作系统页面更加同质并且压缩效果更好从而大幅降低 TCO。 2.时间序列的分析通常涉及比较每两个连续的文档样本、检查给定时间窗口中的最后一个文档等当下一个文档可能位于任何分片上并且实际上位于任何索引上时这是相当复杂的。按时间序列和时间戳排序可以改进分析无论是在性能方面还是在我们添加新聚合的能力方面。 3.最后作为指标数据时间序列索引生命周期管理的一部分Elasticsearch 启用下采样操作。当对索引进行下采样时Elasticsearch 会保留一个文档其中包含时间序列中每个时间段的统计摘要。然后支持的聚合可以在数据流上运行并包括下采样索引和原始数据索引而用户无需意识到这一点。还支持对下采样索引进行下采样以达到更粗略的时间分辨率。 Time series data stream (TSDS) | Elasticsearch Guide [8.7] | Elastic是一项用于优化时间序列数据的 Elasticsearch 索引的功能。这涉及对索引进行排序以实现更好的压缩并使用合成 _source 来减小索引大小。因此TSDS 指数明显小于包含相同数据的非时间序列指数。TSDS 对于管理大量时间序列数据特别有用。并且提供了采样优化算法可减少 Elasticsearch 时间序列索引中存储的文档数量从而缩小索引并改善查询延迟。这种优化是通过预先聚合时间序列索引来实现的使用 time_series 索引模式来识别时间序列。下采样被配置为 ILM 中的一项操作使其成为管理 Elasticsearch 中大量时间序列数据的有用工具。 五、开箱即用的安全配置功能 在8.0版本中ES官方为我们提供了开箱即用的安全功能。在此之前都要经过一系列复杂的操作才能拥有安全能力。 在没有安全性的情况下运行 Elasticsearch 会使您的集群暴露给任何可以向 Elasticsearch 发送网络流量的人。在以前的版本中您必须显式启用 Elasticsearch 安全功能例如身份验证、授权和网络加密 (TLS)。从 Elasticsearch 8.0 开始 首次启动 Elasticsearch 时Start the Elastic Stack with security enabled | Elasticsearch Guide [8.0] | Elastic 启动时我们会生成注册令牌您可以使用该令牌连接 Kibana 实例或在安全的 Elasticsearch 集群中注册其他节点而无需生成安全证书或更新 YAML 配置文件。只需在启动新节点或 Kibana 实例时使用生成的注册令牌Elastic Stack 就会为您处理所有安全配置。开箱即用您将得到 用户认证用户授权使用 TLS 进行加密的节点间通信Elasticsearch 和 Kibana 之间使用 TLS 进行加密通信 需要新的注册令牌吗使用该 elasticsearch-create-enrollment-token | Elasticsearch Guide [8.0] | Elastic 工具为 Elasticsearch 节点和 Kibana 实例创建注册令牌。 六、底层存储优化与性能提升 1.keyword、match_only_text、 和text字段的存储节省 在8.0版本中更新了倒排索引一种内部数据结构以使用更节省空间的编码。这种变化将有利于keyword各个领域、 match_only_text各个领域以及在较小程度上的text各个领域。在我们使用应用程序日志的基准测试中这意味着字段索引大小message映射为match_only_text减少了 14.4%磁盘占用空间总体减少了 3.5%。 2.更快地索引geo_point、geo_shape和范围字段 在8.0版本中优化了多维点的索引速度多维点是用于geo_point、geo_shape和范围字段的内部数据结构。Lucene 级基准测试报告称这些字段类型的索引速度提高了 10-15%。主要由这些字段组成的 Elasticsearch 索引和数据流可能会显着提高索引速度。 3.管道处理性能提升 在8.3版本中通过避免深度递归改进了具有同步处理器的管道的管道执行逻辑。在我们模拟日志记录用例的夜间基准测试中这导致摄取管道上花费的 CPU 时间减少了 10%整体摄取速度提高了 3%。 4.filters/range/date_histogram aggs 性能提升 在8.4版本中在没有子聚合时对聚合进行提速。这非常常见例如Kibana 的发现选项卡顶部的直方图没有date_histogram任何子聚合。在我们的集会测试中该特定聚合速度加快了约 85%从 250 毫秒降至 30 毫秒。 5.使用显式“_id”改进了 get、mget 和索引的性能 在8.7中将布隆过滤器的误报率_id从约 10% 降低至约 1%从而减少了段中不存在术语时的 I/O 负载。这可以提高通过 检索文档时的性能_id这种情况发生在执行 get 或 mget 请求时或者发出_bulk提供显式 _id 的请求时。 6.Encode using 40, 48 and 56 bits per value 在8.8版本中做了编码的提升。 使用编码如下 * 对于每个值采用 [33, 40] 位的值使用每个值 40 位进行编码 * 对于每个值采用 [41, 48] 位的值使用每个值 48 位进行编码 * 对于采用 [ 49, 56] 每个值位使用每个值 56 位进行编码 这是对 ForUtils 使用的编码的改进ForUtils 不对每个值超过 32 位的值应用任何压缩。 请注意每个值的 40、48 和 56 位表示字节的精确倍数每个值 5、6 和 7 个字节。因此我们总是使用比长值所需的 8 个字节少 3、2 或 1 个字节的值来写入值。 看看存储字节的节省对于 128 个长值的块我们通常会存储 128 x 8 字节 1024 字节而现在我们有以下内容 * 每个值 40 位写入 645 字节而不是 1024 字节节省379 字节 (37%) * 每个值 48 位写入 772 字节而不是 1024节省 252 字节 (24%) * 每个值 56 位写入 897 字节而不是 1024节省 127 字节 (12%) 还将压缩应用于规格指标假设每个值超过 32 位的压缩值对于浮点值效果很好因为浮点值的表示方式IEEE 754 格式。 7.并发索引和搜索下更好的索引和搜索性能 在8.9版本中提升并发索引和搜索的性能。当像匹配短语查询或术语查询这样的查询针对常量关键字字段时我们可以跳过分片上的查询执行其中查询被重写以不匹配任何文档。我们利用包括常量关键字字段的索引映射并以这样的方式重写查询如果常量关键字字段与索引映射中定义的值不匹配我们将重写查询以匹配任何文档。这将导致分片级别请求在数据节点上执行查询之前立即返回从而完全跳过分片。在这里我们利用尽可能跳过分片的功能来避免不必要的分片刷新并改善查询延迟通过不执行任何与搜索相关的 I/O。避免这种不必要的分片刷新可以改善查询延迟因为搜索线程不再需要等待不必要的分片刷新。不匹配查询条件的分片将保持搜索空闲状态索引吞吐量不会受到刷新的负面影响。在引入此更改之前查询命中多个分片包括那些没有与搜索条件匹配的文档的分片考虑使用索引模式或具有许多支持索引的数据流可能会导致“分片刷新风暴”从而增加查询延迟搜索线程等待所有分片刷新完成后才能启动和执行搜索操作。引入此更改后搜索线程只需等待包括相关数据的分片刷新完成。请注意分片预过滤器的执行以及重写发生的相应“可以匹配”阶段取决于所涉及的分片总数以及是否至少有一个分片返回非空结果请参阅 pre_filter_shard_size设置为了解如何控制这种行为。Elasticsearch 在所谓的“可以匹配”阶段对数据节点进行重写操作利用这样一个事实此时我们可以访问索引映射并提取有关常量关键字字段及其值的信息。这意味着我们仍然将搜索查询从协调器节点“扇出”到相关数据节点。在协调器节点上不可能基于索引映射重写查询因为协调器节点缺少索引映射信息。 七、更高效的快照 8.5版本中快照操作的开销已显着减少。快照现在以更高效的顺序运行并且需要的网络流量比以前少得多。 八、更丰富的地图搜索功能
