网站建设公司与前端,脚底长了像水泡一样的东西很痒什么原因,crm管理系统在线使用,怎么自己给自己的网站做推广在我在之前的文章 “Elasticsearch#xff1a;彻底理解 Elasticsearch 数据操作” 文章中#xff0c;我详细地描述了如何索引数据到 Elasticsearch 中。在今天的文章中#xff0c;我想更进一步来描述这个流程。
Elasticsearch 是一个非常强大和灵活的分布式数据系统#x…
在我在之前的文章 “Elasticsearch彻底理解 Elasticsearch 数据操作” 文章中我详细地描述了如何索引数据到 Elasticsearch 中。在今天的文章中我想更进一步来描述这个流程。
Elasticsearch® 是一个非常强大和灵活的分布式数据系统接受数十亿个文档并为其建立索引使它们可以近乎实时地用于搜索、聚合和分析。 本文将介绍如何做到这一点重点介绍基本的新数据插入和从请求一直到磁盘的数据流。
索引是一个相对简单的高级过程包括
通过 API 到达数据路由到正确的索引、分片和节点映射、规范化和分析存储在内存和磁盘上使其可供搜索
然而实际过程要复杂得多尤其是考虑到集群及其数据的分布式特性、涉及的高数据速率以及同时进行的所有事情的并行特性。 此外这一切都必须尽可能可靠和可扩展。 这就是 Elasticsearch 的神奇之处。
让我们更详细地看一下这些步骤。充分了解这个过程对于我们如何优化 Elasticsearch 集群及操作以提高其索引数据的速度非常重要。 API 请求和分批
当数据通过索引 API 到达时Elasticsearch 首先了解要索引的传入数据。 Logstash、Beats 甚至 cURL 等客户端将数据发送到集群的节点进行处理。 他们一次可以发送一个文档但通常使用批量 API 批量发送数据以减少开销并加快处理速度。 批次只是在一个 API 调用中发送的一组文档不需要相关即它们可以包含发往多个不同索引的数据。 摄取数据可以发送到任何节点。 然而更大的集群通常使用专用协调节点更多用于搜索而不是摄取甚至专用摄取节点它们可以运行数据管道来预处理数据。 数据到达的任何节点都将成为该批次的协调节点并将数据路由到正确的位置即使实际摄取工作是在保存目标索引数据的数据节点上执行的。 管道和数据流
数据最常到达单个标准索引但也可以路由到数据流data stream或摄取管道ingest pipeline。 数据流是 X-Pack 的一项功能最常用于处理时间序列数据例如指标和日志并且基本上解析为该摄取过程的实际支持索引。 管道是处理器的集合用于在索引之前处理文档数据。
如果请求或批处理包含管道并且协调节点不是摄取节点则它似乎会首先路由到摄取节点然后继续到主节点。 目前尚不清楚协调器或摄取节点是否将其发送到主节点primary node即 primary shard 所在的节点但可能是协调节点即摄取节点运行管道后然后将文档返回到协调器节点以进行下一步也即下面将要讲到的 Routing。 路由 - Routing
一旦数据到达协调节点每个文档都必须路由到正确的索引、分片和节点以进行摄取。 由于批量请求可能包含许多索引的数据并且单个索引的多个文档可能会转到不同的分片因此路由步骤是针对每个文档运行的并且对于将每个文档都送到正确的位置非常重要。 此过程启动 “协调阶段”。
每个文档的第一步是协调节点使用提供的索引、别名、数据流等来确定文档将要到达的实际目标索引。 如果索引不存在将创建它然后该过程可以继续。 请注意Elasticsearch 在执行任何索引之前会尝试首先创建批量请求所需的所有索引。
协调节点知道目标索引后它会运行一个路由过程来为文档选择索引的分片。 路由可能会变得复杂默认情况下由文档 ID 驱动默认情况下它由协调节点自动生成。
如果你愿意客户端可以指定自己的 ID还可以控制用于路由的字段例如时间戳、用户、源设备等作为集群策略将相关且可快速查询的数据共同定位在一个单一的分片。 此外索引可以具有将文档强制到特定分片的自定义路由。 但一般来说每个文档都会随机分布在其目标索引的分片中。
路由过程的结果将是目标分片及其分片 ID但我们必须记住分片可能有副本。 如果有副本协调节点也会将它们包含在路由列表中因此结果是该文档的所有分片的列表主分片和副本。 协调节点然后查找这些分片的节点 ID以了解将文档路由到何处以进行索引。 索引阶段 - indexing stage
一旦协调节点知道文档的目标主分片和该分片的节点文档将被发送到该节点以进行主索引作为 “初级阶段” 的一部分。 主分片验证请求然后在本地索引它们这也验证了映射、字段等。 下面更详细地描述了该过程。
如果主节点索引成功主分片节点不是协调节点将文档并行发送到所有 “in-sync” “active” 副本即 “Replica Stage”。 主分片节点等待所有副本完成索引然后将结果返回给等待的协调节点。 一旦批处理中的所有文档都被索引或失败协调器就会将结果返回给原始 API 调用者即客户端。 每个文档都由其每个主分片和副本分片分别索引。 必须了解每个文档都由它将存在的每个分片分别索引并且所有这些都必须在给定文档被 “索引” 之前完成。 因此如果一个索引的副本数为 3这意味着每个文档都将转到四个分片主分片和三个副本并分别由这些分片索引所有分片都在不同的节点上。 Elasticsearch 中没有真正的预处理或中央索引并且集群完成的 “工作” 随着给定索引的副本数量线性增加。 这通常是大多数索引延迟发生的地方因为它只能像最慢的节点和分片一样慢地完成。
协调器节点尽可能多地并行化一批文档。 它并行地将文档发送到它们的路由主分片但似乎只对每个主分片排队一个请求。 因此如果批次有 10 个文档用于单个索引和单个分片这些将全部按顺序处理一次处理一个但是如果批次有 10 个文档用于两个索引每个索引有 5 个分片并且路由结果为一个每个分片的文档所有 10 个将并行完成。 这是额外的主分片加速处理的一种方式。 分片级索引
一旦文档到达拥有它将驻留的分片的给定节点实际的文档索引就完成了。 第一步是将文档写入 translog 以获得持久副本以防在此之后节点崩溃。
Translog 是 Elasticsearch 的一项功能提供了 Lucene 自身无法做到的持久性并且是可靠系统的关键。 如果节点在实际索引完成之前崩溃则在重新启动时 Elasticsearch 会将文档重播到索引过程中以确保它得到处理。更多关于 translog 的描述清阅读文章 “ElasticsearchElasticsearch 中的 refresh 和 flush 操作指南”。 实际的索引过程有几个步骤
在 Elasticsearch 中映射文档字段在 Lucene 中分析添加到 Lucene 中的倒排索引
首先节点通过索引模板映射文档的字段该模板指定如何处理每个字段例如类型但也包括分析器和其他选项。 由于每个文档都可以有不同的字段和数据所以这个映射步骤是必不可少的也是经常发生错误的地方因为字段类型不匹配、超出范围等。 这项工作是在 Elasticsearch 级别完成的因为 Lucene 没有模板或映射的概念。 Lucene 文档只是一组字段每个字段都有名称、类型和值。
其次文档被传递给 Lucene后者将对其进行 “分析”。 实际上这意味着在其上运行配置的分析器每个分析器可以有几个步骤和组件包括标记化和过滤它们一起可以做很多强大的事情。有关分析器方面的知识请阅读文章 “Elasticsearch: analyzer”。
分词化将每个字段中的数据拆分为分词例如在空格上分隔单词和过滤包括除了基本过滤之外的广泛内容以小写文本删除停用词和通过词干归一化即改变单词到他们的 “正常” 版本例如 dogs 变成 dogwatched 变成 watch 等 最后Lucene 获取结果并为此文档构建存储记录。 这通常包括文档中的每个字段以及可用于重新索引等的特殊字段例如 _source 和 _all 等。 以及最重要的倒排索引本身。
Lucene 将所有这些写入内存中的段缓冲区然后成功返回协调节点。 在所有副本分片上完成此操作后从协调器节点或客户端的角度来看该文档的索引基本上已完成。 获取磁盘上的文档数据并可搜索
刚刚建立索引的文档只在内存中的临时多文档段中还没有在磁盘上也不能用于搜索。 两个独立的进程在幕后运行以实现这两件事。 索引数据尚未在磁盘上也不可搜索。 第一个过程是 “refreshing” 以使数据可用于搜索。 刷新间隔按索引设置默认为 1 秒。 许多用户将此设置得更高例如 30-60 秒因为这是一项昂贵的操作并且每秒执行一次会降低整体索引吞吐量。 请注意不经常搜索的索引在搜索之前不会自动刷新以提高批量索引速度。有关 refresh 操作的描述请阅读文章 “ElasticsearchElasticsearch 中的 refresh 和 flush 操作指南”。
在刷新间隔内存缓冲区的段被合并并写入文件系统上的单个新段并且数据可用于搜索。 但是虽然这个段现在存在于文件系统上但它主要在文件缓存中实际上可能不在磁盘上如果此时出现崩溃这就是一个问题。 数据可用但不安全但如果发生崩溃translog 仍然存在并会被回放文档会重新被索引。
为了使数据在磁盘上安全有一个单独的 Elasticsearch 刷新过程执行 Lucene 提交合并和 fsyncs 上述段确保它们确实在磁盘上。 完成后Elasticsearch 会截断传输日志因为数据现在安全地保存在磁盘上不会在崩溃中丢失。 Elasticsearch 根据传输日志大小默认最大值为 512MB安排这些刷新以帮助保持合理的恢复时间。
本质上translog 维护所有新文档更改的可靠性以及 Elasticsearch 刷新/Lucene 提交之间的可靠性。 请注意translog 有其自己的可靠性设置包括每 5 秒 fsync 到磁盘的默认值。
Elasticsearch 还单独运行后台线程以尽可能继续合并段使用分层合并策略尝试最小化段segment数因为它们是按顺序搜索的同时不会降低整体实时索引和搜索性能。 这与上述所有过程都是分开的。
总体结果是在任何给定时间任何特定的可用索引都由磁盘上一组大小不同的永久段和文件缓存中的一些新段组成。 加上仅在内存中的索引但尚未可用的段等待刷新间隔。 问题
Elasticsearch 索引是一个很好但很复杂的分布式过程它平衡了高性能、数据可靠性和强大的功能。 虽然它运作良好但事情可能而且确实会出错。 有些问题出在文档本身而另一些则出在集群方面。
集群级问题通常与分片丢失或过程中的移动有关。 正常的流程是从协调器节点到主节点再到副本节点但是如果主节点在这个过程中发生变化或者副本丢失了怎么办 尽管尝试保存文档有各种复杂的重试、超时和路由过程当然它们可能会失败此时客户端必须重试。
其中一些例如副本超时或失败将导致该分片被声明为不同步和无效将索引状态更改为黄色并安排副本重建。 其他的比如网络分区会导致主节点本身被声明为无效当它试图与副本对话时会发现这一点。 总的来说这是一个复杂但强大的系统。
