dns 国外网站电脑培训课程

当前位置： 首页 > news >正文

dns 国外网站,电脑培训课程,2023年商标注册流程图,镇江网站建设平台作者#xff1a;来自 Elastic Andrei Dan 在 Elastic Cloud Serverless 中#xff0c;我们根据索引负载自动为数据流配置最佳分片数量#xff0c;从而使用户无需摆弄分片。 传统上#xff0c;用户会更改数据流的分片配置#xff0c;以处理各种工作负载并充分利用可用资源。…作者来自 Elastic Andrei Dan 在 Elastic Cloud Serverless 中我们根据索引负载自动为数据流配置最佳分片数量从而使用户无需摆弄分片。 传统上用户会更改数据流的分片配置以处理各种工作负载并充分利用可用资源。在 Elastic Cloud Serverless 中我们引入了数据流的自动分片使其能够根据索引负载自动管理和扩展。这篇文章探讨了自动分片的机制、其好处以及它对处理可变工作负载的用户的影响。自动分片的理念是积极增加分片数量并非常谨慎地减少分片数量这样分片的增加不会因为工作负载在短时间内减少而过早地减少分片数量。 无服务器 Elasticsearch 中的数据流自动分片 想象一下你有一个大披萨需要在聚会上与朋友们分享。如果你将披萨切成两片供六个朋友食用那么每片都需要供多人食用。这将造成瓶颈一个人独占一整片而其他人则在等待导致共享过程缓慢。此外并不是每个人都能同时享用披萨你几乎可以听到那些等待的朋友的叹息声。如果更多的朋友意外出现你将很难用两片披萨喂饱他们并发现自己不得不当场手忙脚乱地重新塑形。 另一方面如果你把披萨切成 36 片小块给同样的六个朋友管理分享就变得很棘手。每个人都没有享受披萨而是花更多的时间想办法拿到自己的小份。如果切片太小披萨甚至可能会散开。 为了确保每个人都能高效地享用披萨你应该把它切成与朋友数量相匹配的片数。如果你有六个朋友把披萨切成 6 片或 12 片每个人都可以拿到一片而不用等很长时间。通过在切披萨时找到合适的平衡你将让聚会顺利进行让每个人都开心。 当你立即跟进解释时你就知道这是一个很好的比喻披萨代表数据切片代表索引分片朋友是集群中的 Elasticsearch 节点。 传统上Elasticsearch 的用户必须预测他们的索引吞吐量并手动配置每个数据流data stream的分片数量。这种方法严重依赖于预测启发式方法需要根据工作负载特征进行持续调整同时还要平衡数据存储、搜索分析和应用程序性能。 零售等具有季节性流量的企业通常会处理数据需求激增的问题而物联网应用程序可能会在特定时间经历负载的快速增加。开发和测试环境通常每周只运行几个小时这使得固定分片配置效率低下。新应用程序可能难以准确估计工作负载需求从而导致潜在的过度或不足配置。 我们在 Elastic Cloud Serverless 中引入了数据流的自动分片。Serverless 中的数据流根据索引负载自动管理和扩展 - 当朋友到达你的聚会或吃完时自动切片你的披萨。 自动分片的承诺 自动分片通过根据当前索引负载自动调整分片数量来解决这些挑战。这意味着用户无需手动调整配置Elasticsearch 将根据实时数据流量动态管理项目中数据流的分片数量。 Elasticsearch 将每个索引的索引负载作为名为写入负载的指标的一部分进行跟踪并将其作为索引部分下索引统计 API index stats API的一部分公开给本地和 ESS 部署。 write_load 表示索引文档时使用的平均写入线程数。 对于具有一个分片的索引write_load 指标的最大可能值是可用的写入线程数例如所有写入线程都忙于在同一个分片中写入。 对于具有多个分片的索引写入负载的最大可能值是节点中可用的写入线程数乘以项目中的索引节点数。例如托管我们索引的分片的所有索引节点上的所有写入线程都忙于在属于我们索引的分片中写入仅此而已 为了了解 write_load 允许的值让我们查看索引 logs其中一个分片在一台分配了 2 个处理器的 Elasticsearch 机器上运行。写入线程池的大小将为 2 个线程。这意味着如果此 Elasticsearch 节点专门且持续地写入相同的索引日志我们将报告的索引日志的 write_load 将为 2.0即 2 个写入线程完全用于写入索引日志。 如果 logs 有 2 个主分片并且我们现在在两个 Elasticsearch 节点上运行每个节点分配有 2 个处理器如果两个 Elasticsearch 节点上的所有写入线程都专门写入日志索引我们将能够获得最大报告的 write_load 4.0。 无服务器自动扩展 我们刚刚研究了当我们增加分片和 Elasticsearch 节点的数量时写入 write load 如何翻倍。Elastic Cloud Serverless 使用数据流自动分片和摄取自动扩展ingest autoscaling自动处理这两项操作。自动扩展是指根据当前需求动态调整资源如内存、CPU 和磁盘的过程。 在我们的无服务器架构中我们从一台小型 2GB 内存服务器开始并使用阶跃函数扩展方法来有效增加容量。我们逐步增加内存然后通过添加服务器进行扩展。这个循环继续在管理服务器数量的同时逐步将每台服务器的内存增加到 64GB。 将自动扩展和自动分片联系起来 自动扩展和自动分片之间的联系对于优化性能至关重要。在计算数据流的最佳分片数量时我们会考虑扩展设置中每个节点可用的最小和最大写入线程数。 对于小型项目当数据流使用超过节点容量的一半即超过一个索引线程时系统将从 1 个分片移动到 2 个分片。对于中型项目由于系统跨多个节点扩展因此不会超过 3 个分片以避免过多的开销。一旦我们达到最大的节点大小就会启用进一步的分片以适应更大的工作负载。 自动分片还可以使项目达到更高的摄取负载值从而实现自动扩展以根据需要增加资源防止系统在高索引工作负载期间保持低容量。 自动分片公式 为了确定所需的分片数量我们使用以下公式 此公式平衡了根据 write_load 增加分片的需求同时限制了分片数量以防止过度分片。除以 2 反映了仅在超过节点容量的一半后才增加分片的策略。最小/最大写入线程表示自动缩放步骤函数中可用的最小和最大写入线程数即最小 2GB 步骤上可用的写入线程数和最大服务器上可用的写入线程数 让我们可视化公式的输出 Y 轴表示分片数量。X 轴表示写入负载write load。我们从 1 个分片开始当写入负载刚好超过 3.0 时分片数量增加到 3 个。在写入负载达到 48.0 左右之前我们会一直使用 3 个分片。 这涵盖了我们通过节点扩展但尚未达到 2 个或更多或最大服务器的时间此时我们会解锁自动分片到 3 个以上的分片数量与提取数据所需的数量相同。 虽然添加分片可以提高索引性能但 Elasticsearch 集群中的过度分片可能会产生负面影响 - 想象一下只有 7 个朋友分享 56 片披萨。每个分片都有间接成本包括维护和资源分配。我们的算法考虑并避免了过度分片的危险直到我们达到最大的工作负载此时添加超过 3 个分片会对索引性能和吞吐量产生重大影响。 使用滚动实现自动分片 自动分片的实现依赖于滚动rollover的概念。滚动操作会在数据流data stream中创建一个新索引将其提升为写入索引同时将前一个索引指定为常规后备索引不再接受写入。这种转变可能基于特定条件发生例如超过 50GB 的分片大小。我们负责为无服务器中的数据流配置最佳滚动条件optimal rollover conditions。 在无服务器Serverless中除了与维护健康索引和分片相关的常规滚动条件外我们还引入了一个新条件用于评估当前写入负载是否需要增加分片数量。如果满足此条件将触发滚动并为新生成的数据流写入索引write index配置最佳分片数量。 对于缩减规模系统将监控工作负载不会仅仅为了减少分片而触发滚动。相反它将等到常规滚动条件如主分片大小触发滚动。生成的写入索引将配置较少数量的分片。 分片调整的冷却期 为了确保分片调整期间的稳定性我们实施了冷却期 ​​增加分片冷却时间自上次调整以来在增加分片数量之前强制执行至少 4.5 分钟的等待时间。4.5 分钟的冷却时间可能看起来很奇怪但选择这个间隔是为了确保我们每次在数据流生命周期data stream lifecycle检查数据流是否应该滚动时目前每 5 分钟一次可以增加分片数量但频率不会超过 5 分钟以涵盖内部 Elasticsearch 集群重新配置。减少分片冷却时间在减少分片之前我们保持 3 天的最低等待时间以确保决策基于持续的工作负载模式而不是暂时的波动。 结论 无服务器 Elasticsearch 中的数据流自动分片功能代表了有效管理数据流的重大进步。通过根据实时索引负载自动调整分片数量此功能简化了操作并增强了可扩展性。 借助自动扩展的额外优势用户可以期待更高效、响应更快的体验无论他们是在处理小型项目还是大型应用程序。随着数据工作负载的不断发展自动分片提供的适应性确保 Elasticsearch 仍然是管理各种索引需求的强大解决方案。 试用我们的无服务器 Elasticsearch 产品利用数据流自动分片并观察索引吞吐量随着数据提取负载的增加而无缝扩展。 随着越来越多的朋友来到你的聚会你的披萨将被最佳地切成薄片他们渴望尝试您为他们准备的酸面团手工披萨。 了解有关 Elastic Cloud Serverless 的更多信息并开始 14 天免费试用以亲自测试。 原文Autosharding of data streams in Elasticsearch Serverless - Elasticsearch Labs