我们如何优化 Elasticsearch Serverless 中的刷新成本

作者：来自 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 实现的，它持久存储每个操作以保证数据持久性和在发生故障时恢复。

更多有关刷新的知识，请参考文章 “Elasticsearch：Elasticsearch 中的 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 相比，这导致特定无服务器工作负载的成本和用户体验面临挑战。批量对象存储上传使我们能够最大限度地减少对象存储请求的数量，并提高无服务器产品的成本效率。