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

最近，我们发布了 Elastic Cloud Serverless 产品，旨在提供在云中运行搜索工作负载的无缝体验。为此，我们重新架构了 Elasticsearch，以解耦存储和计算，数据存储在提供几乎无限存储和可扩展性的云 Blob 存储中。在这篇博文中，我们将深入探讨我们如何消除索引数量和对象存储调用次数之间的强关联，从而同时改进用户体验并降低成本。

在我们深入了解所做的更改之前，首先了解 Elasticsearch 和 Lucene 之间的相互作用至关重要。

Elasticsearch 使用 Lucene（一个用 Java 编写的功能强大的开源全文索引和搜索库）。当文档被索引到 Elasticsearch 中时，Lucene 不会立即将其写入磁盘。相反，Lucene 会更新其内部内存数据结构。一旦积累了足够的数据或触发了刷新，这些文档就会写入磁盘，创建一组新的不可变文件（在 Lucene 术语中称为段）。在将段写入磁盘之前，已索引的文档不可用于搜索。这就是为什么刷新在 Elasticsearch 中是一个如此重要的概念。您可能想知道，在刷新触发之前，文档保存在内存中时如何确保持久性。这是通过 Translog 实现的，Translog 持久存储每个操作，以确保数据持久性和故障恢复。

现在我们知道了什么是 Lucene 段以及为什么在 Elasticsearch 中需要刷新，我们可以探索有状态 Elasticsearch 和无服务器 Elasticsearch中刷新行为的不同之处。

有状态 Elasticsearch 中的刷新

在 Elasticsearch 中，索引被划分为多个分片，每个分片包含一个主分片和可能多个副本分片。在有状态 Elasticsearch 中，当索引文档时，它首先被路由到主分片，Lucene 在那里处理和索引它。在主分片上索引之后，文档将被路由到副本分片，在那里由这些副本进行索引。

如前所述，需要刷新才能使这些已索引的文档可搜索。在有状态 Elasticsearch 中，刷新会将 Lucene 内存数据结构写入磁盘，而无需执行 fsync。刷新会定期安排，每个节点在不同的时间执行它们。此过程将在每个节点上创建不同的 Lucene 段文件，所有这些文件都包含相同的一组文档。

无服务器 Elasticsearch 中的刷新

相反，无服务器 Elasticsearch 采用基于段的复制模型。在这种方法中，每个分片的一个节点处理文档索引并生成 Lucene 段。一旦启动刷新，这些段就会上传到 Blob 存储。随后，搜索节点会收到关于这些新的 Lucene 段的通知，它们可以直接从 Blob 存储中读取这些段。

Refresh flow before optimizations in Elasticsearch

上图演示了无服务器 Elasticsearch 中刷新的工作方式

索引节点（所有文档都在其中索引）接收刷新请求，Lucene 将内存数据结构写入磁盘，这与有状态刷新的操作方式类似。
段文件作为单个文件（称为无状态复合提交）上传到 Blob 存储。在上图中，上传了 S4。
段文件上传到 Blob 存储后，索引节点向每个搜索节点发送消息，通知它们新的段文件，以便它们可以对新索引的文档执行搜索。
搜索节点在执行搜索时从 Blob 存储中获取必要的数据。

此模型具有轻量级节点的优势，因为数据存储在 Blob 存储中。与有状态 Elasticsearch 相比，这使得在节点之间扩展或重新分配工作负载更具成本效益，在有状态 Elasticsearch 中，必须将数据传输到包含新分片的新节点。

值得考虑的一个方面是与无服务器 Elasticsearch 中每次刷新相关的附加对象存储请求成本。每次刷新操作都会在对象存储中创建一个新对象，从而导致对象存储 PUT 请求并产生相关的成本。这导致索引数量与对象存储 PUT 请求数量之间存在线性关系。如果刷新次数足够多，对象存储成本可能会超过硬件本身的成本。为了解决这个问题，我们最初实施了刷新节流措施，以有效地管理成本并减轻潜在问题。这篇博文描述了这项工作的下一步，这使我们能够更快、更经济地进行刷新。

无服务器 Elasticsearch 中的刷新成本优化

如前所述，无服务器 Elasticsearch 架构提供了许多好处。但是，为了有效地管理刷新成本，我们做出的决定有时会影响用户体验。其中一项决定是强制执行 15 秒的默认刷新间隔，这意味着在某些情况下，新索引的数据要经过 15 秒才能可搜索。尽管我们付出了努力，但对象存储费用变得过高的场景依然出现，这促使我们重新评估我们的方法。在本节中，我们将深入探讨我们如何成功地将刷新操作与对象存储调用解耦，以解决这些挑战，同时不会影响用户体验。

在评估了各种解决方案后——从在 NFS 等分布式文件系统中临时存储段到直接将段推送到搜索节点——我们选择了一种依赖于索引节点直接向搜索节点提供段数据的方法。

索引节点不再让刷新立即将新的 Lucene 段上传到 Blob 存储，而是现在累积来自刷新的段，并在稍后将它们作为一个 Blob 上传。这使得索引节点能够以类似于 Blob 存储的方式为搜索节点提供读取服务，将段上传延迟到积累足够的数据或经过预定时间间隔。

此策略使我们能够完全控制上传到 Blob 存储的 Blob 大小，从而使我们能够确定何时请求成本相对于硬件成本变得可以忽略不计。

批量复合提交

我们的目标是以增量方式实现此增强功能，并确保与存储在 Blob 存储中的现有数据向后兼容。因此，我们选择保持在 Blob 存储中存储 Lucene 段的相同文件格式。作为背景，Lucene 段包含多个文件，每个文件都扮演着不同的角色。为了简化上传过程并最大限度地减少 PUT 请求，我们引入了复合提交：单个 Blob 包含所有连续的段文件，以及元数据头，包括复合提交中文件的目录。

从 Blob 存储检索复合提交时（例如在分片重新定位期间），我们的主要关注点通常是复合提交头。此标头至关重要，因为它包含快速填充内部数据结构所需的基本数据。考虑到这一点，我们意识到我们可以保持现有的文件格式，但对其进行简化，以便每个 Blob 都可以顺序地附加一个复合提交到另一个复合提交之后。我们将此新文件格式命名为批量复合提交。

由于每个复合提交的大小都存储在其头部，因此检索批处理复合提交内所有复合提交的头部非常简单；我们可以通过简单地查找下一个条目来顺序读取每个头部。处理旧格式的 Blob 时，它们被视为单例批处理复合提交。我们文件格式的另一个关键方面是，一旦 Lucene 段文件被追加到批处理复合提交中，就为每个文件维护固定的偏移量。这确保了文件是从索引节点还是 Blob 存储中提供服务的一致性。它还避免了在最终将批处理复合提交上传到 Blob 存储时，需要逐出搜索节点上的缓存条目。

新的刷新生命周期

索引节点现在将累积来自刷新的 Lucene 段，直到收集到足够的数据才能将其作为单个 Blob 上传。让我们探讨一下索引节点和搜索节点如何协调以确定从哪里访问这些数据。

Optimized refresh flow in Elasticsearch serverless

如上图所示，在无服务器 Elasticsearch 中优化的刷新过程中会发生以下步骤：

索引节点接收刷新请求，将其写入新的一组 Lucene 段到本地磁盘，并将这些段添加到待处理的批处理复合提交中，以便最终上传。
索引节点将这些新段的信息（包括相关段和它们的位置（Blob 存储或索引节点））通知搜索节点。
当搜索节点需要一个段来满足查询时，它会决定是从 Blob 存储还是索引节点获取它，并在本地缓存数据。

Optimized refresh upload flow in Elasticsearch serverless

上图说明了在无服务器 Elasticsearch 中将数据上传到 Blob 存储的过程，一旦索引节点中累积了足够的段，或者在指定的时间过去之后。

刷新会向批处理复合提交添加一个新的段，并且累积的数据达到 16 MB，或者自上次刷新以来已经过了一定的时间，从那时起，新的段将累积到一个新的批处理复合提交中。
索引节点开始将累积的段作为单个 Blob 上传到对象存储。
索引节点将最新上传到对象存储的段通知搜索节点副本，指示它们以后从 Blob 存储中获取这些段的数据。
如果搜索需要本地未缓存的数据，它将从 Blob 存储中检索必要的信息，而即使在上传之后，先前从索引节点获取的任何数据仍然有效。

考虑因素和权衡

所选择的方法模糊了存储和计算之间的清晰界限，要求索引节点处理存储请求，直到 Lucene 段最终上传到 Blob 存储。但是，这些存储请求的开销最小，我们没有观察到对索引吞吐量的影响。

我们注意到，我们将事务日志条目保留到相应的数据上传到 Blob 存储为止，因此该方法保持了现有的数据安全保证。崩溃后的恢复时间可能会略长一些，但我们认为这是一个可以接受的权衡。

结论

这篇博文探讨了我们向更云原生方法的转变，强调了它的许多好处以及关键的成本考虑。我们追踪了我们的发展历程，从一个模型转变为在对象存储中每个新的 Lucene 段生成一个不同的对象。与有状态 Elasticsearch 相比，这导致了特定无服务器工作负载中的成本和用户体验挑战。批处理对象存储上传使我们能够最大限度地减少对象存储请求的数量，并提高无服务器产品的成本效率。