推几个学习网站,如何修改网站后台,备案 通过后 网站打不开,wordpress yuti作者#xff1a;来自 Elastic Francisco Fernndez Castao, Henning Andersen 最近#xff0c;我们推出了 Elastic Cloud Serverless 产品#xff0c;旨在提供在云中运行搜索工作负载的无缝体验。为了推出该产品#xff0c;我们重新设计了 Elasticsearch#xff0c;将存储与…作者来自 Elastic Francisco Fernández Castaño, Henning Andersen 最近我们推出了 Elastic Cloud Serverless 产品旨在提供在云中运行搜索工作负载的无缝体验。为了推出该产品我们重新设计了 Elasticsearch将存储与计算分离数据存储在云 blob 存储中提供几乎无限的存储和可扩展性。在这篇博文中我们将深入探讨如何消除索引数量和对象存储调用数量之间的强关系从而让我们能够同时改善用户体验并降低成本。
在深入研究所做的更改之前首先必须了解 Elasticsearch 和 Lucene 之间的相互作用。
Elasticsearch 使用 Lucene一个用 Java 编写的高性能开源库进行全文索引和搜索。当文档被索引到 Elasticsearch 中时Lucene 不会立即将其写入磁盘。相反Lucene 会更新其内部内存数据结构。一旦积累了足够的数据或触发了刷新refresh这些文档就会被写入磁盘从而创建一组新的不可变文件在 Lucene 术语中称为段 - segemnts。在将段写入磁盘之前索引文档无法进行搜索。这就是为什么刷新是 Elasticsearch 中如此重要的概念的原因。你可能想知道当文档保存在内存中直到触发刷新时如何确保持久性。这是通过 Translog 实现的它持久存储每个操作以保证数据持久性和在发生故障时恢复。 更多有关刷新的知识请参考文章 “ElasticsearchElasticsearch 中的 refresh 和 flush 操作指南”。 现在我们知道了 Lucene 段是什么以及为什么 Elasticsearch 需要刷新我们可以探索有状态 Elasticsearch 和 serverless Elasticsearch 之间的刷新行为有何不同。 有状态 Elasticsearch 中的刷新
在 Elasticsearch 中索引被分为多个分片每个分片由一个主分片和多个可能的副本分片组成。在有状态stateful Elasticsearch 中当文档被索引时它首先被路由到主分片Lucene 在那里对其进行处理和索引。在主分片上进行索引后文档被路由到副本分片在那里由这些副本对其进行索引。
如前所述需要刷新才能使这些索引文档可搜索。在有状态 Elasticsearch 中刷新会将 Lucene 内存数据结构写入磁盘而无需执行 fsync。刷新是定期安排的每个节点在不同的时间执行它们。此过程将在每个节点上创建不同的 Lucene 段文件所有文件都包含同一组文档。 Serverlss Elasticsearch 中的刷新
相比之下无服务器serverless Elasticsearch 采用基于段的复制模型。在这种方法中每个分片的一个节点负责处理文档索引并生成 Lucene 段。一旦启动刷新这些段就会上传到 blob 存储中。随后搜索节点会收到有关这些新的 Lucene 段的通知它们可以直接从 blob 存储中读取这些段。 上图演示了无服务器 Elasticsearch 中的刷新工作原理
索引节点所有文档都已编入索引接收刷新请求Lucene 将内存中的数据结构写入磁盘类似于有状态刷新的运行方式。段文件作为单个文件上传到 blob 存储称为无状态复合提交。图中上传的是 S4。将段文件上传到 blob 存储后索引节点会向每个搜索节点发送一条消息通知它们新的段文件以便它们可以对新编入索引的文档执行搜索。搜索节点在执行搜索时从 blob 存储中获取必要的数据。
此模型具有轻量级节点的优势因为数据存储在 blob 存储中。与有状态 Elasticsearch 相比这使得在节点之间扩展或重新分配工作负载更具成本效益在有状态 Elasticsearch 中数据必须传输到包含新分片的新节点。
值得考虑的一个方面是无服务器 Elasticsearch 中每次刷新相关的额外对象存储请求成本。每次刷新操作都会在对象存储中创建一个新对象从而产生一个对象存储 PUT 请求并产生相关成本。这导致索引数量与对象存储 PUT 请求数量之间存在线性关系。如果刷新次数足够多对象存储成本可能会超过硬件本身的成本。为了解决这个问题我们最初实施了刷新限制措施以有效管理成本并缓解潜在的问题。这篇博文描述了这项工作的下一步这使我们能够以更快的速度和可控的成本进行刷新。 刷新成本优化
如前所述无服务器 Elasticsearch 架构提供了许多好处。但是为了有效地管理刷新成本我们做出了偶尔会影响用户体验的决定。其中一个决定是强制执行 15 秒的默认刷新间隔这意味着在某些情况下新索引的数据要等到 15 秒过去后才能搜索。尽管我们付出了努力但还是出现了对象存储费用过高的情况促使我们重新评估我们的方法。在本节中我们将深入研究如何成功地将刷新操作与对象存储调用分离以在不影响用户体验的情况下解决这些挑战。
在评估了各种解决方案从在 NFS 等分布式文件系统中临时存储段到将段直接推送到搜索节点后我们决定采用一种依赖于将段数据从索引节点直接提供给搜索节点的方法。
索引节点现在不会让刷新立即将新的 Lucene 段上传到 blob 存储而是从刷新中积累段然后将它们作为单个 blob 上传。这使得索引节点能够以类似于 blob 存储的方式为搜索节点提供读取服务延迟分段上传直到积累足够的数据或经过预定的时间间隔。
此策略使我们能够完全控制上传到 blob 存储的 blob 的大小使我们能够确定请求成本与硬件成本相比何时可以忽略不计。 批量复合提交
我们的目标是逐步实现这一增强功能并确保与存储在 Blob 存储中的现有数据的向后兼容性。因此我们选择在 Blob 存储中存储 Lucene 段时使用相同的文件格式。就上下文而言Lucene 段包含多个文件每个文件都充当不同的角色。为了简化上传过程并最大限度地减少 PUT 请求我们引入了复合提交单个 Blob 连续包含所有段文件并附带元数据标头其中包括复合提交中的文件目录。 从 blob 存储中检索复合提交时例如在分片重新定位期间我们的主要关注点通常放在复合提交标头header上。此标头至关重要因为它包含及时填充内部数据结构所需的基本数据。考虑到这一点我们意识到我们可以保留现有文件格式但对其进行简化以便每个 blob 可以按顺序逐个附加复合提交。我们将这种新文件格式称为批量复合提交。 由于每个复合提交的大小都存储在其标头中因此检索批量复合提交中所有复合提交的标头非常简单我们只需查找下一个条目即可按顺序读取每个标头。在处理旧格式的 blob 时它们被视为单例批量复合提交。我们的文件格式的另一个关键方面是一旦将每个 Lucene 段文件附加到批量复合提交中就会为其保持固定偏移量。这确保了文件是从索引节点还是 blob 存储提供的一致性。当批量复合提交最终上传到 blob 存储时它还可以避免在搜索节点上逐出缓存条目。 新的刷新生命周期
索引节点现在将从刷新中积累 Lucene 段直到收集到足够的数据以将它们上传为单个 blob。让我们探索索引和搜索节点如何协调以确定从何处访问这些数据。 如上图所示在无服务器 Elasticsearch 中优化的刷新过程中会发生以下步骤
索引节点接收刷新请求将一组新的 Lucene 段写入其本地磁盘并将这些段添加到待处理的批量复合提交中以供最终上传。索引节点将这些新段通知搜索节点提供有关所涉及段及其位置blob 存储或索引节点的详细信息。当搜索节点需要一个段来完成查询时它会决定是从 blob 存储还是索引节点获取该段并在本地缓存数据。 上图说明了在索引节点中积累了足够多的段或经过了指定的时间后将数据上传到无服务器 Elasticsearch 中的 Blob 存储的过程。
刷新会将新段添加到分批复合提交中并且累积的数据达到 16 MB或者自上次刷新以来已经过了一段时间从此时起新段将累积到新的分批复合提交中。索引节点开始将累积的段作为单个 Blob 上传到对象存储。索引节点将最新上传到对象存储的段通知搜索节点副本search node replicas指示它们从 Blob 存储中获取这些段的数据。如果搜索需要本地未缓存的数据它将从 Blob 存储中检索必要的信息而任何先前从索引节点获取的数据即使在上传后仍然有效。 考虑和权衡
所选方法模糊了存储和计算之间的明确区分要求索引节点处理存储请求直到 Lucene 段最终上传到 blob 存储。但是这些存储请求的开销很小我们没有观察到对索引吞吐量的影响。
我们会注意到我们会保留 translog 条目直到相应的数据已上传到 blob 存储因此该方法保持了现有的数据安全保障。崩溃后的恢复时间可能会稍长一些但我们认为这是一个可以接受的权衡。 结论
这篇博文探讨了我们向更云原生方法的过渡强调了它的诸多好处以及关键的成本考虑。我们从一个模型中追溯了我们的演变过程在这个模型中每个新的 Lucene 段都会在对象存储中生成一个不同的对象。与有状态的 Elasticsearch 相比这导致特定无服务器工作负载的成本和用户体验面临挑战。批量对象存储上传使我们能够最大限度地减少对象存储请求的数量并提高无服务器产品的成本效率。 准备好亲自尝试一下了吗开始免费试用。 想要获得 Elastic 认证吗了解下一期 Elasticsearch 工程师培训何时开课 原文Elasticsearch refresh: How we optimized refreshes in Serverless — Search Labs
